Principes de L'intégration Continue

3,939
-1

Published on

0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,939
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Principes de L'intégration Continue

  1. 1. L’ Intégration Continue Xavier.Warzee@Valtech.Fr http://warzee.fr Le 9 Octobre 2007
  2. 2. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion
  3. 3. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion
  4. 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. 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. 6. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion
  7. 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. 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. 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. 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. 11. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion
  12. 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. 13. Processus d’intégration
  14. 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. 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. 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. 17. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code Conclusion
  18. 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. 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. 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. 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. 22. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code La solution Cruisecontrol Conclusion
  23. 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. 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. 25. 3 développeurs pendant 6 mois = 980 builds ( 8 / jours )
  26. 26. La solution CruiseControl > l’écosysteme Extension Firefox Widgets • Widget Apple • Widget Yahoo Windows SysTray • JCCTray, CCTray (.Net)
  27. 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. 28. Intégration continue >Agenda Motivations Principes Processus d’intégration continue Focus sur l’inspection du code La solution Cruisecontrol Conclusion
  29. 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. 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é

×