principes de l'integration continue

L’ Intégration Continue

[email protected]://warzee.frLe 9 Octobre 2007

mailto:[email protected]

http://warzee.fr/

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


Motivations

Principes



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

Référentiel de

Gestion de configuration

(Clearcase, CVS, SVN, …)

1

2

3

4

1 Check In (changements)

2 Détection des changements (sur les logs)

3 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

4

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

6 Déploiement de l’application

56

Serveur d’intégration Plateforme de déploiement

Cf. SDTimes « Will the Build Bottleneck Put the Brakes on Agile? »(http://www.sdtimes.com/article/special-20050815-01.html)

Les différents types de « build »

http://www.sdtimes.com/article/special-20050815-01.html


Motivations

Principes



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é


Motivations

Principes



Conclusion

Focus sur l’inspection du code> Inspection par les tests

Station de travail

Machined’assemblage

Plateformed’intégration

Plateformede

pré-acceptation

Plateformed’acceptation

client

Plateforme de développement

Accessible à distance (équipe offshore)

- 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


« 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


« 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 !


Motivations

Principes



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 …


Référentielde source

ANT

Maven

Cruisecontrol1

2

3

• RSS • e-mail• Jabber• x10 • web

1

2

3

Détecte les modifications

Lance et contrôle la construction

Publie les résultats

Shell

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

3 développeurspendant6 mois

= 980 builds( 8 / jours )

La solution CruiseControl> l’écosysteme

Extension Firefox

Widgets• Widget Apple• Widget Yahoo

Windows SysTray• JCCTray, CCTray (.Net)


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 »


Motivations

Principes



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é

principes de l'integration continue

Documents