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.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.