[Salon Linux] – Industrialisation JEE / Intégration continue
Voilà, je mets moi aussi la main à la pâte pour faire un petit compte rendu sur ce à quoi j’ai assisté durant le salon du Linux. Khanh a très bien fait le point sur les différentes conférences auxquelles il a assisté dans les articles précédents. Pour ma part, je vais plutôt m’intéresser à la formation/tutoriel de mercredi après-midi (deuxième jour du salon) et qui a pour nom très évocateur :
« INDUSTRIALISER LES DÉVELOPPEMENTS JAVAEE »
Et plus spécialement la 4ème session intitulée de cette formation/tuto ayant (presque) le même titre : Industrialisation des développements JEEet co-animéeparChristian BLAVIER et Benoît Lafontaine de la société OCTO(vous pouvez retrouver le programme des formations/tutos ici)
Au début de la présentation, une explication sur la notion d’Industrialisation dans le monde informatique a été faite.
Qu’est ce que l’industrialisation ?
Là on pourrait penser au Taylorisme mais ce n’est pas du tout de cela qu’il est question ici 🙂 Nous parlons plutôt du Toyotisme (mis en avant par Toyota et qui met l’homme au centre de la démarche).
L’industrialisation se base suivant la structure de la présentation sur 3 concepts :
- l’intégration continue
- le développement piloté par les tests
- mesure continue de la qualité
Je vais présenter ici un aperçu sur la première partie de leur présentation l’intégration continue, très intéressante, il faut dire.
Pourquoi faire de l’intégration continue ?
Tout simplement car plus un défaut est détecté tard et plus il couterait cher à corriger, c’est la loi du « Defect Cost Increase » ! Voici un diagramme (tiré d’un site qui prône les méthodes agiles.. mais ça c’est un autre sujet !) qui illustre ceci :
[/caption]
L’idée de l’intégration continue est donc d’utiliser un serveur d’intégration continue (comme Hudson, CruiseControl, Continuum..) qui à chaque « build » local va réaliser un « build » global allant de la récupération des dépendances à la documentation comme l’illustre la figure suivante :
[/caption]
L’intégration continue doit toutefois surmonter 2 défis de taille :
- s’assurer d’une bonne performance
- et éviter l’instabilité du « build ».
Défi 1 : Performance
Le problème :
Le problème qui pourrait survenir est que si beaucoup de « builds » sont réalisés en même temps, le « build » global devant passer par toutes les étapes décrites ci-dessus pourrait prendre beaucoup de temps et ralentir considérablement le serveur d’IC.
Les solutions proposées :
– Build profilé :
Au lieu de refaire toutes les étapes à chaque fois, il faut choisir les opérations à effectuer. Exemple : Il n’est pas très utile de réaliser le « build » de la documentation à chaque fois, cette opération pourrait donc être effectuée pendant la nuit. A contrario, des « builds » rapides se basant sur les tests unitaires pourraient eux, être effectués toutes les 10 minutes et ainsi de suite…
– Build distribué :
L’idée derrière cette solution est la distribution par le serveur d’IC (maître) de certains « builds » (comme le « build » complet) sur des serveurs d’intégration secondaires (agents).
Défi 2 : Eviter l’instabilité du « Build »
Le problème :
Toute l’idée de l’IC est de faire des « builds » assez souvent. Les « builds » instables sont donc et très logiquement un des problèmes qu’il faut absolument gérer pour empêcher qu’un développeur ne bloque les autres et conserver un référentiel de sources “propre”.
Les solutions proposées :
– Instaurer une culture du « build » :
Il faut souligner ici l’intérêt de certaines petites règles que je trouve très ingénieuses car elles incitent les développeurs à faire plus attention avant de mettre leur code sur le gestionnaire de sources et en plus, pourrait instaurer une bonne atmosphère au sein de l’équipe : Exemple de règle : « Celui qui casse le build, paie le café » (…ou les croissants… en fonction de la gravité des conséquences de ses actes J)
– Le « build » incassable :
L’idée ici est de passer par le serveur d’IC et s’assurer que le « build » passe sans problèmes avant d’intégrer le code au gestionnaire de sources.
Conclusion
L’intégration continue reste un ensemble de bonnes pratiques pour mieux réaliser un projet et détecter/résoudre les problèmes très tôt dans la réalisation. Cette présentation donnait un aperçu clair des différents avantages de l’intégration continue mais explique aussi les défis qu’elle doit relever, à savoir: éviter que cela ne se fasse au détriment de la performance et aussi garantir la robustesse des builds.