1. L’ Intégration Continue
Xavier.Warzee@Valtech.Fr
http://warzee.fr
Le 9 Octobre 2007

2. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
Conclusion

3. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
Conclusion

4. Motivations au niveau entreprise
Marketing
• Demande de démonstrations non planifiées
Budgets
• Démontrer rapidement l’avancement d’un projet
 Projets gérés par tranches, par lots conditionnels : focus sur le fonctionnel important !
Ressources, équipes
• Coordination d’équipes distribuées : le reporting projet ne suffit pas !
 Il faut partager les mêmes éléments d’évaluation de l’état d’avancement d’un projet
• Des changements dans l’organisation : fusion/acquisition, restructuration, …
Besoins : les besoins varient continuellement en fonction
• Des produits de concurrents éventuels
• Des changements légaux, règlementaires (contraintes d’importation, de
confidentialité, etc.)
Besoin d’intégrer les évolutions d’un projet en continu

5. Motivations au niveau projet
Nécessité d’améliorer :
• La qualité des livrables
 Réduire la complexité ( meilleure maintenabilité)
 Adéquation
• La traçabilité
 des changements
 des déploiements
• La productivité
 Se focaliser sur le métier, pas sur la technique
Principes « agiles »
• Fabriquer souvent
• Tester souvent (tests unitaires)
• Tester les performances souvent
• Intégrer souvent dans le SI

6. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
Conclusion

7. Formalisation par Martin Fowler & Kent Beck, 2000
« Continuous Integration is a software development
practice where members of a team integrate their
work frequently, usually each person integrates at
least daily - leading to multiple integrations per day. »
« Each integration is verified by an automated build
(including test) to detect integration errors as
quickly as possible. »
Many teams find that this approach
 leads to significantly reduced integration problems
 and allows a team to develop cohesive software more rapidly.

8. Principes
Fabriquer (build) un projet à chaque changement
• Intégrer les changements en continue !!!
« Build » ?
• Compiler
• Tester (tests unitaires, d’intégration , de performance)
• Inspecter (revue de code)
• Déployer
• Documenter
• Notifier (email, SMS, RSS, etc.)

9. Principes
4
6
5
Serveur d’intégration Plateforme de déploiement
Check In (changements)
1
1 3
2 Détection des changements (sur les logs)
2
Update de l’espace de travail du serveur d’intégration
3
4 Exéctution du « build »
• compilation des sources,
• regénération des ressources,
• tests,
Référentiel de
• inspections,
Gestion de configuration
• déploiements
(Clearcase, CVS, SVN, …)
Notification des résultats (RSS, Email, Blog, Tray, …)
5
Déploiement de l’application
6

10. Les différents types de « build »
Cf. SDTimes « Will the Build Bottleneck Put the Brakes on Agile? »
(http://www.sdtimes.com/article/special-20050815-01.html)

11. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
Conclusion

12. Processus d’intégration continue : enjeux
Comment contrôler la
qualité durant les étapes
de « build » ?
 automatiser le
processus complet en
tenant compte des
aspects distribués
 plateformes de
développement,
 plateformes d’intégration,
 plateformes d’acceptation,
 plateformes de pré-
production,
 etc.

13. Processus d’intégration

14. Processus d’intégration continue
>Côté développeur
Plateforme de développement
• « Local build » : les développeurs construisent le logiciel sur leur
poste de travail
 Compilation des sources, exécution des tests, inspection du code, etc.
 Si possible, utilisation des mêmes commandes de « build » que celles du serveur
d’intégration continue (IC)
• « commit at all time » : à tout moment, les développeurs peuvent
mettre à jour le référentiel commun de gestion de configuration
(travail en équipe)
Référentiel de gestion de configuration
(«source repository »)
• Ensemble des éléments d’un projet (documents, code, …) gérés en
configuration
• Les développeurs mettent à jour le référentiel avec le code, les tests,
les documents
• le code doit en principe être compilable
• les tests doivent en principe être exécuté avec succès

15. Processus d’intégration continue
> Côté serveur d’intégration continue
« Automated builds integration plateform »
• Construction automatique de l’application régulièrement, par exemple
toute les 2 heures
• Production de rapports (tests, qualité, activités, …) disponibles en
ligne et/ou par exemple envoyés par messagerie
Livraison d’une « release » en interne régulièrement
• Par exemple toute les 2 semaines
• Objectif de cette « release » : faire des tests fonctionnels et/ou de
performance (stress)
Livraison officielle

16. Processus d’intégration continue
> En résumé
Automatiser le processus de développement
• Extraction périodique et automatique des sources du
référentiel
• Lancement des tests, calcul de couverture des tests
• Calcul d’indicateurs (complexité, etc.)
• Construction du logiciel
• packaging, déploiement automatisé

17. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
Conclusion

18. Focus sur l’inspection du code
> Inspection par les tests
Accessible à distance (équipe offshore)
Plateforme de développement
Plateforme
Plateforme
Plateforme d’acceptation
de
d’intégration client
Station Machine
pré-acceptation
de travail d’assemblage
- Tests d’intégration - Tests fonctionnels
- Tests unitaires - Tests Fonctionnels (manuel) - Tests fonctionnels
exécutés par l’équipe de
(mocks/bouchons) exécutés par le client
- Tests fonctionnels par les - Tests Techniques
d’intégration (manuel) (manuel)
développeurs
- Quelques tests /Performance (manuel)
d’intégration (Base de
données)
Automatisation possible des tests fonctionnels avec des
outils comme Selenium

19. Focus sur l’inspection du code
> Inspection par les tests
« Build » en journée
• Un « build » de journée est lancé en moyenne toutes les 2 heures :
 le temps est donc compté pour lancer des tests !
• Des tests simples ou « smoke tests »* peuvent être lancés permettant
de détecter rapidement des disfonctionnements essentiels :
 Fichiers de configuration (XML, propriétés, etc.) inconsistants entre eux ne
permettant pas de démarrer l’application par exemple
 Ressources tierces inaccessibles (base de données, drivers, etc.)
• Ces tests doivent solliciter toutes les parties d’une application sans
pour autant être exhaustifs
• Typiquement, les tests unitaires sont lancés en journée. Un test
unitaire ne doit prendre que quelques secondes pour s’exécuter.
 Tests avec ou sans bouchon (mocks)
 Tests sans bouchon : utiliser des frameworks de tests comme TestNG (suites de
tests lancés en fonction d’autres tests exécutés avec succès !)
* Article de Steve McConnell, IEEE Software, Vol. 13, No. 4, July 1996

20. Focus sur l’inspection du code
> Inspection par les tests
« Build » de nuit (nightly build)
• Exécuter des tests plus exhaustifs !
 100% des tests doivent être exécutés avec succès pour le « build »
se termine avec succès !!!
• Ces tests permettent par la suite de réduire les risques à
l’intégration
• Comme il y a moins de changements entre 2 « builds », il
est plus simple
 de diagnostiquer l’origine d’un problème de compilation
 ou de comprendre pourquoi certains tests sont en échec.

21. Focus sur l’inspection du code
> Métriques, revue de code
Quoi mesurer ?
• Taux de couverture du code,
• Métriques de complexité (McCabe, …),
• Détection de bugs (Findbugs, PMD, …)
Comment mesurer ?
• Maven, xUnit, Agitar, Sonar, Cobertura, …
Reste « Quand mesurer » ?
• Mesurer quotidiennement (« build » de nuit)
• Eviter de créer un effet tunnel !

22. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
La solution Cruisecontrol
Conclusion

23. La solution CruiseControl
CruiseControl est un outil
• Permettant la construction automatisée du logiciel.
• Indépendant de l’outil de construction
 Shell : utilisation possible de make, gmake, clearmake
 Ant
 Maven
• Indépendant du gestionnaire de source
Cvs

Subversion

Clearcase

…


24. La solution CruiseControl
• RSS
• e-mail
Référentiel
• Jabber
Cruisecontrol
1 3
de source
• x10
• web
2
• Compiler
• Tester
ANT
• Inspecter
Maven • Déployer
Shell • Documenter
Détecte les modifications
1
Lance et contrôle la construction
2
Publie les résultats
3

25. 3 développeurs
pendant
6 mois
=
980 builds
( 8 / jours )

26. La solution CruiseControl
> l’écosysteme
Extension Firefox
Widgets
• Widget Apple
• Widget Yahoo
Windows SysTray
• JCCTray, CCTray (.Net)

27. La solution CruiseControl
Détection de problème en amont.
Détection au checkin.
Evite l’intégration traditionnellement faite en fin de
projet.
Outil de communication
« Machine à feedback »

28. Intégration continue
>Agenda
Motivations
Principes
Processus d’intégration continue
Focus sur l’inspection du code
La solution Cruisecontrol
Conclusion

29. Conclusion
Contrôler la qualité pendant les développement
• Tester souvent
• Tester les performances souvent
• Construire les applications souvent (« build »)
Cruisecontrol est une référence
• Écosystème signe de reconnaissance et maturité
 Apple Widget, Yahoo Widget, CCTray, …
• Il existe des solutions opensource plus simple (moins
souple ?) :
 Bamboo, Continuum, Hudson, etc.
• Des solutions commerciales existent :
 BuildForge (IBM), OpenMake (Catalyst Systems Corporation), ParaBuild
(Viewtier Systems)

30. Conclusion
L’intégration continue
• Moyen efficace d’éviter le « big-bang » d’une phase
d’intégration
• « releases » plus robustes et fonctionnellement
pertinentes :-)
• Capitalisation des bonnes pratiques de fabrication du
logiciel
• Processus répétable et automatisé de fabrication du
logiciel
• L’automatisation permet plus de réactivité