Suivez-moi aussi sur Identi.ca 
ou sur Twitter 
Après mon billet décrivant un exemple d’infrastructure derrière un site web moderne, je vais continuer dans cette veine en décrivant un exemple d’infrastructure servant au développement d’un projet de Logiciel Libre, à savoir ici le projet Brebis, un vérificateur de sauvegarde (nombreux types d’archives, fichiers plats) dont j’ai déjà parlé de nombreuses fois sur ce blog.
C’est parti !
Gestionnaire de versions décentralisé : Mercurial
Au coeur du processus de développement du projet, l’outil décentralisé de gestion de versions Mercurial. J’ai fait le choix de Mercurial car il est codé principalement en Python et utilisé dans la communauté des Pythonistes. Utilisant déjà Git plus ou moins régulièrement, Je souhaitais avoir une expérience sérieuse de développement avec Mercurial, en ayant marre de lire des comptes-rendu de personnes qui testent 10 minutes Mercurial puis 10 minutes Git et ensuite écrivent un billet de 10 pages sur le sujet. Pas de parti pris donc.
Intégration continue avec le projet Buildbot
Avec le projet Belier, un générateur de script expect pour établir des connexions SSH complexes, j’avais commencé à utiliser l’outil d’intégration continue Buildbot qui consiste à lancer une série de tests à chaque modification de mon dépôt de sources et à fournir une vue synthétique du résultat de ces tests, afin d’éviter d’introduire de nouveaux bugs et de subir des régressions (casser des fonctionnalités déjà présentes dans les versions précédentes) au sein du code. Mes besoins n’ayant pas beaucoup évolués, j’ai déployé une nouvelle instance Buildbot et l’utilise pour différentes étapes de l’intégration continue, à savoir :
- lancement automatique des actions de Buildbot via un hook dans le dépôt Mercurial sur le serveur
- Lancement des tests unitaires sur le serveur
- Lancement des tests fonctionnels sur le serveur
- Construction du paquet Python sur le serveur
- Test de l’installation du paquet Python sur le serveur
- Lancement des tests fonctionnels qui vont prendre du temps (plusieurs dizaines de minutes) sur le serveur
Le résultat est une vue en cascade des différentes étapes du processus d’intégration continue permettant d’identifier les étapes ayant échouées et vous permettant ainsi de les corriger avant la publication de la nouvelle version.
Site web, suivi de bugs et accès web au dépôt du projet : la forge Redmine
La forge Redmine est un projet que j’affectionne car il fournit une forge (qu’est-ce qu’une forge logicielle ?) efficace, simple à configurer et offrant de nombreuses fonctionnalités (wiki, forums, explorations des dépôts via le web, publication de news, …). Puis c’est 100% du Logiciel Libre (GPL) contrairement à blingbling Github. Cette forge me permet de rester tant que je le souhaite avec le même cadre de travail.
J’utilise beaucoup la fonctionnalité de suivi de bugs (et je vous la recommande) afin de tracer les différentes étapes du développement (principalement améliorations et corrections de bugs) et j’ai donc de nombreuses interactions entre le dépôt Mercurial et les bugs ouverts dans Redmine. Lors de mes commits une chaîne de type “fixes #21” dans mon message de commit me permet par exemple de fermer automatiquement un bug ouvert dans Redmine. Quasi indispensable.
Axes d’amélioration
Le principal goulet d’étranglement que je rencontre aujourd’hui n’est plus tant dans le processus de production du code que dans le processus de publication. J’ai encore de nombreuses étapes manuelles à ce niveau que je pourrais réduire drastiquement. Je vais donc me concentrer sur ces points dans un futur très proche. J’ai également dans l’idée de mettre en place un outil de revue de code quand le nombre de contributeurs grossira.
Et vous ? Que pensez-vous de l’infrastructure décrite ci-dessus ? N’hésitez pas à réagir dans les commentaires.
Moi personnellement, j’utilise git, gitlab et gitlab-ci. C’est un github like en ruby on rails qui fonctionne très bien. J’utilisé redmine avant mais la mise à jour et la maintenance de redmine me gêner.
Voilà mes 2 cents
Alexandre Cartier : merci pour ton retour. En effet j’aurais envisagé gitlab si j’étais dans un projet uniquement sous Git. Mais là j’ai plusieurs projets et je passe de Git à Mercurial donc une forge multi dvcs me va mieux.
Merci pour avoir mentionné Gitlab CI, j’avais jeté un coup d’oeil à gitlab il y a un moment mais je n’avais pas vu qu’ils y joignaient un outil d’intégration continue. Je vais regarder ça de plus près.
Ayant fait le tour de la question récemment, j’ai opté pour GitHub pour mes projets libres. Je me suis aussi crée un compte sur Gitlab, mais je ne l’ai pas déployé sur mon serveur.
En résumé :
– Je trouve redmine pas intuitif du tout, le blingbling github/gitlab me convient bien mieux.
– Des softs d’intégration continue pèse lourd sur un serveur. Je préfère alors utilisé des services annexes à GitHub.
– Une instance de Gitlab est supposée être déployée pour des centaines de personnes. Et il ne possède pas de dépôts publiques.
– Tu n’a pas la force de la communauté GitHub, où tout le monde possède déjà un compte (j’ai horreur de me créer un compte sur la forge redmine d’un autre) et fait un pull request en trente secondes sans avoir git installé ..
Au final pour de petits projets libres, ça ne vaut pas le coup de déployé soit-même un environnement.
Quentin : La notion du Logiciel Libre est quelque chose d’important pour moi et je n’envisage pas faire intervenir des logiciels privateurs dans la réalisation d’un Logiciel Libre (en tout cas pas à titre personnel). Github en est un.
Maintenant on est d’accord c’est très pratique, très beau, communauté énorme, mais l’affaire Bitkeeper (http://fr.wikipedia.org/wiki/BitKeeper#BitKeeper_et_Linux) nous a appris à nous méfier de l’intervention d’un maillon privateur dans la chaîne libre de réalisation de nos logiciels.
Pour gitlab depuis la version 4.1 il est possible de rendre sont projet public
Pour moi aussi. Cependant je ne serai pas aussi absolu que Stallman, et l’affaire Bitkeeper est un exemple que je n’aime peu, ça c’est mal terminé, mais je suis du côté de Linus qui a accepté d’utiliser un logiciel proprio.
Bref, pour en revenir a nos moutons, j’aimerais utiliser aussi un logiciel libre mais rien ne me convient.
En fait, ce qui cloche c’est que les forges libres actuelles se concentre trop sur l’aspect client/serveur, alors que des instances décentralisé de Gitlab, pouvant communiquer ensemble, à l’instar de diaspora, ça ça sera le pied !
Parce que c’est l’aspect social et la grande communauté de Github qui en fait un excellent hébergeur de logiciels libres, bien que le code de ce dernier soit fermé.
Cependant, je comprend ton point de vue, et je ne confierais pas la compilation de mes softs, s’il avait une certaine importance, à un service proprio.
Alexandre: Il y a public et public. Les dépôt sont encore moins publics que sur redmine vu qu’il faut absolumant s’inscrire sur gitlab.
Pour la compatibilité Git+Mercurial j’utilise Bitbucket pour mes projets personnels.
Pour les déploiements j’utilise zc.buildout pour sa capacité à installer autre chose que du Python tout en gardant un syntaxe lisible. J’ai mon propre serveur Pypi privé avec Plone+PloneSoftwareCenter pour le stockage et la distribution. Pour finir j’utilise zest.releaser pour préparer les distributions.
La chaîne complète est raisonnablement automatisée.
Encolpe DEGOUTE : très intéressant merci. il faut vraiment que je me penche sur zc.buildout
Quentin : l’exemple de Linus et BitKeeper est malheureusement symptomatique de ce qui peut arriver quand on utilise un logiciel privateur dans sa chaîne de production de logiciels libres. C’est un cas d’école à méditer. Je mets toujours dans la balance au moment du choix d’un logiciel son côté pratique avec sa pérennité dans le temps et la communauté derrière.
Car aussi beau un logiciel soit-il, s’il m’oblige à perdre des centaines d’heures de travail pour migrer en catastrophe car la société qui l’édite a été racheté/rend payant la solution/met la clé sous la porte/m’interdit l’accès au logiciel car elle n’aime pas mon activité ou ma communauté/(remplir selon sa convenance), je l’écarte immédiatement.
De plus les EULA des logiciels privateurs permettent de faire tout et n’importe quoi (et t’oblige à signer n’importe quoi pour avoir accès à leur service), c’est un risque majeur de mon point de vue.