Project-Builder 0.10.1 est disponible

Posté par (page perso) . Modéré par Xavier Teyssier.
Tags : aucun
16
20
jan.
2011
Perl
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.
  • # Adieu JVM

    Posté par (page perso) . Évalué à 0.

    Ave,

    C'est une très bonne nouvelle pour ceux qui veulent éviter les logiciels équivalent en Java ( http://cruisecontrol.sourceforge.net/ ).

    Bravo !
    • [^] # Re: Adieu JVM

      Posté par . É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 . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 ?
  • # Des exemples de projets libres utilisant ce type d'outils?

    Posté par . É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?
  • # Alternative en python

    Posté par (page perso) . Évalué à 1.

    Ave,

    À tous, il semble y avoir une alternative en python issue du monde Zope : ZC.buildout.

    http://pypi.python.org/pypi/zc.buildout

    Ce projet semble intégrer l'exécution de tests automatiques à partir de .egg et autres formats.


    À quand un comparatif ? :)

    Étienne
    • [^] # Re: Alternative en python

      Posté par (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.