Un billet concernant quelque chose qui me tient particulier à coeur en tant que développeur.
L’intégration continue est un ensemble de pratiques liées au génie logiciel et qui permettent d’obtenir facilement un instantané de l’état d’un projet.
Je m’explique, mettre en place l’intégration continue sur un projet permet à tout moment de :
- Extraire les sources du repository (CSV, SVN, ClearCase, …)
- Vérifier que le code compile
- Vérifier que les tests unitaires sont OK
- Packager une version
- Analyser le code source à l’aide de plugins tels que Checkstyle, Findbugs, …
- Vérifier la couverture de code des tests unitaires (Cobertura)
- Générer les rapports HTML des actions précédemment citées
Alors concrètement, comment mettre ça en place? Voici comment j’ai fait sur ma mission actuelle :
Matériel mis à ma disposition :
- 1 PC sous XP (2GHz, 2Go de RAM)
Besoins logiciels :
- Maven2 : pour créer les scripts de compilation, packaging, reporting, …
- Continuum : pour gérer la planification de l’exécution des scripts Maven
- WAMP : héberge les rapports HTML, ainsi qu’un Wiki interne
- Client ClearCase : permet d’extraire les sources du projet
Tous les jours à 6h du matin, Continuum lance l’extraction des sources du projet.
Tous les jours à 7h du matin, Continuum lance la compilation, l’exécution des tests, l’exécution de l’audit de code, et génère les rapports HTML.
De ce fait, un développeur qui arrive au travail à 8h peut déjà consulter l’état du projet :
- Est-ce que toutes les actions ont l’état Success ?
- Si la réponse est NON : Quelle est la cause? Un jar manquant, un fichier qui n’a pas été commité par un développeur, … dans ce cas, il faut réagir et, par exemple, modifier le script de packaging pour ajouter les dépendances manquantes.
- Si la réponse est OUI : Le code est-il propre? Le code est-il vraiment bien testé (couverture) ?
Un développeur du projet peut à loisir déclencher via Continuum les mêmes actions que celles qui sont exécutées quotidiennement.
Le mot de la fin :
En responsabilisant chacun des développeurs et en faisant en sorte d’agir à chaque erreur, on réduit l’effort à apporter le jour des livraisons 
J’aime beaucoup ton “mot de la fin”. En effet, je constate aujourd’hui (malheureusement) une déresponsabilisation constante des développeurs. Les sociétés mettent en place des encadrements de folie enlevant toute autonomie ou marge de manoeuvres à ces derniers.
Il est donc bon de mettre en avant des pratiques comme “l’intégration continue” qui encouragent les développeurs à prendre leurs responsabilités ; le métier n’en est que plus passionnant.
“De ce fait, un développeur qui arrive au travail à 8h”… oh?? ça existe?
)
@oh??
Oui ça existe, c’est le même développeur qui part à 17h
@Greg
Je trouve qu’en plus, c’est plutot fun de corriger ses erreurs pour faire baisser le score findbugs/checkstyle, et on prend par la même occasion de bonnes habitudes de code.
Je vois qu’on partage le même point de vue!!!
Vive l’intégration continue!
Dans ma boîte ils utilisent les produits Atlassian (Bamboo, Jira, Confluence). Très bonne intégration de tout ça!
Continuum a pris du retard par rapport à Hudson…
@AlexisMP
Pourrais-tu préciser ta pensée en nous exposant les ‘plus’ que Hudson possède par rapport à Continuum?
Je viens d’installer Hudson, et pour l’instant je n’ai pas noté de grandes différences, j’ai vu qu’il y avait une génération de graphiques. Mais … what else? Je l’ai trouvé un poil moins ergonomique que Continuum, mais peut être parce que j’ai trop l’habitude de ce dernier.
Pour faire court: communauté et plugins.
J’utilise aussi Hudson et pour faire court : oui les plugins sont géniaux, en revanche je trouve que beaucoup d’entre eux sont mal documentés ou mal finis.