Your SlideShare is downloading. ×
0
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Principes de L'intégration Continue
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Principes de L'intégration Continue

3,533

Published on

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

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×