principes de l'integration continue
Post on 06-Jun-2015
5.726 Views
Preview:
DESCRIPTION
TRANSCRIPT
L’ Intégration Continue
Xavier.Warzee@Valtech.Frhttp://warzee.frLe 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
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 »
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
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
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
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)
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é
top related