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 Check In (changements)
1 3
2 Détection des changements (sur les logs)
2
3 Update de l’espace de travail du serveur d’intégration

4 Exéctution du « build »
• compilation des sources,
• regénération des ressources,

Référentiel de • tests,

Gestion de configuration • inspections,

(Clearcase, CVS, SVN, …) • déploiements

5 Notification des résultats (RSS, Email, Blog, Tray, …)

6 Déploiement de l’application
 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

Plateforme
Plateforme
Plateforme d’acceptation
de
Station Machine d’intégration client
pré-acceptation
de travail d’assemblage

- Tests unitaires - Tests d’intégration - Tests Fonctionnels (manuel) - Tests fonctionnels - Tests fonctionnels

(mocks/bouchons) exécutés par l’équipe de exécutés par le client

- Tests fonctionnels par les - Tests Techniques
d’intégration (manuel) (manuel)
- Quelques tests développeurs /Performance (manuel)

d’intégration (Base de

données)
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
Référentiel • e-mail
1 Cruisecontrol 3 • Jabber
de source
• x10
• web
2

• Compiler
ANT • Tester
• Inspecter
Maven • Déployer
Shell • Documenter
1 Détecte les modifications
2 Lance et contrôle la construction
3 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é