[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.