L’ Intégration Continue

Xavier.Warzee@Valtech.Fr http://warzee.fr Le 9 Octobre 2007

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion

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

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

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion

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.

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

Principes
4

6 5 Serveur d’intégration Plateforme de déploiement

1 2

1 3 2 3 4

Check In (changements) Détection des changements (sur les logs) Update de l’espace de travail du serveur d’intégration Exéctution du « build » • compilation des sources, • regénération des ressources, • tests, • inspections, • déploiements Notification des résultats (RSS, Email, Blog, Tray, …) Déploiement de l’application

Référentiel de Gestion de configuration (Clearcase, CVS, SVN, …) 5 6

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)

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion

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.

Processus d’intégration

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

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

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é

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion

Focus sur l’inspection du code > Inspection par les tests
Accessible à distance (équipe offshore)

Plateforme de développement

Station de travail

Machine d’assemblage

Plateforme d’intégration

Plateforme de pré-acceptation

Plateforme d’acceptation client

- Tests unitaires (mocks/bouchons) - Quelques tests d’intégration (Base de données)

- Tests d’intégration - Tests fonctionnels par les développeurs

- Tests Fonctionnels (manuel) - Tests Techniques /Performance (manuel)

- Tests fonctionnels exécutés par l’équipe de d’intégration (manuel)

- Tests fonctionnels exécutés par le client (manuel)

Automatisation possible des tests fonctionnels avec des outils comme Selenium

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

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.

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 !

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code La solution Cruisecontrol Conclusion

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 …

La solution CruiseControl • RSS • e-mail • Jabber • x10 • web

Référentiel de source

1

Cruisecontrol

3

2

ANT Maven Shell
1 2 3

• Compiler • Tester • Inspecter • Déployer • Documenter

Détecte les modifications Lance et contrôle la construction Publie les résultats

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

La solution CruiseControl > l’écosysteme

Extension Firefox Widgets
• Widget Apple • Widget Yahoo

Windows SysTray
• JCCTray, CCTray (.Net)

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 »

Intégration continue >Agenda

Motivations Principes Processus d’intégration continue Focus sur l’inspection du code La solution Cruisecontrol Conclusion

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)

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é