intégration continue enjeux, outils et bénéfices Philippe ENSARGUET Orange Business Services IT&L@BS Resp. du centre de compétences «Architecture et expertise technique du SI» Direction Technique Nationale philippe.ensarguet@orange-ftgroup.com Thierry CARRE Orange Business Services IT&L@BS Architecte applicatif thierry.carre@orange-ftgroup.com
objet de l intervention > positionner la thématique de l intégration continue > montrer le lien au processus et à la stratégie de build > définir les concepts de l intégration continue > analyser les critères de choix d une solution en environnement Java > comparer CruiseControl, Continuum et Hudson > illustrer par la pratique des mises en situation > dégager le bénéfices et les points de vigilance d une telle pratique > proposer des bonnes pratiques et identifier des anti-patterns > mettre en exergue nos pratiques et réflexions sur le domaine
nuage de tags Jeff Sutherland Agile manifesto Design Patterns Kent Beck Martin Fowler Ward cunningam Ken Schwaber Référentiels POM archetype Build Forge logicielle Reproductiblité Artefact Maven2 Qualité Adaptatif KISS OCP TDD FDD XP SCM DRY Implémentation YAGNI Conception simple Mélée quotidienne Project Owner Sprint Refactorisation Propriété collective Tests unitaires Hudson SRP Backlog Scrum Intégration continue Continuum jmock EasyMock IDE Selenium junit outillage Checkstyle Scrum Master Cruisecontrol Findbugs jdepend PMD
agenda > en aparté > stratégie et processus de build comme point de départ > principes et enjeux de l intégration continue > éléments de conclusion > critères de choix et analyse de moteurs d intégration continue en environnement Java > bonnes pratiques et anti-patterns > éléments de conclusion
en aparté intégration continue introduction, bonnes pratiques et feuille de route
positionnement de la thématique > l intégration est une activité complexe > l effort augmente significativement avec : - le nombre d artéfacts, - les tests d intégration et leurs définitions, - le nombre d erreurs, - la qualité du code, - - le temps écoulé depuis la dernière intégration. > l intégration continue est apparue avec les pratiques XP avec comme motivation de remplacer les grosses et longues phases d intégration en fin de projet par des phases plus petites et plus fréquentes > l idée principale : - réduire au minimum l effort d intégration de l application sans altérer le processus de développement logiciel
la «fabrique» IT&L@BS ingrédients et ustensiles de notre démarche traçabilité sur la vie du projet reproductibilité de l environnement de compilation reproductibilité de l environnement technique Processus Intégration continue Environnement de build Socle technique SCM Référentiel de librairies GForge Codex Qualimétrie et tableau de bord
stratégie et processus de build comme point de départ intégration continue introduction, bonnes pratiques et feuille de route
build ou construction du logiciel > pas de définition (totalement) précise! > le build peut aller de la compilation, incrémentale, à la génération d un package en passant par la génération de fichiers de source, le lancement de tests (unitaires, d intégration ), l analyse du code source, la génération d un site web et de rapports > d une certaine manière, le build englobe l ensemble des actions souhaitées prenant en entrée des fichiers sources pour produire un résultat souhaité. > généralement, nous attendons d un outil de build qu il puisse automatiser et optimiser ces actions.
la problématique du build reproductibilité dans le temps et dans l espace dans l espace pic Les builds sur les postes p0, p1, pj, pic doivent être identiques Par exemple, il faut pouvoir reproduire le build sur l ensemble des postes de l équipe, du serveur d intégration continue pj p1 p0 Les builds aux temps t0, t1, ti doivent être identiques t0 t1 ti dans le temps Par exemple, il faut pouvoir à tout moment reproduire le build d une version taggée Il faut aussi définir ce que veut dire identique
la problématique du build de nombreuses influences Le build est une opération qui paraît simple, mais dans les faits c est une problématique compliquée et nous ne disposons toujours pas de solution qui permette d assurer cela Outils de build options de compilation compilateur Variables d environnemen t OS Dépendances ressources code source Fichiers sources Facteurs humains Plateforme d exécution Repositories maven Base de données xml schemas wsdl Ressources externes build artefacts
Maven2, le fil rouge > permettre aux personnes de se concentrer sur leur tâche principale plutôt que de passer du temps à régler des problèmes annexes liés au build > «standardiser" la manière de travailler ce qui facilite la réutilisation et le passage d'un projet à un autre > améliorer la qualité du code par une approche d'intégration continue
Maven2, le fil rouge > Maven2 est un outil de gestion de projet qui en tant que tel nous assiste dans de nombreuses tâches - build, tests, intégration continue, documentation, reporting, gestion des sources, gestion de l équipe, diffusion, > convention plutôt que configuration - règle du 80/20 - les opérations de builds suivent un pattern uniformité et reproductibilité du processus - extension par plug-ins
à retenir! >Pas d intégration continue sans stratégie de build totalement opérationnelle
principes et enjeux intégration continue introduction, bonnes pratiques et feuille de route
l intégration continue > l'intégration continue est un processus d'automatisation des tâches récurrentes liés à l'environnement de développement, telles que la construction, le déploiement, l'exécutions des tests unitaires et d'intégration, etc. > l'intérêt de cette automatisation réside dans sa fréquence d'exécution, qui doit au moins être quotidienne. > on dispose ainsi régulièrement de nouvelles versions d'une application et de l'état actuel du projet.
Module 1 Module 2 intégration Continue la problématique Module i Développement Intégration Source: http://www.agitar.com/solutions/why_unit_testing.html Les 5% de bugs découverts après la release représentent 95% des coûts de correction
Module 1 Module 2 Module i intégration Continue la problématique Développement Intégration Les 5% de bugs découverts après la release représentent 95% des coûts de correction Intégration Continue Intégration Intégration Détecter au plus tôt les problèmes pour les corriger au plus tôt Intégration Intégration Intégration Intégration Module1 Module2 Modulei
intégration continue un processus d orchestration > l'intégration continue ne se résume pas seulement à la simple mise en œuvre d'un outil permettant d'automatiser la compilation. > il s'agit davantage d'un processus qui va orchestrer le quotidien des développeurs autours de trois composants : - un outil de construction automatisée tel qu'ant ou Maven2, permettant aussi bien au développeur qu'à l'outil d'intégration continue de construire tout ou partie du système. - un unique système de gestion de sources, tel que CVS ou Subversion, contenant les sources et l'historique des modifications apportées par les développeurs sur le système. A chaque mise à jour, le serveur d'intégration continue charge les modifications et exécute la construction complète du système. - un serveur d'intégration continue, tels que Hudson, Bamboo, Continuum ou Cruise Control. Son rôle est de détecter les mises à jour sur le système de gestion de sources, d'exécuter le cas échéant la construction du système et de notifier l'équipe de développement du résultat.
le processus d intégration continue 1 Développement, correction d une fonctionnalité Spécifications Implémentation de la fonctionnalité ou correction et des tests unitaires 4 Historisation et publication des résultats Compilation privée du module ou projet Enregistrement dans le SCM 2 Détection du besoin d intégration Enregistrement des résultats Evènements envoyés par le SCM Génération des rapports Scrutation du SCM Notifications des résultats Périodique, manuelle Publication de l artéfact 3 Intégration Mise à jour depuis le SCM Compilation du projet Tests unitaires et d intégration Analyses de la qualité de code
Intégration continue l outillage Production de code Accueil d un nouveau développeur Enregistrement des modifications Gestion de dépendances Compilations privées Gestion de configuration Outil de compilation pom.xml Détection du besoin d intégration Chargement de modifications Intégration continue Compilation, tests Analyses de code
détail du processus * Notifications Evènements de déclenchement Appel d actions Rapports Artéfacts Notifications comment : SMTP, Jabber, Communicator, RSS, etc. Intervention qui : liste de humaine destinataires, depuis plusieurs l'outil listes d'icpossibles; le(s) dernier(s) comiters Script quand (Bat, : Systématiquement Shell) après chaque build, Conditionnel (échec, qualité de code ) Périodique (CRON) Rapports Script Ant Détection analyse de static modifications du code (PMD, dans checkstyle, SCM Findbugs), (polling) Par Script dépendance rapport Maven de tests 1 (tests unitaires, couverture ), Publication Script suivi Maven des d'une modifications 2 API (Web du SCM Service, JMS, Jabber...) historique des résultats de builds, Analyse évoluée des résultats de builds Modifications historique des dans métriques, SCM Dashboard, (notification) etc. Artefacts lien vers le résultat du build (JAR, site web )
critères de choix et analyse de moteurs d intégration continue en environnement Java intégration continue introduction, bonnes pratiques et feuille de route
intégration continue critères de choix fonctionnels Notifications Mails, Jabber, Lava lamps Evènements de déclenchement Appel d actions Rapports Tests unitaires, qualité de code : PMD, Findbugs Périodique, manuel, détection de modifications dans le SCM Outils de build : Ant, Maven, Shell Artéfacts Jar, War Détection du besoin d intégration Intégration Historisation et publication des résultats
intégration continue critères de choix techniques > exigences techniques - Environnements d exécution : Windows, Linux - Mode d exécution : application WEB, service - Conteneurs WEB supportés : Tomcat, Websphere - Tout autres critères liés à l environnement technique où sera utilisé le serveur d intégration continue. > exigences de contraintes opérationnelles - Sécurité : authentification, contrôle d accès - Administration : installation, configuration, exploitation - Utilisation : ergonomie, prise en main - Fournisseur : coût, licence, maturité
intégration continue illustration >Choix d'un serveur d'intégration continue (FT ROSI/FT R&D/OBS IT&L@BS) - Réalisation d'une grille d'évaluation (350 critères) - Audits de 10 projets pour remplir la grille et pour identifier les différentes pratiques
CruiseControl > une des premières solutions d intégration continue (2001) - développée par la société ThoughtWorks > solution Open Sources sous licence BSD > particularités : - Principalement destiné aux projets Java, CC peut être utilisé pour des projets.net et C++ - Son extensibilité : tout est plugins - Haut niveau de configuration des fonctionnalités
architecture de CruiseControl Rapports Legacy Reporting Dashboard XML Notifications Evènements de déclenchement Conteneur WEB Build Loop Appel d actions Artéfacts Serveur d intégration continue
CruiseControl
Apache Continuum > développée par la communauté Apache - solution Open Sources sous licence Apache version 2 > particularités : - pour des projets Java utilisant Maven 1 et 2, Ant, Script - intègre parfaitement les projets Maven 2 chargement et configuration des projets directement depuis leur pom.xml projet simple et multi-modules - pas d extension par plugin
architecture de Continuum Continuum Notifications Evènements de déclenchement Conteneur WEB Maven Rapports Artéfacts Appel d actions Serveur d intégration continue
Apache Continuum
Hudson > une des solutions les plus récentes - communauté la plus active - projet Open Sources soutenu par Sun Microsystem, sous licence DamageControl Organisation License > particularités : - développement agressif : plusieurs versions par semaine - simplicité d installation et de mise à jour Déploiement d une application Web Configuration d Hudson et des projets est effectuée depuis l outil Stockage de la configuration dans un dossier de notre choix - ergonomie conviviale et intuitive rapidité de prise en main interprétation des résultats
architecture de Hudson Hudson Notifications Rapports Evènements de déclenchement Conteneur WEB Artéfacts Appel d actions Serveur d intégration continue
Hudson
à retenir! CruiseControl Continuum Hudson >Maturité, stabilité >Bonne documentation >Support d outils de compilation pour d autre langage que Java >Son extensibilité Avantages >Configuration des projets Maven2 depuis le pom.xml >Gestion des versions >Mutualisation de la configuration entre projet >Interprétation des résultats aisée >Facilité de mise en œuvre et de prise en main, navigation intuitive >Aide en ligne et bonne documentation >Communauté réactive Inconvénients >Installation non standard complexe >Utilisation moyennement intuitive, la prise en main de l outil demande un effort >Présentation des résultats assez austère >Peu de rapports et pas de lien vers ceux générés par les plugins Maven >Historique textuel des compilations >Pas d extension par plugin possible >Documentation incomplète >Manque de maturité de certaines fonctionnalités : intégration des résultats de build pour d autres langages >Pas de mutualisation de configuration
conclusion sur les outils analysés > CruiseControl : - outil mature et complet, pas seulement en Java, - MAIS complexe dans sa mise en œuvre, sa prise en main, l interprétation des résultats, > Continuum : - limitation à l automatisation de compilation uniquement > Hudson : - bonne impression générale - simplicité de mise en œuvre ne se fait pas au détriment des fonctionnalités - qualité des rapports permettant une bonne interprétation
bonnes pratiques et anti-patterns intégration continue introduction, bonnes pratiques et feuille de route
pratiques à privilégier et anti-patterns > détecter et résoudre les problèmes au plus tôt - commiter du code qui marche fréquemment exécuter des builds privés développer de petites tâches commenter chaque commit - valider le build par des tests (unitaires et fonctionnels) qui passent à 100% pas de test = pas d erreur, les tests doivent être pertinents prendre en compte la couverture de test - intégrer après chaque commit temps de build < 10 min distinguer les tests unitaires des tests d intégration, fonctionnels, etc. exécuter une intégration complète au moins une fois par jour - corriger les échecs de builds immédiatement! Stopper les commits! - adapter le système de notification à l équipe
pratiques à privilégier et anti-patterns > reproduire le build dans le temps et l espace - le build doit être automatisé au maximum - l environnement de build doit être propre privilégier le checkout, au moins pour l intégration complète quotidienne nettoyer le dépôt local de Maven selon les cas, intégrer sur différentes plateforme - dans certains l utilisation d un miroir du SCM peut-être utile - anti-patterns : absence de référentiel de sources intégration sur le poste de développement utilisation de scripts de build différents entre le développement et l intégration
pratiques à privilégier et anti-patterns > l amélioration de la qualité de code - l analyse de code est à mettre en place dès le début du projet - se fixer des objectifs raisonnables - automatiser les tâches de relecture - anti-patterns : les objectifs trop ambitieux peuvent décourager sélectionner les règles prévoir du temps dédier à l amélioration de la qualité de code sentiment de flicage : les métriques ne sont pas une note! en réfléchissant un peu, il est très simple de contourner les outils d analyse excès de confiance de bonnes métriques n impliquent pas que l application ne comporte pas de bogues, ou que de mauvaises pratiques n ont pas été implémentées.
éléments de conclusion intégration continue introduction, bonnes pratiques et feuille de route
le bénéfice, la réduction des risques la gestion du temps > contrairement à une intégration programmée en vue d'une livraison, et dont la durée est difficilement prévisible, l'intégration continue est fondue dans la phase de développement. > il n'y a plus de longues phases d'intégration, à tout moment l'état du système est connu.
le bénéfice, la réduction des risques fiabilité > un projet testé tout au long de son développement a toutes les chances de contenir moins de bogues. > selon la pertinence des jeux de tests, davantage de bogues sont détectés au plus tôt, donc plus facilement identifiables et rapidement corrigés puisqu'ils sont liés aux récentes modifications le SCM est utilisé comme simple support d'archivage. Le projet n'est pas dans un état stable et ceci est la dernière préoccupation des développeurs. les échecs sont immédiatement corrigés, commits fréquents.
le bénéfice, la réduction des risques la qualité de code > les bogues ont la fâcheuse tendance à se cumuler. Plus il y en a, plus il est difficile de supprimer chacun d'entre eux. - Ceci est en partie dû aux interactions entres les bogues, où un échec est le résultat de plusieurs erreurs, rendant chaque erreur plus difficile à trouver. > l'effet psychologique sur le développeur n'est pas négligeable, d'autant plus si l'on se trouve dans un contexte d'urgence. -la qualité des corrections est bien souvent délaissée au profit de la rapidité de mise en œuvre. -pour éviter de telles situations, dans une démarche d'intégration continue, LA tâche prioritaire lorsqu'un bogue est découvert est de le corriger.
le bénéfice, la réduction des risques réactivité > une version est toujours disponible, permettant ainsi les fréquents déploiements et mises à jour. > l'intégration continue se prête alors parfaitement au cycle de développement collaboratif : - les retours clients sur les fonctionnalités du système ainsi que leurs prises en comptes sont plus rapides.
mais aussi l amélioration de la productivité des développeurs Intégration Continue compilation tests unitaires packaging tests d'intégration site web 2' 4' 1' 8' 10' x' x 20 x 20 x 15 x 15 x 2 x compilation tests unitaires 2' 4' x 40 30 x 20 15 compilation tests unitaires 2' 4' x 25 20 x 25 20 compilation tests unitaires 2' 4' x 45 35 x 10 5 packaging 1' x 15 packaging 1' x 13 packaging 1' x 15 tests d'intégration 8' x 02 tests d'intégration 8' x 24 tests d'intégration 8' x 0 site web 10' x 02 site web 10' x 1 site web 10' x 0 x' x x' x x' x
témoignages et retours d expérience > Étude et état de l art de moteurs d intégration continue - Grilles d analyse et d évaluation (>350 critères) - Déploiement de POM simple module, POM Multi-modules, POM multimodules complexe > État des lieux et retour d expérience sur 10 projets opérationnels > Déploiement de la «forge» sur - Un projet à l international - Deux projets nationaux multi-sites (>25 personnes) - Un projet multi-site et multi-prestataire - Tout nouveau projet de plus d une centaine de jours amener l intégration continue comme une pratique à part entière un mode de diffusion «viral» au sein des équipes
des opportunités mais vigilance! > la mise en place de l intégration continue n est pas une opération anodine > Il faut prendre en compte les aspects humains (non traité dans la présentation) - si l intégration continue est vécu comme un flicage alors les développeurs trouveront un contournement qui fera perdre tout le bénéfice de l intégration continue (voire pire). Par exemple, ne plus commiter > de la même manière, être responsable de la qualité peut être une tâche très difficile à réaliser si l équipe ne joue pas le jeu - la personne aura quotidiennement à rappeler à l ordre les développeurs et sera perçue négativement > il ne faut pas oublier l objectif initiale qui a pour but d améliorer le développement. > tout le monde doit se sentir concerné! - les succès et les échecs doivent être vécus de façon commune et non de façon individuelle.
questions?
Références web et bibliographie > intégration continue vue par M. Fowler > http://www.martinfowler.com/articles/continuousintegration.html > Hudson > https://hudson.dev.java.net/ > Continuum > http://continuum.apache.org/ > CruiseControl > http://cruisecontrol.sourceforge.net/ > Bamboo > http://www.atlassian.com/software/bamboo/