Project-Builder 0.10.1 est disponible

Posté par Cornec Bruno (site web personnel) le 20 janvier 2011 à 12:49. Modéré par Xavier Teyssier.

Étiquettes :

jan.

2011

Une nouvelle version de l'outil d'empaquetage en continu (Continuous Packaging) Project-Builder.org a été publiée ce 17 janvier.

Avec le rôle grandissant du logiciel libre dans l'entreprise, certaines des techniques de développement de ces projets connaissent aussi un momentum. L'intégration continue (dépot partagé de sources, fabrication automatique, test automatique) en est un exemple. Le nouveau procédé que représente l'empaquetage en continu doit néanmoins encore être promu et développé comme bonne pratique pour l'industrie.

Project-Builder.org est un projet GPL v2, destiné aux développeurs de logiciels libres, pour leur permettre de fournir le plus aisément possible des paquets logiciels pour diverses cibles à partir d'une seule source de données. Il leur permet d'agrandir leur base d'utilisateurs et de faciliter l'installation et la gestion de leurs applications.

Il vise à devenir un outil de l'initiative vcs-pkg.org.
L'outillage est aujourd'hui utilisé pour des projets aussi divers que FOSSology, MondoRescue, LinuxCOE.

Les fonctions de l'outil sont détaillées dans la suite de la dépêche. Les aspects couverts par l'outil sont :

produire uniquement des paquets logiciels (facilite l'intégration au sein de serveurs de déploiement, fournit des mécanismes d'héritage et des environnements / machines virtuelles);
faciliter les diverses phases du cycle de développement (impact contrôlé à l'installation/désinstallation, gestion des dépendances, gestion de l'intégrité, gestion des annonces, délivrance de site web, dépôt de méta-données) ;
accompagne les nouveaux projets dans la production de paquets (modèles et squelettes pour les divers systèmes supportés, structure générée, accompagnement dans la fabrication des environnements/machines virtuelles) ;
éviter la duplication de code ou de méta-données, ainsi que l'impact sur le projet d'origine (système de macros, dépôt séparé) ;
être neutre en terme d'environnement Unix (agnostique par rapport au dépôt, au système, au type de paquet).

Ces fonctions contribuent à réduire le coût de développement en fournissant un processus, des méthodes et un outillage pour empaqueter en continu des projets tout au long de leur cycle de vie.

Aujourd'hui l'outil prend en charge :

de multiples dépôts (aucun - archive tar, SVN, CVS, Git, Mercurial, SVK...) ;
de multiple systèmes (RPM Linux - Red Hat, SuSE, Mandriva... deb Linux - Debian, Ubuntu... ebuild - Gentoo, pkg Solaris/OpenSolaris...) ;
de multiples environnements de fabrications (local, VM - QEMU, KVM... VE - mock, rinse, pbuilder...) ;
de multiples gestionnaires de dépôts (yum, urpmi, apt...).

Tout ceci pour différentes étapes d'un projet : développement, test, intégration, livraison.

Aller plus loin

Site Web de Project-Builder.org (31 clics)
Wiki du projet (13 clics)
VCs-Pkg (8 clics)
GPLv2 (26 clics)

# Commentaire supprimé

Posté par Anonyme le 20 janvier 2011 à 13:59. Évalué à 0.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Adieu JVM
  
  Posté par flagos le 20 janvier 2011 à 15:22. Évalué à 3.
  
  C'est moi ou justement Project Builder ne repond pas au meme besoin que cruisecontrol ? Ce n'est pas de l'integration continue (avec build automatique et lancement automatique de tests) mais plutot un moyen de generer les differentes builds pour toutes les distribs possibles ? J'ai l'impression que cruisecontrol ne fait absolument pas ca (enfin j'avoue que je ne connais ni l'un ni l'autre)...
  
  Sinon, question par rapport a Project Builder, comment se passe la partie repo ? Par ex, sur Launchpad, les sources sont recompilees par le repo lui meme... Comment fait-on dans ce cas la ? On heberge nous meme les repos ? Il y a moyen d'uploader les paquets (sources je suppose) vers une liste de repos style launchpad de maniere automatique ?
  - [^] # Re: Adieu JVM
    
    Posté par daemontux le 20 janvier 2011 à 17:31. Évalué à 1.
    
    sur Launchpad, les sources sont recompilees par le repo lui meme
    Ah ? Comment tu fais-ça ? J'ai du passer à côté d'un truc, moi à chaque fois que je veux régénérer mes paquets je le fais à la main et les upload avec dput. Y'a moyen que Launchpad les reconstruise à chaque commit ?
    
    Sinon concernant ta question si le projet permet de pondre des .deb on doit pouvoir les envoyer sur un depot debian genre un ppa via dput justement. En tout cas je vois pas ce qui l'empêcherai.
    - [^] # Re: Adieu JVM
      
      Posté par flagos le 20 janvier 2011 à 17:55. Évalué à 2.
      
      Sur launchpad tu generes un paquet contenant les sources, tu l'uploades avec dput et Launchpad va ensuite le compiler. apres je ne pense pas que tu puisses genererdes paquets sources si tu as par exemple un repo git hebergé chez eux, si c'est ca ta question.
      
      "Sinon concernant ta question si le projet permet de pondre des .deb on doit pouvoir les envoyer sur un depot debian genre un ppa via dput justement. En tout cas je vois pas ce qui l'empêcherai."
      
      Justement, il reste une etape de compilation sur le serveur, qui est regulierement source d'erreurs. J'aimerai me l'eviter (c'est pour un futur projet).
      - [^] # Re: Adieu JVM
        
        Posté par daemontux le 20 janvier 2011 à 18:27. Évalué à 2.
        
        Ah oui j'avais oublié cette histoire de compilation, faut dire que le seul truc que j'ai publié sur Launchpad c'est du python alors...
        
        Ma question c'était de savoir si en ayant des sources sous bzr chez-eux ils pouvaient régénérer les paquets automatiquement, genre lorsque je commit ou une fois par jour.
        
        Sinon personne a utilisé le truc de Suse (build service) ? Si je me souviens bien c'est supposé générer des paquets et des dépots pour plusieurs distribs, ce serait intéressant d'avoir un comparatif avec package-builder par quelqu'un qui a utilisé les deux.
  - [^] # Re: Adieu JVM
    
    Posté par Alexandre COLLIGNON (site web personnel) le 21 janvier 2011 à 12:41. Évalué à 1.
    
    Je confirme on parle bien pas du tout de la même chose !
    
    Ne pas confondre intégration continue et création de paquet continue
    Alexandre COLLIGNON
# Exemple ?

Posté par Stéphane Gully (site web personnel) le 20 janvier 2011 à 14:33. Évalué à 4.

Ce qui est décrit plus haut est un peu trop abstrait à mon goût. On sent l'utilité de l'outil mais on (enfin j'ai) du mal à l'appliquer à mes problématiques quotidiennes.
Pour aider à avoir une vision plus pratique de l'outil, pourrait on avoir un exemple de "cas d'usage" de PB ?
- [^] # Re: Exemple ?
  
  Posté par Cornec Bruno (site web personnel) le 12 mars 2011 à 13:36. Évalué à 0.
  
  Régradez le Lab pour avoir une idée plus précise peut-être.
# Des exemples de projets libres utilisant ce type d'outils?

Posté par Gabin le 20 janvier 2011 à 16:06. Évalué à 2.

Qu'utilisent les gros LL tel que KDE, Gimp, Apache etc...?

ça parle surtout "entreprise", où l'on sait, tout est fait pour compliquer la vie d'un dev avec des gros serveurs d'applis en tout genre! :)

à notre échelle de dev du dimanche qui veut malgré tout monter d'un niveau en terme organisationnel, qualité de code etc... comment mettre en place une telle infra s'en que les avantages ne se fassent dépasser pas les inconvénients?
# Commentaire supprimé

Posté par Anonyme le 25 janvier 2011 à 11:11. Évalué à 1.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Alternative en python
  
  Posté par Cornec Bruno (site web personnel) le 12 mars 2011 à 13:38. Évalué à 0.
  
  Cela ne semble pas faire des paquets natifs de distributions, ce qui est le but de pb. Le comparatif pourrait plutôt être fait avec le build system Open SuSE par ex. Mais le but de pb est de donner à tout projet qui le souhaite les moyens de fournir des paquets facilement, sans dépendre d'autrui.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.