Jenkins : Le guide complet

  • Published on
    05-Jan-2017

  • View
    235

  • Download
    5

Transcript

  • Copyright .................................................................................................................... xxiAvant-propos ............................................................................................................. xxiiiPrface ....................................................................................................................... xxv

    1. Audience ........................................................................................................ xxv2. Organisation du livre ........................................................................................ xxv3. Jenkins ou Hudson? .......................................................................................... xxv4. Conventions sur les polices ............................................................................... xxvi5. Conventions de ligne de commande .................................................................... xxvi6. Contributeurs ................................................................................................. xxvii

    6.1. Les traducteurs du prsent livre en franais .............................................. xxviii7. L'quipe de revue ............................................................................................ xxix8. Sponsors du livre ............................................................................................ xxix

    8.1. Wakaleo Consulting .............................................................................. xxix8.2. CloudBees ........................................................................................... xxix8.3. Odd-e .................................................................................................. xxx

    9. Utilisation des exemples de code ......................................................................... xxx10. Safari Books Online .................................................................................... xxxi11. Comment nous contacter ................................................................................. xxxi12. Remerciements ............................................................................................. xxxii

    1. Introduction Jenkins .................................................................................................. 11.1. Introduction ..................................................................................................... 11.2. Les fondamentaux de l'Intgration Continue ........................................................... 11.3. Introduction Jenkins (n Hudson) ...................................................................... 31.4. De Hudson Jenkins Un rapide historique ........................................................ 31.5. Dois-je utiliser Jenkins ou Hudson? ...................................................................... 41.6. Mettre en place l'Intgration Continue au sein de votre organisation ............................ 5

    1.6.1. Phase 1 Pas de serveur de build ............................................................ 51.6.2. Phase 2 Builds quotidiens .................................................................... 61.6.3. Phase 3 Builds quotidiens et tests automatiss basiques .............................. 61.6.4. Phase 4 Arrive des mtriques .............................................................. 61.6.5. Phase 5 Prendre les tests au srieux ....................................................... 61.6.6. Phase 6 Tests d'acceptance automatiss et un dploiement plus automatis..................................................................................................................... 61.6.7. Phase 7 Dploiement Continu ................................................................ 7

    1.7. Et maintenant ? ................................................................................................. 72. Vos premiers pas avec Jenkins ....................................................................................... 9

    2.1. Introduction ..................................................................................................... 92.2. Prparation de votre environnement ...................................................................... 9

    2.2.1. Installation de Java ................................................................................ 102.2.2. Installation de Git ................................................................................. 112.2.3. Configurer un compte GitHub ................................................................. 112.2.4. Configurer les clefs SSH ........................................................................ 122.2.5. Forker le dpt des exemples .................................................................. 12

  • iv

    2.3. Dmarrer Jenkins ............................................................................................ 142.4. Configuring the Tools ...................................................................................... 18

    2.4.1. Configuring Your Maven Setup ............................................................... 192.4.2. Configuring the JDK ............................................................................. 202.4.3. Notification .......................................................................................... 212.4.4. Setting Up Git ...................................................................................... 21

    2.5. Your First Jenkins Build Job ............................................................................. 222.6. Your First Build Job in Action .......................................................................... 272.7. More ReportingDisplaying Javadocs ................................................................ 342.8. Adding Code Coverage and Other Metrics ........................................................... 362.9. Conclusion ..................................................................................................... 42

    3. Installer Jenkins ......................................................................................................... 433.1. Introduction .................................................................................................... 433.2. Tlcharger et installer Jenkins .......................................................................... 433.3. Prparation d'un serveur de build pour Jenkins ...................................................... 463.4. Le rpertoire de travail de Jenkins ...................................................................... 483.5. Installer Jenkins sur Debian ou Ubuntu ................................................................ 493.6. Installer Jenkins sur Redhat, Fedora ou CentOS .................................................... 503.7. Installer Jenkins sur SUSE ou OpenSUSE ............................................................ 513.8. Excuter Jenkins comme une application autonome ................................................ 523.9. Running Jenkins Behind an Apache Server .......................................................... 563.10. Running Jenkins on an Application Server .......................................................... 573.11. Memory Considerations .................................................................................. 583.12. Installing Jenkins as a Windows Service ............................................................ 593.13. Whats in the Jenkins Home Directory ............................................................... 633.14. Backing Up Your Jenkins Data ........................................................................ 673.15. Upgrading Your Jenkins Installation .................................................................. 673.16. Conclusion ................................................................................................... 68

    4. Configurer votre serveur Jenkins .................................................................................. 694.1. Introduction .................................................................................................... 694.2. Le tableau de bord de configuration L'cran Administrer Jenkins .......................... 694.3. Configurer l'environnement systme .................................................................... 724.4. Configurer les proprits globales ....................................................................... 734.5. Configurer vos JDKs ........................................................................................ 744.6. Configurer vos outils de build ............................................................................ 77

    4.6.1. Maven ................................................................................................. 774.6.2. Ant ..................................................................................................... 784.6.3. Langage de scripts Shell ......................................................................... 79

    4.7. Configurer vos outils de gestion de version .......................................................... 794.7.1. Configurer Subversion ........................................................................... 804.7.2. Configurer CVS .................................................................................... 80

    4.8. Configurer le serveur de messagerie lectronique ................................................... 804.9. Configurer un Proxy ........................................................................................ 81

  • v

    4.10. Conclusion ................................................................................................... 825. Configurer vos tches de Build .................................................................................... 83

    5.1. Introduction .................................................................................................... 835.2. Tches de Build Jenkins ................................................................................... 835.3. Crer une tche de build free-style ..................................................................... 84

    5.3.1. Options Gnrales ................................................................................. 845.3.2. Options avances du projet ..................................................................... 86

    5.4. Configurer la Gestion du Code Source ................................................................ 885.4.1. Travailler avec Subversion ...................................................................... 885.4.2. Travailler avec Git ................................................................................ 91

    5.5. Dclencheurs de build .................................................................................... 1035.5.1. Dclencher une tche de build lorsqu'une autre tche de build se termine ........ 1045.5.2. Tches de build priodiques .................................................................. 1045.5.3. Scruter le SCM ................................................................................... 1055.5.4. Dclencher des builds distance ............................................................ 1065.5.5. Construction manuelle de tches ............................................................ 108

    5.6. Les tapes de builds ....................................................................................... 1085.6.1. Les tapes de build Maven .................................................................... 1095.6.2. Les tapes de build Ant ........................................................................ 1115.6.3. Excuter une commande Batch Shell ou Windows ..................................... 1115.6.4. Utiliser les variables denvironnement Jenkins dans vos builds ..................... 1135.6.5. Excuter des scripts Groovy .................................................................. 1155.6.6. Construire des projets dans dautres langages ............................................ 117

    5.7. Les actions la suite du build .......................................................................... 1175.7.1. Rapport sur les rsultats de tests ............................................................. 1175.7.2. Archiver les rsultats de build ................................................................ 1185.7.3. Notifications ....................................................................................... 1225.7.4. Construire dautres projets .................................................................... 122

    5.8. Dmarrer votre nouvelle tche de build .............................................................. 1235.9. Travailler avec des tches de build Maven .......................................................... 123

    5.9.1. Construire ds lors quune dpendance SNAPSHOT est construite ................ 1245.9.2. Configurer un build Maven ................................................................... 1245.9.3. Les actions la suite du build ................................................................ 1265.9.4. Dployer vers un gestionnaire de dpt dentreprise ................................... 1275.9.5. Dployer vers des gestionnaires de dpt dentreprise commerciales .............. 1305.9.6. Grer les modules ............................................................................... 1315.9.7. Les tapes de build supplmentaires dans votre tche de build Maven ............ 132

    5.10. Utiliser Jenkins avec dautres langages ............................................................. 1325.10.1. Construire des projets avec Grails ......................................................... 1335.10.2. Construire des projets avec Gradle ........................................................ 1345.10.3. Construire des projets avec Visual Studio MSBuild .................................. 1375.10.4. Construire des projets avec NAnt .......................................................... 1385.10.5. Construire des projets avec Ruby et Ruby on Rails ................................... 139

  • vi

    5.11. Conclusion .................................................................................................. 1416. Tests automatiss ..................................................................................................... 143

    6.1. Introduction .................................................................................................. 1436.2. Automatisez vos tests unitaires et d'intgration .................................................... 1446.3. Configuration des rapports de test dans Jenkins ................................................... 1456.4. Afficher les rsultats de test ............................................................................. 1476.5. Ignorer des tests ............................................................................................ 1506.6. Couverture de code ........................................................................................ 152

    6.6.1. Mesurer la couverture de code avec Cobertura .......................................... 1536.6.2. Mesurer la couverture de code avec Clover .............................................. 162

    6.7. Tests d'acceptation automatiss ......................................................................... 1646.8. Tests de performance automatiss avec JMeter .................................................... 1676.9. A l'aide ! Mes tests sont trop lents ! .................................................................. 175

    6.9.1. Ajouter plus de matriel ....................................................................... 1756.9.2. Lancer moins de tests d'intgration/fonctionnels ........................................ 1766.9.3. Excutez vos tests en parallle ............................................................... 176

    6.10. Conclusion .................................................................................................. 1777. Scuriser Jenkins ...................................................................................................... 179

    7.1. Introduction .................................................................................................. 1797.2. Activer la scurit dans Jenkins ........................................................................ 1797.3. Scurit simple dans Jenkins ............................................................................ 1807.4. Domaines de scurit Identifier les utilisateurs Jenkins ...................................... 181

    7.4.1. Utiliser la base de donnes intgre Jenkins ........................................... 1817.4.2. Utiliser un annuaire LDAP .................................................................... 1857.4.3. Utiliser Microsoft Active Directory ......................................................... 1867.4.4. Utiliser les utilisateurs et les groupes Unix ............................................... 1877.4.5. Dlguer au conteneur de Servlet ........................................................... 1877.4.6. Utiliser Atlassian Crowd ....................................................................... 1887.4.7. S'intgrer avec d'autres systmes ............................................................ 190

    7.5. Autorisation Qui peut faire quoi ................................................................... 1917.5.1. Scurit base sur une matrice ............................................................... 1927.5.2. Scurit base sur le projet .................................................................... 1967.5.3. Scurit base sur les rles .................................................................... 198

    7.6. Audit Garder la trace des actions utilisateurs ................................................... 2017.7. Conclusion ................................................................................................... 204

    8. Notification ............................................................................................................. 2058.1. Introduction .................................................................................................. 2058.2. Notification par email ..................................................................................... 2058.3. Notification par email avance ......................................................................... 2078.4. Revendiquer des builds ................................................................................... 2108.5. Flux RSS ..................................................................................................... 2118.6. Radars de build ............................................................................................. 2128.7. Messagerie instantane .................................................................................... 214

  • vii

    8.7.1. Notification par IM avec Jabber ............................................................. 2148.7.2. Notification avec IRC .......................................................................... 219

    8.8. Notification par IRC ....................................................................................... 2198.9. Notificateurs de bureau ................................................................................... 2238.10. Notifications via Notifo ................................................................................. 2278.11. Notifications vers mobiles .............................................................................. 2298.12. Notifications via SMS ................................................................................... 2308.13. Faire du bruit .............................................................................................. 2328.14. Appareils de retour extrmes .......................................................................... 2348.15. Conclusion .................................................................................................. 236

    9. Qualit du Code ....................................................................................................... 2379.1. Introduction .................................................................................................. 2379.2. La qualit du code dans votre processus de build ................................................. 2389.3. Les outils danalyse de qualit du code populaires pour Java et Groovy .................... 239

    9.3.1. Checkstyle ......................................................................................... 2399.3.2. PMD/CPD .......................................................................................... 2429.3.3. FindBugs ........................................................................................... 2469.3.4. CodeNarc ........................................................................................... 248

    9.4. Rapports de problmes de qualit de code avec le plugin Violations ......................... 2499.4.1. Travailler avec des tches de build free-style ............................................ 2509.4.2. Travailler avec des tches de build Maven ............................................... 253

    9.5. Utiliser les rapports Checkstyle, PMD, et FindBugs .............................................. 2559.6. Les rapports sur la complexit du code .............................................................. 2589.7. Les rapports sur les tches ouvertes ................................................................... 2599.8. Intgration avec Sonar .................................................................................... 2619.9. Conclusion ................................................................................................... 265

    10. Builds avancs ....................................................................................................... 26710.1. Introduction ................................................................................................. 26710.2. Tches de build paramtres .......................................................................... 267

    10.2.1. Crer des tches de build paramtres .................................................... 26710.2.2. Adapter vos build pour travailler avec des scripts de builds paramtrs ......... 26910.2.3. Types de paramtres plus avancs ......................................................... 27110.2.4. Construire partir d'un tag Subversion .................................................. 27310.2.5. Raliser un build partir d'un tag Git .................................................... 27410.2.6. Dmarrer une tche de build paramtre distance ................................... 27510.2.7. Historique des tches de build paramtres ............................................. 275

    10.3. Dclencheurs paramtrs ............................................................................... 27610.4. Tches de build multiconfiguration .................................................................. 279

    10.4.1. Configurer un build multiconfiguration .................................................. 27910.4.2. Configurer un axe Esclave ................................................................... 28010.4.3. Configurer un axe JDK ....................................................................... 28110.4.4. Axe personnalis ............................................................................... 28210.4.5. Excuter un Build Multiconfiguration .................................................... 282

  • viii

    10.5. Gnrer vos tches de build Maven automatiquement .......................................... 28510.5.1. Configurer une tche .......................................................................... 28610.5.2. Rutiliser une configuration de tche par hritage ..................................... 28810.5.3. Le support des plugins ........................................................................ 29010.5.4. Les tches Freestyle ........................................................................... 293

    10.6. Coordonner vos builds .................................................................................. 29310.6.1. Les builds parallles dans Jenkins ......................................................... 29310.6.2. Graphes de dpendance ....................................................................... 29410.6.3. Jonctions .......................................................................................... 29510.6.4. Plugin Locks and Latches .................................................................... 297

    10.7. Pipelines de build et promotions ..................................................................... 29810.7.1. Gestion des releases Maven avec le plugin M2Release .............................. 29810.7.2. Copier des artefacts ............................................................................ 30110.7.3. Promotions de build ........................................................................... 30510.7.4. Agrger des rsultats de tests ............................................................... 31310.7.5. Pipelines de Build .............................................................................. 314

    10.8. Conclusion .................................................................................................. 31711. Builds distribus ..................................................................................................... 319

    11.1. Introduction ................................................................................................. 31911.2. L'Architecture de build distribue de Jenkins ..................................................... 31911.3. Stratgies Matre/Esclave dans Jenkins ............................................................. 320

    11.3.1. Le matre dmarre l'agent esclave en utilisant SSH ................................... 32111.3.2. Dmarrer l'agent esclave manuellement via Java Web Start ........................ 32511.3.3. Installer un esclave Jenkins en tant que service Windows ........................... 32811.3.4. Dmarrer le noeud esclave en mode Headless .......................................... 32911.3.5. Dmarrer un esclave Windows en tant que service distant .......................... 329

    11.4. Associer une tche de build avec un esclave ou un groupe d'esclaves ...................... 33011.5. Surveillance des noeuds ................................................................................ 33211.6. Cloud computing .......................................................................................... 333

    11.6.1. Utiliser Amazon EC2 ......................................................................... 33311.7. Utiliser le service CloudBees DEV@cloud ........................................................ 33811.8. Conclusion .................................................................................................. 339

    12. Dploiement automatis et livraison continue ............................................................... 34112.1. Introduction ................................................................................................. 34112.2. Mise en oeuvre du dploiement automatis et continu ......................................... 342

    12.2.1. Le script de dploiement ..................................................................... 34212.2.2. Mises jour de base de donnes ........................................................... 34212.2.3. Tests fumigatoires .............................................................................. 34512.2.4. Revenir sur des changements ............................................................... 345

    12.3. Dployer vers un serveur d'application ............................................................. 34612.3.1. Dployer une application Java .............................................................. 34612.3.2. Dployer des applications base de scripts telles Ruby et PHP ................... 356

    12.4. Conclusion .................................................................................................. 359

  • ix

    13. Maintenir Jenkins ................................................................................................... 36113.1. Introduction ................................................................................................. 36113.2. Surveillance de l'espace disque ....................................................................... 361

    13.2.1. Utiliser le plugin "Disk Usage" ............................................................ 36213.2.2. Disk Usage et les projets Jenkins de type Apache Maven ........................... 364

    13.3. Surveiller la charge serveur ............................................................................ 36513.4. Sauvegarde de votre configuration ................................................................... 367

    13.4.1. Fondamentaux de la sauvegarde Jenkins ................................................. 36713.4.2. Utilisation du Backup Plugin ............................................................... 36913.4.3. Des sauvegardes automatises plus lgres ............................................. 371

    13.5. Archiver les tches de build ........................................................................... 37213.6. Migrer les tches de build .............................................................................. 37313.7. Conclusion .................................................................................................. 377

    A. Automatiser vos tests unitaires et dintgration ............................................................. 379A.1. Automatiser vos tests avec Maven .................................................................... 379A.2. Automatiser vos tests avec Ant ........................................................................ 384

    Index ......................................................................................................................... 389

  • List of Figures2.1. Installer Java .......................................................................................................... 102.2. Crer un compte GitHub ........................................................................................... 122.3. Forker le dpt des exemples de code ......................................................................... 132.4. Excuter Jenkins en utilisant Java Web Start partir du site web du livre ........................... 152.5. Java Web Start tlchargera et excutera la dernire version de Jenkins .............................. 162.6. Java Web Start excutant Jenkins ............................................................................... 162.7. La page de dmarrage Jenkins ................................................................................... 172.8. The Manage Jenkins screen ....................................................................................... 182.9. The Configure Jenkins screen .................................................................................... 192.10. Configuring a Maven installation .............................................................................. 202.11. Configuring a JDK installation ................................................................................. 212.12. Managing plugins in Jenkins .................................................................................... 222.13. Installing the Git plugin .......................................................................................... 222.14. Setting up your first build job in Jenkins .................................................................... 242.15. Telling Jenkins where to find the source code ............................................................. 252.16. Scheduling the build jobs ........................................................................................ 262.17. Adding a build step ................................................................................................ 262.18. Configuring JUnit test reports and artifact archiving ..................................................... 272.19. Your first build job running ..................................................................................... 282.20. The Jenkins dashboard ............................................................................................ 282.21. A failed build ....................................................................................................... 312.22. The list of all the broken tests .................................................................................. 322.23. Details about a failed test ........................................................................................ 322.24. Now the build is back to normal .............................................................................. 342.25. Adding a new build step and report to generate Javadoc ................................................ 352.26. Jenkins will add a Javadoc link to your build results ..................................................... 362.27. Jenkins has a large range of plugins available ............................................................. 372.28. Adding another Maven goal to generating test coverage metrics ...................................... 382.29. Configuring the test coverage metrics in Jenkins .......................................................... 392.30. Jenkins displays code coverage metrics on the build home page ...................................... 402.31. Jenkins lets you display code coverage metrics for packages and classes ........................... 412.32. Jenkins also displays a graph of code coverage over time .............................................. 423.1. Vous pouvez tlcharger les binaires de Jenkins sur le site web de Jenkins ......................... 443.2. L'assistant de configuration sous Windows ................................................................... 453.3. La page d'accueil de Jenkins ..................................................................................... 463.4. Starting Jenkins using Java Web Start ......................................................................... 603.5. Installing Jenkins as a Windows service ...................................................................... 613.6. Configuring the Jenkins Windows Service ................................................................... 623.7. The Jenkins home directory ....................................................................................... 643.8. The Jenkins jobs directory ........................................................................................ 65

  • xii

    3.9. The builds directory ................................................................................................. 663.10. Upgrading Jenkins from the web interface .................................................................. 684.1. Configurer son installation Jenkins dans l'cran Administrer Jenkins .................................. 704.2. Configuration du systme dans Jenkins ........................................................................ 724.3. Configurer les variables d'environnement dans Jenkins ................................................... 744.4. Utiliser une variable d'environnement configure ........................................................... 744.5. Configuration des JDKs dans Jenkins .......................................................................... 754.6. Installer un JDK automatiquement .............................................................................. 764.7. Configurer Maven dans Jenkins ................................................................................. 774.8. Configurer la variable systme MVN_OPTS ................................................................. 784.9. Configurer Ant dans Jenkins ..................................................................................... 794.10. Configurer un serveur d'email dans Jenkins ................................................................ 804.11. Configurer un serveur d'email pour utiliser un domaine Google Apps ............................... 814.12. Configurer Jenkins pour utiliser un proxy ................................................................... 825.1. Jenkins supporte quatre principaux types de tches de build ............................................. 845.2. Crer une nouvelle tche de build .............................................................................. 855.3. Conserver un build sans limite de temps ...................................................................... 865.4. Pour afficher les options avances, vous devez cliquer sur le bouton Avanc... ..................... 865.5. L'option Empcher le build quand un projet en aval est en cours de build est utile quandun simple commit affecte plusieurs projets dpendants les uns des autres. ................................. 875.6. Jenkins embarque par dfaut le support pour Subversion ................................................. 885.7. Navigateur de code source montrant les changements dans le code qui ont caus le build. ....... 905.8. Configuration systme du plugin Git ........................................................................... 925.9. Remplir une URL de dpt Git .................................................................................. 935.10. Configuration avance d'une URL de dpt Git ........................................................... 945.11. Configuration avance des branches Git construire .................................................... 945.12. Branches et rgions ................................................................................................ 955.13. Choix de la stratgie .............................................................................................. 975.14. Configuration globale de l'excutable de Git ............................................................... 985.15. Navigateur de dpt ............................................................................................... 985.16. Journal de scrutation .............................................................................................. 995.17. Rsultats de la scrutation de Git ............................................................................... 995.18. Dclenchement par Gerrit ...................................................................................... 1005.19. Git Publisher ....................................................................................................... 1015.20. Fusionner les rsultats ........................................................................................... 1025.21. Navigateur de dpt GitHub ................................................................................... 1035.22. Navigateur de dpt GitHub ................................................................................... 1035.23. Il y a de multiples manires de configurer Jenkins pour le dmarrage d'une tche de build.................................................................................................................................. 1035.24. Dclencher une autre tche de build mme si celle-ci est instable. .................................. 1045.25. Dclencher un build via une URL en utilisant un jeton ................................................ 1085.26. Ajouter une tape de build une tche de build Freestyle ............................................ 1105.27. Configurer une tape de build Ant .......................................................................... 111

  • xiii

    5.28. Configurer une tape Excuter un script Shell ........................................................... 1125.29. Ajouter une installation Groovy Jenkins ................................................................. 1165.30. Lancer des commandes Groovy dans le cadre dune tche de build ................................ 1165.31. Lancer des scripts Groovy dans le cadre dune tche de build ....................................... 1175.32. Rapport sur les rsultats de tests ............................................................................. 1185.33. Configurer les artefacts de builds ............................................................................ 1185.34. Les artefacts de build sont affichs sur la page de rsultat dun build et la page daccueildun job ..................................................................................................................... 1195.35. Archiver le code source et un paquet binaire ............................................................. 1215.36. Notification par email ........................................................................................... 1225.37. Crer une nouvelle tche de build Maven ................................................................. 1235.38. Spcifier les goals Maven ...................................................................................... 1255.39. Les tches de build Maven les options avances .................................................... 1255.40. Dployer des artefacts vers un dpt Maven .............................................................. 1275.41. Aprs dploiement, lartefact devrait tre disponible sur votre gestionnaire de dptdentreprise ................................................................................................................. 1285.42. Redployer un artefact .......................................................................................... 1295.43. Dployer vers Artifactory depuis Jenkins .................................................................. 1295.44. Jenkins affiche un lien vers le dpt Artifactory correspondant ...................................... 1305.45. Voir lartefact dploy sur Artifactory ...................................................................... 1305.46. Voir les artefacts dploys et le build Jenkins correspondant dans Artifactory ................... 1315.47. Grer les modules dans une tche de build Maven ...................................................... 1315.48. Configurer des tapes de build Maven supplmentaires ............................................... 1325.49. Ajouter une installation Grails Jenkins ................................................................... 1335.50. Configurer une tape de build Grails ....................................................................... 1345.51. Configurer le plugin Gradle ................................................................................... 1355.52. Configurer une tche de build Gradle ....................................................................... 1375.53. Tche incrmentale de Gradle ................................................................................ 1375.54. Configurer les outils de build .NET avec Jenkins ....................................................... 1385.55. Une tape de build utilisant MSBuild ....................................................................... 1385.56. Une tape de build utilisant NAnt ........................................................................... 1395.57. Une tape de build utilisant Rake ............................................................................ 1405.58. Publier des mtriques de qualit de code pour Ruby et Rails ......................................... 1416.1. Vous configurez votre installation Jenkins dans l'cran Administrer Jenkins ...................... 1456.2. Configurer les rapports de test Maven dans un projet free-style ....................................... 1466.3. Installer le plugin xUnit .......................................................................................... 1466.4. Publier les rsultat de test xUnit ............................................................................... 1476.5. Jenkins affiche la tendance des rsultats de test sur la page d'accueil du projet .................... 1486.6. Jenkins affiche une vue synthtique des rsultats de test ................................................ 1486.7. Les dtails d'un chec de test ................................................................................... 1496.8. Les tendances de temps de build peuvent vous donner un bon indicateur de la rapidit devos tests ..................................................................................................................... 1506.9. Jenkins vous permet de voir combien de temps les tests ont mis pour s'excuter .................. 151

  • xiv

    6.10. Jenkins affiche les tests ignors en jaune .................................................................. 1526.11. Installer le plugin Cobertura ................................................................................... 1586.12. Votre build de couverture de code doit produire les donnes de couverture de code ............ 1596.13. Configurer les mtriques de couverture de code dans Jenkins ........................................ 1596.14. Les rsultats des tests de couverture de code contribuent l'tat du projet sur le tableau debord ........................................................................................................................... 1606.15. Configurer les mtriques de couverture de code dans Jenkins ........................................ 1616.16. Afficher les mtriques de couverture de code ............................................................ 1626.17. Configurer les rapports Clover dans Jenkins .............................................................. 1636.18. Tendance de couverture de code Clover ................................................................... 1646.19. Utilisation de conventions de nommage orientes mtier pour des tests JUnit ................... 1656.20. Installer le plugin HTML Publisher ......................................................................... 1656.21. Publier les rapports HTML .................................................................................... 1666.22. Jenkins affiche un lien spcial sur la page d'accueil de la tche de build pour votre rapport.................................................................................................................................. 1666.23. Le plugin DocLinks vous permet d'archiver des documents HTML et non-HTML ............. 1676.24. Prparer un script de test de performance dans JMeter ................................................. 1696.25. Prparer un script de tests de performance dans JMeter ............................................... 1716.26. Mise en place du build de performance pour s'excuter chaque nuit minuit .................... 1726.27. Les tests de performance peuvent demander de grandes quantits de mmoire .................. 1726.28. Configurer le plugin Performance dans votre tche de build ......................................... 1736.29. Le plugin Jenkins Performance garde une trace des temps de rponse et des erreurs ........... 1736.30. Vous pouvez aussi visualiser les rsultats de performance par requte ............................. 1757.1. Activer la scurit dans Jenkins ................................................................................ 1807.2. La page de connexion Jenkins .................................................................................. 1817.3. La liste des utilisateurs connus de Jenkins .................................................................. 1827.4. Afficher les builds auxquels un utilisateur participe ...................................................... 1827.5. Crer un nouveau compte utilisateur en s'enregistrant ................................................... 1837.6. Synchroniser les adresses email ................................................................................ 1837.7. Vous pouvez aussi grer les utilisateurs Jenkins depuis la page de configuration Jenkins ....... 1847.8. La base de donnes des utilisateurs de Jenkins ............................................................ 1847.9. Configurer LDAP dans Jenkins ................................................................................ 1857.10. Utiliser des groupes LDAP dans Jenkins .................................................................. 1867.11. Slectionner le domaine de scurit ......................................................................... 1887.12. Utiliser Atlassian Crowd comme domaine de scurit Jenkins ....................................... 1897.13. Utiliser Atlassian Crowd comme domaine de scurit Jenkins ....................................... 1897.14. Utiliser les groupes Atlassian Crowd dans Jenkins ...................................................... 1907.15. Utiliser des scripts personnaliss pour grer l'authentification ....................................... 1907.16. Scurit base sur une matrice ................................................................................ 1927.17. Configurer un administrateur .................................................................................. 1937.18. Configurer les autres utilisateurs ............................................................................. 1937.19. Scurit base sur le projet .................................................................................... 1967.20. Configurer la scurit base sur le projet .................................................................. 197

  • xv

    7.21. Voir un projet ..................................................................................................... 1977.22. Configurer les permissions de droit de lecture tendus ................................................. 1987.23. Configurer la scurit base sur les rles .................................................................. 1987.24. Le menu de configuration Grer les rles ................................................................. 1997.25. Grer les rles globaux ......................................................................................... 1997.26. Grer les rles de projets ....................................................................................... 2007.27. Assigner des rles des utilisateurs ......................................................................... 2007.28. Configurer le plugin Audit Trail ............................................................................. 2017.29. Mettre en place l'historique des configurations de tches .............................................. 2027.30. Prsentation de l'historique de configuration des tches ............................................... 2037.31. Voir les diffrences dans l'historique de configuration des tches ................................... 2038.1. Configurer les notifications par email ........................................................................ 2058.2. Configurer les notifications par email avances ........................................................... 2078.3. Configurer les dclencheurs de notification par email ................................................... 2098.4. Message de notification personnalis ......................................................................... 2108.5. Revendiquer un build chou ................................................................................... 2118.6. Flux RSS dans Jenkins ........................................................................................... 2128.7. Crer une vue radar ............................................................................................... 2138.8. Afficher une vue radar ............................................................................................ 2148.9. Installation des plugins Jenkins de messagerie instantane ............................................. 2158.10. Jenkins ncessite son propre compte de messagerie instantane ..................................... 2158.11. Mise en place de notifications de base Jabber dans Jenkins .......................................... 2168.12. Configuration avance Jabber ................................................................................. 2178.13. Messages Jenkins Jabber en action .......................................................................... 2198.14. Installation des plugins Jenkins IRC ........................................................................ 2208.15. Configuration avance des notifications par IRC ........................................................ 2218.16. Configuration avance de notifications par IRC pour une tche de build .......................... 2228.17. Messages de notification par IRC en action ............................................................... 2238.18. Notifications Jenkins dans Eclipse ........................................................................... 2248.19. Connexion de Jenkins dans NetBeans ...................................................................... 2258.20. Lancement de Jenkins Tray Application ................................................................... 2268.21. Excution de Jenkins Tray Application .................................................................... 2278.22. Crer un service Notifo pour votre instance Jenkins .................................................... 2288.23. Configurer les notifications via Notifo dans votre tche de build Jenkins ......................... 2298.24. Recevoir une notification via Notifo sur un iPhone ..................................................... 2298.25. Utiliser l'application iPhone Hudson Helper .............................................................. 2308.26. Envoyer des notifictions SMS via une passerelle SMS ................................................ 2318.27. Recevoir des notifications via SMS ......................................................................... 2328.28. Configurer les rgles de Jenkins Sounds dans une tche de build ................................... 2338.29. Configurer Jenkins Sounds ..................................................................................... 2338.30. Configurer Jenkins Speaks ..................................................................................... 2348.31. Un Nabaztag ....................................................................................................... 2358.32. Configurer votre Nabaztag ..................................................................................... 236

  • xvi

    9.1. Cest facile de configurer les rgles Checkstyle avec Eclipse .......................................... 2409.2. Configurer les rgles PMD dans Eclipse .................................................................... 2439.3. Gnrer les rapports de qualit de code dans un build Maven ......................................... 2509.4. Configurer le plugin violation pour un projet free-style ................................................. 2519.5. Les violations au cours du temps .............................................................................. 2519.6. Les violations pour un build particulier ...................................................................... 2529.7. Configurer le plugin de violations pour un projet free-style ............................................ 2539.8. Configurer le plugin Violations pour un projet Maven. .................................................. 2549.9. Les tches de build Maven de Jenkins comprennent les structures multi-modules de Maven.................................................................................................................................. 2549.10. Activer le plugin Violations pour un module individuel ............................................... 2559.11. Installer les plugins Checkstyle et Static Analysis Utilities. .......................................... 2569.12. Configurer le plugin Checkstyle .............................................................................. 2579.13. Afficher les tendances Checkstyle ........................................................................... 2579.14. Un nuage de point couverture/complexit. ................................................................ 2589.15. Vous pouvez cliquer sur nimporte quel point du graphique pour poursuivre lenqute ........ 2599.16. Configurer le plugin Task Scanner est simple ............................................................ 2609.17. Le graphique de tendances des tches ouvertes .......................................................... 2609.18. Rapport de qualit de code par Sonar. ...................................................................... 2619.19. Jenkins et Sonar ................................................................................................... 2629.20. Configurer Sonar dans Jenkins ............................................................................... 2639.21. Configurer Sonar dans une tche de build ................................................................. 2649.22. Planifier les builds Sonar ....................................................................................... 26410.1. Crer une tche de build paramtre ........................................................................ 26810.2. Ajouter un paramtre la tche de build .................................................................. 26810.3. Ajouter un paramtre la tche de build .................................................................. 26910.4. Dmonstration d'un paramtre de build .................................................................... 26910.5. Ajouter un paramtre la tche de build Maven ........................................................ 27010.6. Diffrents types de paramtres sont disponibles ......................................................... 27110.7. Configurer un paramtre Choix ............................................................................... 27110.8. Configurer un paramtre Run ................................................................................. 27210.9. Configurer un paramtre Fichier ............................................................................. 27210.10. Ajouter des paramtres pour raliser un build partir d'un tag Subversion ...................... 27310.11. Raliser un build partir d'un tag Subversion .......................................................... 27310.12. Configurer un paramtre pour un tag Git ................................................................ 27410.13. Raliser un build partir d'un tag Git ..................................................................... 27510.14. Jenkins stocke les valeurs des paramtres utilises pour chaque build ............................ 27610.15. Tche de build paramtr pour des tests unitaires ..................................................... 27710.16. Ajouter un dclencheur paramtr une tche de build .............................................. 27710.17. La tche de build que vous dclenchez doit aussi tre une tche paramtre .................... 27810.18. Passer un paramtre prdfini une tche de build paramtr ...................................... 27910.19. Crer une tche de build multiconfiguration ............................................................ 28010.20. Ajouter un axe un build multiconfiguration ........................................................... 280

  • xvii

    10.21. Dfinir un axe de noeuds esclave .......................................................................... 28110.22. Dfinir un axe de versions de JDK ........................................................................ 28210.23. Dfinir un axe spcifique l'utilisateur ................................................................... 28210.24. Rsultats de build multiconfiguration ..................................................................... 28310.25. Mettre en place un filtre de combinaison ................................................................ 28410.26. Rsultats de build utilisant un filtre de combinaison .................................................. 28510.27. Une tche gnre avec le Maven Jenkins plugin ...................................................... 28710.28. Tche gnre jenkins-master ............................................................................... 28810.29. Configuration du plugin Jenkins pour Artifactory ..................................................... 29210.30. Dclencher plusieurs autres builds aprs une tche de build ........................................ 29410.31. Un graphe de dpendance de tche de build ............................................................ 29510.32. Configurer une jonction dans la tche de build phoenix-web-tests ................................ 29610.33. Un graphe de dpendance de tche de build plus compliqu ........................................ 29610.34. Ajouter un nouveau verrou ................................................................................... 29710.35. Configurer une tche de build pour utiliser un verrou ................................................ 29810.36. Configurer une release Maven en utilisant le plugin M2Release ................................... 29910.37. L'option de menu Perform Maven Release .............................................................. 30010.38. Effectuer une release Maven dans Jenkins ............................................................... 30110.39. Ajouter une tape de build Copier des artefacts d'un autre projet ............................... 30210.40. Excuter des tests web sur un fichier WAR copi ..................................................... 30410.41. Copier partir d'un build multiconfiguration ........................................................... 30510.42. Tches de build dans le processus de promotion ....................................................... 30610.43. Configurer un processus de promotion de build ........................................................ 30710.44. Configurer un processus manuel de promotion de build ............................................. 30810.45. Voir les dtails d'une promotion de build ................................................................ 30910.46. Utiliser fingerprints dans le processus de promotion de build ...................................... 31010.47. Rcuprer le fichier WAR depuis la tche de build amont .......................................... 31110.48. Archiver le fichier WAR dans la tche aval ............................................................. 31110.49. Rcuprer le fichier WAR depuis la tche d'intgration .............................................. 31110.50. Nous avons besoin de dterminer le fingerprint du fichier WAR que nous utilisons .......... 31210.51. Rcuprer le dernier fichier WAR promu ................................................................ 31210.52. Les builds promus sont indiqus par une toile dans l'historique de build ....................... 31310.53. Rapport sur l'agrgation des rsultats de test ............................................................ 31310.54. Visualisation des rsultats de tests agrgs .............................................................. 31410.55. Configurer une tape manuelle dans le pipeline de build ............................................ 31510.56. Crer une vue Build Pipeline ................................................................................ 31510.57. Configurer une vue Build Pipeline ......................................................................... 31610.58. Un Pipeline de Build en action ............................................................................. 31711.1. Grer les noeuds esclaves ...................................................................................... 32011.2. Crer un nouveau noeud esclave ............................................................................. 32111.3. Crer un noeud esclave Unix .................................................................................. 32211.4. Mettre un esclave hors-ligne lorsqu'il est inactif ......................................................... 32311.5. Configurer l'emplacement des outils ........................................................................ 324

  • xviii

    11.6. Votre nouveau noeud esclave en action .................................................................... 32511.7. Crer un noeud esclave pour JNLP .......................................................................... 32611.8. Lancer un esclave via Java Web Start ...................................................................... 32611.9. L'agent esclave Jenkins en action ............................................................................ 32711.10. L'esclave Jenkins chouant la connexion au matre ................................................. 32711.11. Configurer le port de l'esclave Jenkins .................................................................... 32811.12. Installer l'esclave Jenkins en tant que service Windows .............................................. 32811.13. Grer le service Windows Jenkins ......................................................................... 32811.14. Permettre Jenkins de contrler un esclave Windows comme un service Windows .......... 33011.15. Excuter une tche de build sur un noeud esclave particulier ....................................... 33111.16. Jenkins surveille proactivement vos agents de build .................................................. 33311.17. Vous grez vos instances EC2 en utilisant la console de gestion Amazon AWS ............... 33411.18. Configurer un esclave Amazon EC2 ...................................................................... 33511.19. Configurer un esclave Amazon EC2 ...................................................................... 33611.20. Crer une nouvelle image Amazon EC2 ................................................................. 33711.21. Ajouter un nouvel esclave Amazon EC2 manuellement .............................................. 33812.1. Une chane simple de dploiement automatis ........................................................... 34712.2. Copier l'artefact binaire dployer .......................................................................... 34812.3. Dployer sur Tomcat avec le plugin Deploy .............................................................. 34812.4. Ajouter un paramtre Build selector for Copy Artifact .............................................. 35012.5. Configurer le slecteur de paramtrage de build ......................................................... 35012.6. Specifier o trouver les artefacts dployer .............................................................. 35112.7. Choix du build redployer ................................................................................... 35112.8. Utiliser l'option Specified by permalink ................................................................. 35212.9. Utiliser un build spcifique .................................................................................... 35212.10. Utiliser un dpt d'entreprise Maven ...................................................................... 35312.11. Dployer un artefact depuis un dpt Maven ........................................................... 35612.12. Prparer le WAR dployer ................................................................................. 35612.13. Configurer un hte distant .................................................................................... 35712.14. Dployer des fichiers vers un hte distant dans la section build .................................... 35812.15. Dployer des fichiers vers un hte distant depuis les actions ralises aprs le build ......... 35913.1. Suppression des anciens builds ............................................................................... 36113.2. Supprimer les anciens builds options avances ...................................................... 36213.3. Voir l'utilisation d'espace disque ............................................................................. 36313.4. Affichage de l'utilisation disque d'un projet ............................................................... 36313.5. Affichage de l'espace disque d'un projet au cours du temps ......................................... 36413.6. Tches de build Mavenoptions avances ............................................................... 36413.7. Statistiques de charge Jenkins ................................................................................. 36613.8. Le plugin Jenkins Monitoring ................................................................................. 36713.9. Le dossier des builds ............................................................................................ 36813.10. Le plugin Jenkins Backup Manager ....................................................................... 37013.11. Configurer Jenkins Backup Manager ...................................................................... 37013.12. Configurer le plugin Thin Backup ......................................................................... 371

  • xix

    13.13. Restaurer une configiuratiopn prcdente ................................................................ 37213.14. Recharger la configuration partir du disque ........................................................... 37313.15. Jenkins vous informe si vos donnes ne sont pas compatibles avec la version actuelle ....... 37413.16. Gestion de configuration prime .......................................................................... 375A.1. Un projet contenant des classes de tests nommes librement .......................................... 382

  • CopyrightCopyright 2010 John Ferguson Smart

    Version imprime publie par O'Reilly Media, 1005 Gravenstein Highway North, Sebastopol, CA95472.

    Version en ligne publie par Wakaleo Consulting, 111 Donald Street, Karori, Wellington 6012, NewZealand.

    Ce travail est diffus sous licence Creative Commons Attribution-Noncommercial-No Derivative Works3.0 United States. Pour plus dinformations au sujet de cette licence, voir http://creativecommons.org/licenses/by-nc-nd/3.0/us/. Vous tes libre de partager, copier, distribuer, afficher et excuter les travauxsous les conditions suivantes :

    Vous devez attribuer le travail John Ferguson Smart

    Vous ne devez pas utilis ce travail des fins commerciales.

    Vous ne devez pas modifier, transformer, ou vous baser sur ce travail.

    Java et tous les logos et marques bass sur Java sont des marques commerciales ou des marquesdposes de Sun Microsystems, Inc., aux tats-Unis et dans dautres pays.

    Eclipse est une marque de lEclipse Foundation, Inc., aux tats-Unis et dans dautres pays.

    Apache et le logo plume dApache sont des marques de lApache Software Foundation.

    Linux est une marque dpose de Linus Torvalds aux Etats-Unis et dans dautres pays.

    Beaucoup dappellations utilises par les fabricants et les vendeurs pour distinguer leurs produits sontdes marques dposes. Lorsque ces appellations apparaissent dans ce livre, et que Wakaleo Consultingtait au courant dune marque dpose, les dsignations ont t inscrites en majuscules ou avec desinitiales en majuscule.

    Bien que toutes les prcautions aient t prises lors de la prparation de ce livre, lditeur et lauteurnassument aucune responsabilit pour les erreurs ou omissions, ou pour les dommages rsultant delutilisation de linformation contenue dans ce document.

    http://creativecommons.org/licenses/by-nc-nd/3.0/us/http://creativecommons.org/licenses/by-nc-nd/3.0/us/

  • Avant-proposKohsuke Kawaguchi

    Il y a 7 ans, jcrivais la premire ligne de code qui a dmarr le projet aujourdhui connu sous le nom deJenkins, et qui sappelait lorigine Hudson. Javais lhabitude dtre celui qui cassait le build1, javaisdonc besoin dun programme qui dtecte mes erreurs avant que mes collgues ne le fassent. Ctait alorsun outil simple qui faisait une chose simple. Cependant, cet outil a rapidement volu et jaime penseraujourdhui quil est devenu le serveur dintgration continue le plus rpandu sur le march, englobantun large cosystme de plugins, des distributions commerciales, du Jenkins-as-a-Service hberg, desgroupes utilisateurs, des rencontres utilisateurs, des formations, etc.

    Comme la plupart de mes autres projets, celui-ci a t rendu open source ds sa cration. Au cours de savie, il a repos essentiellement sur laide et lamour dautres personnes, sans lesquelles ce projet ne seraitpas dans son tat actuel. Durant cette priode, jai aussi appris une chose ou deux sur le fonctionnementdes projets open source. De par cette exprience, jai constat que les gens ignorent souvent quil ya plusieurs faons de contribuer un projet open source, et qucrire du code nen est quune parmidautres. On peut en parler autour de soi, aider les autres utilisateurs, organiser des confrences, et biensr, on peut rdiger de la documentation.

    En cela, John est une personne importante au sein de la communaut Jenkins, mme sil na pas fourni decode, il rend Jenkins plus accessible aux nouveaux utilisateurs. Par exemple, il a un blog populaire quiest suivi par de nombreuses personnes, sur lequel il parle rgulirement des pratiques lies lintgrationcontinue, ainsi que dautres sujets lis au dveloppement logiciel. Il a vraiment un talent pour expliquerles choses afin que mme des utilisateurs nophytes puissent les comprendre, ce qui est souvent difficilepour des gens comme moi qui dveloppent Jenkins jour aprs jour. Il est aussi connu pour ses formations,dont Jenkins fait partie. Cest encore une autre faon par laquelle il rend Jenkins accessible davantagede personnes. Il a clairement une passion pour vangliser de nouvelles ides et enseigner ses pairsdveloppeurs comment tre plus productifs.

    Ces temps-ci je consacre mon temps chez CloudBees la version open source de Jenkins ainsi qu laversion pro sur laquelle nous construisons des plugins, et faire fonctionner Jenkins dans les cloudsprivs et publics via le service DEV@cloud de CloudBees. Avec ce rle, jai maintenant une plus grandeinteraction avec John quauparavant, et mon respect pour sa passion na fait quaugmenter.

    Je fus donc vritablement ravi quil prenne en charge limmense tche que reprsente lcriture dun livresur Jenkins. Cela donne une formidable vue densemble sur les principaux ingrdients de lintgrationcontinue. En plus, titre personnel, vu que lon me demande souvent sil y a un livre sur Jenkins, jepeux enfin rpondre cette question par laffirmative ! Mais plus important encore, ce livre reflte, entreautre, sa passion et sa longue exprience dans lenseignement de Jenkins. Mais ne me croyez pas surparole, vous devrez le lire pour le voir par vous-mme.

    1Note des traducteurs : nous navons pas traduit le terme build car nous navons pas trouv de traduction pertinente et parce quece terme reste majoritairement utilis dans les mtiers des TI.

  • Prface1. AudienceCe livre est destin des lecteurs relativement techniques, bien qu'aucune exprience pralable del'Intgration Continue ne soit requise. Vous dcouvrez peut-tre l'Intgration Continue, et dsirezconnatre les bnfices que cela pourrait apporter votre quipe de dveloppement. Ou, vous pourriezdj utiliser Jenkins ou Hudson, et vous voudriez dcouvrir comment emmener plus loin votreinfrastructure d'Intgration Continue.

    Une partie importante de ce livre traite de Jenkins dans le contexte de projets Java ou lis uneJVM. Cependant, si vous utilisez une autre pile technologique, ce livre devrait vous donner de bonnesbases en ce qui concerne l'Intgration Continue avec Jenkins. La construction de projets utilisant destechnologies non-Java est aborde, comme Grails, Ruby on Rails et .Net. De plus, plusieurs sujets,comme la configuration gnrale, la notification, les builds distribus et la scurit sont applicables quelque soit le langage que vous utilisez.

    2. Organisation du livreL'Intgration Continue ressemble beaucoup d'autres choses : plus vous investissez dessus, plus vousen tirerez de bnfices. Bien qu'une configuration d'Intgration Continue basique produira tout de mmedes amliorations dans le fonctionnement de votre quipe, il est aussi trs avantageux d'assimiler etd'implmenter graduellement quelques-unes des techniques avances. Dans ce but, ce livre est organiscomme un trek progressif dans le monde de l'Intgration Continue avec Jenkins, allant du plus simpleau plus avanc. Dans le premier chapitre, nous effectuerons un balayage de tout ce qui fait Jenkins,sous la forme d'une promenade haut-niveau. Ensuite, nous progresserons dans l'installation et laconfiguration de votre serveur Jenkins et expliquerons comment configurer des tches de build basiques.Une fois que nous aurons matris les bases, nous explorerons des sujets plus avancs, en passant parles tests automatiss, la scurit, des techniques avances de notification et la mesure et les rapportssur les mtriques de qualit de code. Ensuite, nous passerons des techniques de construction pluspousses comme les matrix builds, les builds distribus et l'IC base sur le Cloud, avant de parler del'implmentation du dploiement continu avec Jenkins. Et enfin, nous traiterons des astuces pour lamaintenance de votre serveur Jenkins.

    3. Jenkins ou Hudson?Comme nous l'voquons dans l'introduction, Jenkins tait originellement, et jusqu' rcemment, connusous le nom de Hudson. En 2009, Oracle racheta Sun et hrita de la base de code de Hudson. Dbut2011, des tensions entre Oracle et la communaut open source atteignirent un point de rupture et leprojet se scinda en deux entits distinctes : Jenkins, conduit par la plupart des dveloppeurs originels deHudson, et Hudson, qui resta sous le contrle d'Oracle.

  • xxvi

    Comme le titre le suggre, ce livre se concentre principalement sur Jenkins. Toutefois, une bonne partiede ce livre fut initialement crit avant la scission, et les produits restent trs similaires. Ainsi, bien queles exemples et les illustrations se rfrent habituellement Jenkins, presque tout ce qui est discuts'appliquera aussi Hudson.

    4. Conventions sur les policesCe livre suit certaines conventions pour l'utilisation des polices. Comprendre ces conventions d'emblefacilitera l'utilisation de ce livre.

    ItaliqueUtilise pour les noms de fichiers, extensions de fichiers, URLs, noms d'applications, emphaseset les nouveaux termes lorsqu'ils sont introduits pour la premire fois.

    Chasse fixe

    Utilise pour les noms de classes Java, les mthodes, variables, proprits, types de donnes,lments de base de donnes et extraits de code apparaissant dans le texte.

    Chasse fixe en grasUtilise pour les commandes entrer dans la ligne de commande et pour mettre en valeur ducode nouveau introduit dans un exemple fonctionnel.

    Chasse fixe en italique

    Utilise pour annoter la sortie.

    5. Conventions de ligne de commandeDe temps en temps, ce livre traite des instructions en ligne de commande. Quand c'est le cas, la sortieproduite par la console (e.g. les invites de commande ou la sortie cran) est affiche en caractresnormaux, et les commandes (ce que vous tapez) sont crites en gras. Par exemple :

    $ ls -altotal 168drwxr-xr-x 16 johnsmart staff 544 21 Jan 07:20 .drwxr-xr-x+ 85 johnsmart staff 2890 21 Jan 07:10 ..-rw-r--r-- 1 johnsmart staff 30 26 May 2009 .owner-rw-r--r--@ 1 johnsmart staff 1813 16 Apr 2009 config.xmldrwxr-xr-x 181 johnsmart staff 6154 26 May 2009 fingerprintsdrwxr-xr-x 17 johnsmart staff 578 16 Apr 2009 jobsdrwxr-xr-x 3 johnsmart staff 102 15 Apr 2009 logdrwxr-xr-x 63 johnsmart staff 2142 26 May 2009 plugins-rw-r--r-- 1 johnsmart staff 46 26 May 2009 queue.xml-rw-r--r--@ 1 johnsmart staff 64 13 Nov 2008 secret.key-rw-r--r-- 1 johnsmart staff 51568 26 May 2009 update-center.jsondrwxr-xr-x 3 johnsmart staff 102 26 May 2009 updatesdrwxr-xr-x 3 johnsmart staff 102 15 Apr 2009 userContentdrwxr-xr-x 12 johnsmart staff 408 17 Feb 2009 usersdrwxr-xr-x 28 johnsmart staff 952 26 May 2009 war

  • xxvii

    Lorsque ncessaire, l'antislash la fin de la ligne est utilis pour indiquer un saut de ligne : vous pouveztaper l'ensemble sur une seule ligne (sans l'antislash) si vous prfrez. N'oubliez pas d'enlever le caractre> au dbut des lignes concernes c'est un caractre de l'invite Unix :

    $ wget -O - http://jenkins-ci.org/debian/jenkins-ci.org.key \> | sudo apt-key add -

    Pour des raisons de cohrence, moins que nous ne traitions une question spcifique Windows, nousutiliserons des invites de commande de style Unix (le signe dollar, $), comme montr ici :

    $ java -jar jenkins.war

    ou :

    $ svn list svn://localhost

    Cependant, moins qu'on indique le contraire, les utilisateurs Windows peuvent utiliser ces commandesdepuis la console de commande Windows :

    C:\Documents and Settings\Owner> java -jar jenkins.war

    ou :

    C:\Documents and Settings\Owner> svn list svn://localhost

    6. ContributeursCe livre n'a pas t crit par une seule personne. Cela a plutt t un effort collaboratif impliquantplusieurs personnes jouant diffrents rles. En particulier, les personnes suivantes ont gnreusementdonn de leur temps, de leur savoir et de leur talent d'criture pour rendre ce livre meilleur :

    Evgeny Goldin est un ingnieur logiciel n en Russie vivant en Isral. Il est lead developerchez Thomson Reuters o il est responsable d'un certain nombre d'activits, dont certaines sontdirectement lies Maven, Groovy, et des outils de build comme Artifactory et Jenkins. Il possdeune vaste exprience dans un panel assez large de technologies, dont Perl, Java, JavaScript etGroovy. Les outils de build et les langages dynamiques sont les sujets favoris de Evgeny, proposdesquels il crit, prsente ou bloggue souvent. Il crit actuellement pour GroovyMag, Methods &Tools et dveloppe sur deux projets open source qu'il a crs : Maven-plugins1 et GCommons2. Ilbloggue sur http://evgeny-goldin.com/blog et peut tre trouv sur Twitter comme @evgeny_goldin.

    Evgeny a ralis une section sur la gnration automatique de tche de build Maven dansChapter 10, Builds avancs.

    Matthew McCullough est un vtran nergique de 15 ans d'exprience dans le dveloppementlogiciel d'entreprise, l'ducation open source, et co-fondateur de LLC, une entreprise de consultingde Denver. Matthew est actuellement formateur pour GitHub.com, auteur de la srie Git MasterClass pour OReilly, confrencier plus de 30 confrences nationales et internationales, auteurde 3 des 10 plus importantes RefCards DZone, et prsident du Groupe Utilisateur d'Open Source

    http://evgeny-goldin.com/wiki/Maven-pluginshttp://evgeny-goldin.com/wiki/GCommonshttp://evgeny-goldin.com/blog

  • xxviii

    de Denver. Ses sujets de recherche sont aujourd'hui concentrs autour de l'automatisation deprojet : outils de build (Maven, Leiningen, Gradle), contrle de version distribu (Git), IntgrationContinue (Jenkins) et les mtriques de qualit (Sonar). Matthew rside Denver, dans le Colorado,avec sa magnifique femme et ses deux jeunes filles, qui sont actives dans pratiquement toutes lesactivits d'extrieur que le Colorado puisse offrir.

    Matthew a crit la section sur l'intgration de Git Jenkins dans Chapter 5, Configurer vos tchesde Build.

    Juven Xu est un ingnieur logiciel venant de Chine qui travaille pour Sonatype. Membre actif dela communaut open source et expert Maven reconnu, Juven tait responsable de la traductionchinoise de Maven: The Definitive Guide et aussi d'un livre original de rfrence chinois sur Maven.Il travaille aussi actuellement la traduction chinoise du prsent livre.

    Juven a crit la section sur les notifications IRC dans Chapter 8, Notification.

    Rene Groeschke est ingnieur logiciel chez Cassidian Systems, connu prcdemment commeEADS Deutschland GmbH, et aussi un enthousiaste de l'open source. ScrumMaster certifi avec7 ans d'exprience comme programmeur dans plusieurs projets Java d'entreprise, il se concentreplus particulirement sur les mthodes Agiles comme l'Intgration Continue et le dveloppementguid par les tests. En dehors de son travail quotidien, l'Universit de l'Education d'Entreprise deFriedrichshafen lui permet de faire passer le mot propos de scrum et de sujets connexes en donnantdes cours aux tudiants en informatique.

    Rene a ralis la section sur la construction de projets avec Gradle dans Chapter 5, Configurer vostches de Build.

    6.1. Les traducteurs du prsent livre en franais

    Alexis Morelle3

    Alexis Thomas4

    Antoine Meausoone5

    Baptiste Mathus6

    Joseph Pachod7

    Emmanuel Hugonnet8

    Frederic Bouquet9

    Jeff Maury10

    Kevin Lecouvey11

    Michael Pailloncy12

    http://github.com/almorellehttp://github.com/ath0mashttp://github.com/Ameausoonehttp://github.com/Batmathttp://github.com/cluelessjoehttp://github.com/ehsavoiehttp://github.com/bouquetfhttp://github.com/jeffmauryhttp://github.com/Maetishttps://github.com/mpapo

  • xxix

    Nacef Labidi13

    Thibault Richard14

    7. L'quipe de revueLe processus de revue technique de ce livre a t un peu diffrent de l'approche utilise pour la plupartdes livres. Plutt que d'avoir un ou deux relecteurs techniques pour le livre entier une fois que le livreaurait t en passe d'tre termin, une quipe de volontaires de la communaut Jenkins, incluant plusieursdveloppeurs cl de Jenkins, a relu les chapitres au fil de leur criture. Cette quipe de relecture taitcompose des personnes suivantes : Alan Harder, Andrew Bayer, Carlo Bonamico, Chris Graham, EricSmalling, Gregory Boissinot, Harald Soevik, Julien Simpson, Juven Xu, Kohsuke Kawaguchi, MartijnVerberg, Ross Rowe et Tyler Ballance.

    8. Sponsors du livreCe livre n'aurait pas t possible sans l'aide de plusieurs organisations qui taient dsireuses d'assisteret de subventionner le processus d'criture.

    8.1. Wakaleo Consulting

    Wakaleo Consulting15 est une entreprise de consulting qui aide les organisations optimiser leurprocessus de dveloppement logiciel. Dirige par John Ferguson Smart, auteur de ce livre et deJava Power Tools16, Wakaleo Consulting fournit des services de consulting, de formation et dementoring dans le dveloppement Agile Java et dans les pratiques de test, l'optimisation de cycle vie dedveloppement logiciel et les mthodes Agiles.

    Wakaleo aide les entreprises avec des formations et de l'assistance dans des domaines commel'Intgration Continue, l'automatisation de build, le dveloppement guid par les tests, les tests Webautomatiss et le code propre, en utilisant des outils open source tels que Maven, Jenkins, Selenium 2et Nexus. Wakaleo Consulting donne aussi des formations publiques et sur site autour de l'IntgrationContinue et le Dploiement Continu, l'automatisation de build, les pratiques de codage propre, ledveloppement guid par les tests (TDD) et le Behavior-Driven Development, incluant des coursCertified Scrum Developer (CSD).

    8.2. CloudBees

    CloudBees17 est la seule entreprise spcialise pour offrir un service de gestion du cycle de vie, depuisle dveloppement jusqu'au dploiement, d'applications Java web dans le cloud. L'entreprise est aussil'experte mondiale sur l'outil d'intgration continue Jenkins/Hudson.

    15 http://www.wakaleo.com16 http://oreilly.com/catalog/978059652793817 http://www.cloudbees.com

    http://github.com/nacef-labidihttp://github.com/thbkrkrhttp://www.wakaleo.comhttp://oreilly.com/catalog/9780596527938http://www.cloudbees.comhttp://www.wakaleo.comhttp://oreilly.com/catalog/9780596527938http://www.cloudbees.com

  • xxx

    Le crateur de Jenkins/Hudson Kohsuke Kawaguchi dirige une quipe d'experts CloudBees travers lemonde. Ils ont cr Nectar, une version supporte et amliore de Jenkins disponible par abonnement. Sivous dpendez de Jenkins pour des processus logiciels critiques, Nectar fournit une version hautementteste, stable et totalement supporte de Jenkins. Cela inclut aussi des fonctionnalits disponiblesseulement dans Nectar comme le scaling automatique de machines virtuelles VMWare.

    Si vous tes prts explorer la puissance de l'Intgration Continue dans le cloud, CloudBees proposeJenkins/Hudson comme brique de sa plateforme de build DEV@cloud. Vous pouvez dmarrer avecJenkins instantanment et vous pouvez monter en puisssance comme vous le souhaitez pas de grosinvestissements ds le dbut dans vos serveurs de build, plus de capacits limites pour vos builds etplus de soucis de maintenance. Une fois qu'une application est prte partir, vous pouvez la dployersur l'offre Platform as a Service CloudBees RUN@cloud en seulement quelques clics.

    Avec les services CloudBees DEV@cloud et RUN@cloud, vous n'avez pas vous soucier des serveurs,machines virtuelles ou des quipes informatique. Et avec Nectar, vous profitez du Jenkins le pluspuissant, stable et support existant.

    8.3. Odd-e

    Odd-e18 est une entreprise base en Asie qui construit des produits de faon innovante et aide les autres faire de mme. L'quipe est compose de coaches expriments et de dveloppeurs produit travaillantdans des valeurs scrum, agile, lean, et artisan du logiciel, et l'entreprise est structure de la mme faon.Par exemple, Odd-e n'a pas d'organisation hirarchique de responsables prenant les dcisions pour lesautres. Au lieu de cela, les individus s'organisent eux-mmes et utilisent leurs talents pour constammentamliorer leurs comptences. L'entreprise propose des formations et du coaching suivi pour aider lesautres chercher et dvelopper une meilleure faon de travailler.

    Ce n'est pas le travail mais les valeurs qui lient Odd-e. Ses membres adorent construire du logiciel,accordent davantage d'importance l'apprentissage et la contribution qu' la maximisation du profit, etont dcid de supporter le dveloppement open source en Asie.

    9. Utilisation des exemples de codeCe livre est un livre open source, publi sous licence Creative Commons. Ce livre a t crit en DocBook,en utilisant XmlMind. Le code source du livre est disponible http://www.github.org/wakaleo/jenkins-the-definitive-guide.

    Les exemples de projets Jenkins de ce livre sont open source et librement disponibles en ligne rfrez-vous la page web du livre http://www.wakaleo.com/books/jenkins-the-definitive-guide pour plus dedtails.

    Ce livre existe pour vous aider faire votre travail. En gnral, vous pouvez utiliser le code de celivre dans vos programmes et documentation. Vous n'avez pas besoin de nous contacter pour obtenir

    18 http://www.odd-e.com

    http://www.odd-e.comhttp://www.github.org/wakaleo/jenkins-the-definitive-guidehttp://www.github.org/wakaleo/jenkins-the-definitive-guidehttp://www.wakaleo.com/books/jenkins-the-definitive-guidehttp://www.odd-e.com

  • xxxi

    une permission moins que vous ne reproduisiez une part importante du code. Par exemple, crire unprogramme qui utilise plusieurs extraits de code de ce livre ne ncessite pas de permission. Vendreou distribuer un CD-ROM d'exemples des livres OReilly requiert une permission. Rpondre unequestion en citant ce livre et utiliser des exemples de code du livre ne ncessite pas de permission.Incorporer une part importante d'exemples de code de ce livre dans votre documentation produit requiertune permission.

    Nous apprcions, mais ne requirons pas, une rfrence. Une rfrence inclut habituellement le titre,l'auteur, l'diteur et l'ISBN. Par exemple : Jenkins: The Definitive Guide par John Ferguson Smart(OReilly). Copyright 2011 John Ferguson Smart, 978-1-449-30535-2.

    Si vous pensez que votre utilisation des exemples de code tombe en dehors d'un usageraisonnable (NdT : fair-use) des permissions donnes ci-dessus, n'hsitez pas nous contacter .

    10. Safari Books Online

    Note

    Safari Books Online est une bibliothque numrique la demande qui vous permet dechercher facilement parmi 7500 livres et vidos de rfrence de technologie ou de crationpour trouver les rponses dont vous avez besoin rapidement.

    Avec un abonnement, vous pouvez lire n'importe quelle page ou regarder n'importe quelle vido de notrebibliothque en ligne. Lisez les livres depuis votre tlphone portable ou vos priphriques mobiles.Accdez aux nouveaux titres avant qu'ils soient disponibles en impression papier, et obtenez des accsexclusifs des manuscrits en dveloppements et postez des retours aux auteurs. Copiez et collez desexemples de code, organisez vos favoris, tlchargez des chapitres, mettez des sections cls en favoris,crez des notes, imprimez des pages et bnficiez d'une tonne d'autres fonctionnalits vous faisantgagner du temps.

    OReilly Media a dpos ce livre sur le service Safari Books Online. Pour obtenir l'accs numriquecomplet ce livre et d'autres dans des sujets similaires de chez OReilly et d'autres diteurs, enregistrez-vous gratuitement chez http://my.safaribooksonline.com19.

    11. Comment nous contacterMerci d'adresser vos commentaires et vos questions concernant ce livre l'diteur :

    OReilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472

    19 http://my.safaribooksonline.com/?portal=oreilly

    http://my.safaribooksonline.com/?portal=oreillyhttp://my.safaribooksonline.com/?portal=oreilly

  • xxxii

    800-998-9938 (in the United States or Canada)707-829-0515 (international or local)707-829-0104 (fax)

    Nous avons une page web pour ce livre, sur laquelle nous listons les erreurs, les exemples et toute autreinformation additionnelle. Vous pouvez accder cette page :

    http://www.oreilly.com/catalog/9781449305352

    Pour commenter ou poser des questions techniques propos de ce livre, envoyez un email :

    Pour plus d'information propos de nos livres, cours, confrences et nouvelles, visitez notre site web http://www.oreilly.com.

    Trouvez-nous sur Facebook : http://facebook.com/oreilly

    Suivez-nous sur Twitter : http://twitter.com/oreillymedia

    Regardez-nous sur YouTube : http://www.youtube.com/oreillymedia

    12. RemerciementsPour commencer et avant tout, ma merveilleuse femme, et aux garons, James et William, sans qui,grce leur amour, leur soutien et leur tolrence, ce livre n'aurait pas t possible.

    J'aimerais remercier Mike Loukides pour avoir travaill avec moi une fois de plus sur ce projet de livre,et toute l'quipe OReilly pour leur haut niveau de travail.

    Merci Kohsuke Kawaguchi d'avoir cr Jenkins, et d'tre encore la force motrice derrire ce brillantproduit. Merci aussi Franois Dechery, Sacha Labourey, Harpreet Singh et le reste de l'quipeCloudBees pour leur aide et leur soutien.

    Je suis aussi trs reconnaissant envers ceux qui ont consacr du temps et de l'nergie pour contribuer ce livre : Evgeny Goldin, Matthew McCullough, Juven Xu, et Rene Groeschke.

    Un grand merci revient aux relecteurs suivants, qui ont fourni des retours de grande valeur tout le longdu processus d'criture : Alan Harder, Andrew Bayer, Carlo Bonamico, Chris Graham, Eric Smalling,Gregory Boissinot, Harald Soevik, Julien Simpson, Juven Xu, Kohsuke Kawaguchi, Martijn Verberg,Ross Rowe, et Tyler Ballance.

    Merci Andrew Bayer, Martijn Verburg, Matthew McCullough, Rob Purcell, Ray King, AndrewWalker, et beaucoup d'autres, dont les discussions et les retours m'ont fourni l'inspiration et les idesqui ont fait de ce livre ce qu'il est.

    Et beaucoup d'autres personnes ont aid de diffrentes faons pour enrichir et complter ce livre tel qu'iln'aurait pu l'tre autrement : Geoff et Alex Bullen, Pete Thomas, Gordon Weir, Jay Zimmerman, Tim

    http://www.oreilly.com/catalog/9781449305352http://www.oreilly.comhttp://facebook.com/oreillyhttp://twitter.com/oreillymediahttp://www.youtube.com/oreillymedia

  • xxxiii

    OBrien, Russ Miles, Richard Paul, Julien Simpson, John Stevenson, Michael Neale, Arnaud Hritier,et Manfred Moser.

    Et enfin un grand merci aux dveloppeurs et la communaut utilisateur de Hudson/Jenkins pour lesencouragements et le soutien constants.

  • Chapter 1. Introduction Jenkins1.1. IntroductionL'Intgration Continue, aussi connue sous le terme IC, est l'un des piliers du dveloppement logicielmoderne. En fait, elle est un vritable tournant quand l'Intgration Continue est mise en placedans une organisation, elle change radicalement la manire dont les quipes pensent le processusde dveloppement. Elle est capable de permettre et d'induire toute une srie d'amliorations et detransformations, depuis le build rgulier automatis jusqu' la livraison continue en production. Unebonne infrastructure d'IC peut fluidifier le processus de dveloppement jusqu'au dploiement, aide dtecter et corriger les bogues plus rapidement, fournit un cran de contrle trs utile aux dveloppeursmais aussi aux non-dveloppeurs, et pousse l'extrme, elle permet aux quipes de fournir plus devaleur mtier aux utilisateurs finaux. Toute quipe de dveloppement professionnelle, quelque soit sataille, devrait mettre en uvre l'IC.

    1.2. Les fondamentaux de l'Intgration ContinueA l'poque des projets en V et des diagrammes de Gantt, avant l'introduction des pratiques de l'IC, unequipe de dveloppement dpensait son temps et son nergie sans compter durant la phase amenant la livraison, appele Phase d'Intgration. Durant cette phase, toutes les modifications apportes aucode par les dveloppeurs ou de petites quipes taient rassembles puis aggrges et fusionnes enun produit fonctionnel. Ce travail tait dur, intgrant ainsi des mois de modifications qui entraient enconflit. Il tait trs difficile d'anticiper les problmes qui allaient surgir, et encore plus de les corrigercar cela impliquait de reprendre du code qui avait t crit des semaines, voire des mois auparavant.Ce douloureux processus, plein de risques et de dangers, amenait souvent des retards significatifs delivraison, des cots supplmentaires et, au final, des clients mcontents. L'Intgration Continue est necomme une rponse ces problmes.

    L'Intgration Continue, dans sa forme la plus simple, se compose d'un outil qui surveille lesmodifications de code dans votre gestionnaire de configuration. Ds qu'un changement est dtect, cetoutil va automatiquement compiler et tester votre application. Si la moindre erreur arrive alors l'outil vaimmdiatement avertir les dveloppeurs afin qu'ils puissent tout de suite corriger le problme.

    Mais l'Intgration Continue est bien plus que cela. L'Intgration Continue peut aussi suivre la sant devotre projet en surveillant la qualit du code et les mtriques de couverture et ainsi aider maintenirla dette technique un niveau bas et abaisser les cots de maintenance. Rendre visible publiquementles mtriques de qualit de code encourage les dveloppeurs tre fiers de la qualit de leur code et essayer de toujours l'amliorer. Combine une suite de tests d'acceptance automatiss, l'IC peut aussise transformer en outil de communication en affichant une image claire de l'tat des dveloppementsen cours. Et elle peut simplifier et acclerer la livraison en vous aidant automatiser le processus dedploiement, vous permettant de dployer la dernire version de votre application soit automatiquementsoit d'un simple clic.

  • 2

    Dans le fond, l'Intgration Continue c'est rduire les risques en fournissant des retours rapides. Enpremier lieu, de par sa conception, elle permet d'identifier et de corriger les problmes d'intgration etles regressions plus rapidement ce qui permet de livrer plus facilement et avec moins de bogues. Endonnant une meilleure visibilit sur l'tat du projet tous les membres de l'quipe, techniques commenon-techniques, l'Intgration Continue facilite la communication au sein de l'quipe et encourage lacollaboration pour rsoudre les problmes ainsi que l'amlioration du processus. Et, en automatisant leprocessus de dploiement, l'Intgration Continue vous permet de mettre votre logiciel dans les mainsdes testeurs et des utilisateurs finaux plus rapidement, avec plus de fiabilit et avec moins d'efforts.

    Ce concept de dploiement automatis est important. En effet, si vous poussez ce concept de dploiementautomatis sa conclusion logique, vous pourriez mettre en production tout build qui passerait sansencombre les tests automatiss ncessaires. Cette pratique de dployer en production tous les buildsayant russi est appele communment Dploiement Continu.

    Cependant, une approche pure du Dploiement Continu n'est pas toujours souhaitable. Par exemple,de nombreux utilisateurs n'apprcieraient pas d'avoir une nouvelle version disponible plusieurs foispar semaine et prfreraient un cycle de livraison plus prvisible (et transparent). Des considrationscommerciales et marketing peuvent aussi entrer en compte pour dterminer quand une nouvelle versiondoit tre dploye.

    La notion de Livraison Continue est trs proche de cette ide de Dploiement Continu en prenanten compte ces considrations. Lors d'une Livraison Continue tout build qui a russi passer lestests automatiss pertinents et les contrles qualit peut virtuellement tre dploy en production aumoyen d'un processus lanc par un simple clic, et ainsi se retrouver dans les mains de l'utilisateurfinal en quelques minutes. Cependant, ce processus n'est pas automatique : c'est au mtier, plutt qu'l'Informatique de dcider quel est le moment opportun pour livrer les dernires modifications.

    Ainsi les techniques d'Intgration Continue, et plus particulirement le Dploiement Continu et laLivraison Continue, permettent d'apporter la valeur l'utilisateur final plus rapidement. Combien detemps faut-il votre quipe pour mettre une petite modification du code en production ? Dans cetemps quelle est la part des problmes qui auraient pu tre corrigs plus tt si vous aviez su quellesmodifications faisait Joe au bout du couloir ? Quelle part est prise par le pnible travail des quipes dela qualit pour tester manuellement ? Combien d'tapes manuelles, dont les secrets ne sont connus quede quelques initis seulement, sont ncessaires un dploiement ? L'Intgration Continue n'est pas lasolution miracle, elle permet de rationaliser certains de ces problmes.

    Mais l'Intgration Continue est tout autant une mentalit que des outils. Pour tirer un maximum deprofit de l'IC, une quipe doit adopter un comportement IC. Par exemple, vos projets doivent avoir unbuild fiable, reproductible et automatis, sans intervention humaine. La correction des builds en erreurdevrait tre une priorit absolue, et ne devrait pas tre oublie dans un coin. Le processus de dploiementdevrait tre automatis, sans tape manuelle. Et puisque la confiance que vous mettez dans votre serveurd'intgration dpend en grande partie de la qualit de vos tests, l'quipe doit mettre l'accent sur la qualitdes tests et des pratiques associes.

  • 3

    Dans ce livre nous verrons comment mettre en uvre une solution d'Intgration Continue robuste etcomplte avec Jenkins ou Hudson.

    1.3. Introduction Jenkins (n Hudson)Jenkins, qui s'appelait l'origine Hudson, est un outil d'Intgration Continue open source crit en Java.Bnficiant d'une part de march dominante, Jenkins est utilis par des quipes de toutes tailles, pourdes projets dans des langages et des technologies varis, incluant .NET, Ruby, Groovy, Grails, PHP etd'autres, ainsi que Java bien sr. Qu'est ce qui est l'origine du succs de Jenkins ? Pourquoi utiliserJenkins pour votre infrastructure d'IC ?

    Tout d'abord, Jenkins est facile utiliser. L'interface utilisateur est simple, intuitive et visuellementagrable, et Jenkins dans son ensemble a une trs petite courbe d'apprentissage. Comme nous le verronsdans le chapitre suivant, vous pouvez dmarrer avec jenkins en quelques minutes.

    Cependant jenkins n'a pas sacrifi puissance ou extensibilit : il est aussi extrmement flexible ets'adapte facilement vos moindres dsirs. Des centaines d'extensions open source sont disponibles, etde nouvelles aparaissent toutes les semaines. Ces extensions couvrent tout : les outils de gestion deconfiguration, les outils de build, les mtriques de qualit de code, les annonceurs de build, l'intgrationavec des systmes externes, la personalisation de l'interface utilisateur, des jeux et bien d'autresfonctionnalits encore. Les installer est simple et rapide.

    Enfin, mais ce n'est pas ngligeable, une bonne part de la popularit de Jenkins vient de la taille et dudynamisme de sa communaut. La communaut Jenkins est immense, dynamique, ractive et c'est ungroupe accueillant, avec ses champions passionns, ses listes de diffusion actives, ses canaux IRC et sonblog et son compte twitter trs bruyants. Le rythme de dveloppement est trs intense, avec des livraisonshebdomadaires comportant les dernires volutions, corrections et mises jour des extensions.

    Cependant, Jenkins rpond tout aussi bien aux attentes des utilisateurs qui ne souhaitent pas mettre jour toutes les semaines. Pour ceux qui veulent un rythme moins trpidant, il existe une version Long-term Support, ou LTS. Il s'agit d'un ensemble de versions qui sont la traine par rapport la toutedernire en termes de nouveauts mais qui apportent plus de stabilit et moins de changements. Lesversions LTS sortent environ tous les trois mois, les correctifs importants y sont intgrs. Ce conceptest identique aux versions Ubuntu LTS .

    1.4. De Hudson Jenkins Un rapide historiqueJenkins est le produit d'un dveloppeur visionnaire, Kohsuke Kawaguchi, qui a commenc ce projetcomme un loisir sous le nom d'Hudson la fin de l'anne 2004 alors qu'il travaillait chez Sun. CommeHudson voluait au cours des annes, il tait de plus en plus utilis par les quipes de Sun pour leurspropres projets. Dbut 2008, Sun reconnaissait la qualit et la valeur de cet outil et demandait Kohsukede travailler plein temps sur Hudson, commenant ainsi fournir des services professionnels et dusupport sur Hudson. En 2010, Hudson tait dvenu la principale solution d'Intgration Continue avecune part de march d'environ 70%.

  • 4

    En 2009, Oracle racheta Sun. Vers la fin 2010, des tensions apparurent entre la communaut dedveloppeurs d'Hudson et d'Oracle, dont la source tait les problmes de l'infrastructure Java.net,aggraves par la politique d'Oracle au sujet de la marque Hudson. Ces tensions rvlaient de profondsdsaccords sur la gestion du projet par Oracle. En effet, Oracle voulait orienter le projet vers unprocessus de dveloppement plus control, avec des livraisons moins frquentes, alors que le coeurdes dveloppeurs d'Hudson, men par Kohsuke, preferait continuer fonctionner selon le modlecommunautaire ouvert, flexible et rapide qui avait si bien fonctionn pour Hudson par le pass.

    En Janvier 2011, la communaut des dveloppeurs Hudson vota pour renommer le projet en Jenkins.Par la suite ils migrrent le code originel d'Hudson vers un nouveau projet Github1 et y poursuivirentleur travail. La grande majorit des dveloppeurs du coeur et des plugins leva le camp et suivit KohsukeKawaguchi et les autres principaux contributeurs dans le camp de Jenkins, o le gros de l'activit dedveloppement peut tre observe aujourd'hui.

    Aprs ce fork, la majorit des utilisateurs suivit la communaut des dveloppeurs Jenkins et passa Jenkins. Au moment o ces lignes sont crites, les sondages montrent qu'environ 75% des utilisateursd'Hudson sont passs Jenkins, 13 % utilisent encore Hudson et 12% utilisent Jenkins et Hudson ousont en cours de migration vers Jenkins.

    Cependant, Oracle et Sonatype (la compagnie derire Maven et Nexus) ont poursuivi leur travail partir du code d'Hudson (qui est maintenant lui aussi hberg chez GitHub https://github.com/hudson), mais selon un axe diffrent. En effet, les dveloppeurs de Sonatype se sont concentrs sur desmodifications dans l'architecture, notamment sur l'intgration avec Maven, sur le framework d'injectionde dpendances, et sur l'architecture des plugins.

    1.5. Dois-je utiliser Jenkins ou Hudson?Donc faut-il utiliser Jenkins ou Hudson ? Puisqu'il s'agit ici d'un livre traitant de Jenkins, voici plusieursraisons pour choisir Jenkins :

    Jenkins est le nouvel Hudson. En fait, Jenkins est simplement le bon vieil Hudson renomm,donc si vous avez apprci Hudson, vous aimerez Jenkins ! Jenkins utilise le code d'Hudson etl'quipe de dveloppement ainsi que la philosophie du projet sont restes identiques. En rsum,les dveloppeurs initiaux qui ont crit la plus grande partie du coeur d'Hudson, ont simplementcontinu en travaillant sur le projet Jenkins aprs la sparation.

    La communaut Jenkins. Comme de nombreux projets Open Source ayant du succs, la forced'Hudson venait de sa grande et dynamique communaut et de son adoption massive. Lesbogues sont dtcts (et gnralement corrigs) beaucoup plus rapidement, et si par malheur vousrencontrez un souci il y a de fortes chances que quelqu'un d'autre l'ait dj rencontr ! Si vous avezun problme, crivez une question sur la liste de diffusion ou sur le canal IRC vous trouverezsrement quelqu'un pour vous aider.

    1 https://github.com/jenkinsci

    https://github.com/jenkinscihttps://github.com/hudsonhttps://github.com/hudsonhttps://github.com/jenkinsci

  • 5

    Le rythme de dveloppement intense. Jenkins conserve la frquence lve des sorties, typiqued'Hudson, et que de nombreux dveloppeurs apprcient. Les nouvelles fonctionnalits, lesnouveaux plugins et les corrections de bogues apparaissent hebdomadairement et le temps decorrection des bogues est vraiment trs court. Si, par contre, vous prferrez plus de stabilit, il ya toujours les versions LTS.

    Et, pour quilibrer les choses, voici quelques raisons qui peuvent vous faire prferrer Hudson :

    Si a fonctionne, ne le touchez pas. Vous avez dj un Hudson install dont vous tes trs satisfaitet vous ne ressentez pas le besoin d'installer la dernire version.

    L'intgration professionnelle et les outils Sonatype. Hudson va probablement mettre l'accent surson intgration avec des outils professionnels comme un annuaire LDAP/Active Directory et lesproduits de Sonatype tels que Maven 3, Nexus et M2Ecipse, alors que Jenkins sera plus ouvert des outils concurrents comme Artifactory et Gradle.

    L'architecture des plugins. Si vous avez l'intention d'crire vos propres plugins Jenkins/Hudsonplugins, il vous faut savoir que Sonatype travaille pour proposer une injection de dpendanceJSR-330 pour les plugins d'Hudson. Les nouveaux dveloppeurs peuvent trouver cette approcheplus facile utiliser mme si cela soulve des questions quant la compatibilit entre Jenkins etHudson.

    La bonne nouvelle est que quelque soit l'outil que vous utilisiez entre Hudson et Jenkins, ils restentglobalement trs proches et la plupart des techniques et des astuces prsentes dans ce livre serontvalables sur les deux. En effet, pour illustrer ce point, de nombreuses captures d'cran dans ce livre fontrfrence Hudson plutt qu' Jenkins.

    1.6. Mettre en place l'Intgration Continue au sein devotre organisationL'Intgration Continue n'est pas une histoire de tout ou rien. En fait, mettre en place l'IC au sein d'uneorganisation suit un chemin qui vous fera passer par diffrentes phases. A chacune de ces phases serattachent des amliorations de l'infrastructure technique, mais aussi, et c'est peut-tre le plus important,des amliorations des pratiques et de la culture de l'quipe de dveloppement elle-mme. Dans lesparagraphes qui vont suivre j'ai essay d'esquisser chacune de ces phases.

    1.6.1. Phase 1 Pas de serveur de build

    Au tout dbut, l'quipe n'a pas de serveur central de build quelqu'il soit. Le logiciel est construitmanuellement sur la machine du dveloppeur, mme si cela peut tre ralis par un script Ant ouequivalent. Le code source peut tre enregistr dans un gestionnaire de configuration centralis, mais lesdveloppeurs n'ont pas l'habitude de commiter leurs modifications rgulirement. Peu de temps avantla prochaine livraison prvue, un dveloppeur intgre manuellement les modifications, une oprationqui produit beaucoup de peine et de soufffrance.

  • 6

    1.6.2. Phase 2 Builds quotidiens

    Dans cette phase, l'quipe possde un serveur de build et des builds automatiss sont excutsrgulirement (gnralement la nuit). Ce build compile tout simplement le code car il n'existe pas detests unitaires pertinents et rptables. En effet, les tests automatiss, mme s'ils sont crits, ne font paspartie du processus de build, et peuvent ne pas s'excuter correctement du tout. Cependant, maintenantles dveloppeurs commitent leurs modifications rgulirement au moins la fin de la journe. Siun dveloppeur commite des modifications de code qui entrent en conflit avec le travail d'un autredveloppeur, le serveur de build avertit l'quipe par mail le lendemain matin. Toutefois, l'quipe ne sesert du serveur de build qu' titre informatif ils ne se sentent pas obligs de rparer un build en checimmdiatement, et le build peut rester en chec pendant plusieurs jours sur le serveur de build.

    1.6.3. Phase 3 Builds quotidiens et tests automatiss basiques

    L'quipe commence prendre l'Intgration Continue et les tests au srieux. Le serveur de buildest configur pour lancer un build ds qu'un nouveau code est commit dans l'outil de gestion deconfiguration et les membres de l'quipe peuvent facilement voir quelles sont les modifications du codequi correspondent chaque build et de quel problme elles traitent. A cela s'ajoute le fait que le script debuild compile l'application et lance une srie de tests unitaires ou d'intgration automatiss. En plus desemails, le serveur de build avertit aussi les membres de l'quipe des problmes d'intgration en utilisantdes canaux plus proactifs tel que la messagerie instantane. Les builds en echec sont maintenant rparsrapidement.

    1.6.4. Phase 4 Arrive des mtriques

    Des mtriques de qualit et de couverture de code automatises sont maintenant mesures pour aider valuer la qualit du code et (jusqu' un certain point) la pertinence et l'efficacit des tests. Le buildmesurant la qualit de code produit aussi automatiquement la documentation de l'API de l'application.Tout ceci permet l'quipe de maintenir un code de trs bonne qualit, alertant les membres de l'quipeen cas de drive des bonnes pratiques de tests. L'quipe a aussi mont un build radiator, un tableau debord qui prsente l'tat du projet sur un cran visible de l'ensemble des membres de l'quipe.

    1.6.5. Phase 5 Prendre les tests au srieux

    Les bnfices de l'Intgration Continue sont troitement lis de solides pratiques de test. De nosjours, des techniques comme le dveloppement pilot par les tests sont trs utilises ce qui amliore laconfiance que l'on peut avoir dans le rsultat d'un build automatis. L'application n'est plus simplementcompile et teste, mais si les tests passent, elle est automatiquement dploye sur un serveurd'application pour des tests plus complets de bout en bout et des tests de performance.

    1.6.6. Phase 6 Tests d'acceptance automatiss et un dploiementplus automatis

    Le Dveloppment pilot par les tests d'acceptance est utilis, guidant les efforts de dveloppement etfournissant des rapports de haut niveau sur l'tat du projet. Ces tests automatiss profitent des outils issus

  • 7

    du monde du Dveloppement pilot par le comportement (BDD) et du Dveloppement pilot par lestests d'acceptance non seulement comme outils de tests mais aussi comme outils de communication etde documentation, en produisant des rapports de tests utilisant les termes mtier qu'un non-dveloppeurpeut comprendre. Puisque ces tests de haut-niveau sont automatiss ds le dbut du processus dedveloppement, ils permettent de savoir trs simplement quelles sont les fonctionnalits qui sontralises et celles qu'il reste faire. L'application est automatiquement dploye sur un environnementde test pour l'quipe qualit (QA) soit chaque modification soit tous les soirs ; une version peut tredploye (ou promue) pour des tests de conformit utilisateurs et il est possible de la dployer dans desenvironnements de production au moyen d'un build lanc manuellement quand les testeurs la considreprte. L'quipe peut aussi utiliser le serveur de build pour revenir en arrire d'une version en cas decatastrophe.

    1.6.7. Phase 7 Dploiement Continu

    La confiance dans les tests unitaires, d'intgration et d'acceptance automatiss est telle que les quipespeuvent utiliser les techniques de dploiement continu dveloppes dans les phases prcdentes pourpousser les modifications directement en production.

    La progression entre les niveaux dcrite ici est approximative et peut ne pas correspondre exactement des situations dans le monde rel. Par exemple, vous pouvez tout fait introduire des tests de l'interfaceweb avant de mettre en places les mtriques de qualit de code et les rapports sur la couverture de code.Cependant, cela devrait vous donner une ide globale de la stratgie d'Intgration Continue mettre enoeuvre dans une organisation du monde rel.

    1.7. Et maintenant ?Tout au long du reste du livre, pendant que nous tudierons les diffrentes fonctionnalits de Jenkinsainsi que les pratiques associes pour en profiter au maximum, nous verrons comment progressersuivant ces diffrents niveaux avec Jenkins.Et souvenez-vous, la plupart des exemples de ce livresont disponibles en ligne (cf. http://www.wakaleo.com/books/jenkins-the-definitive-guide pour plusd'informations), vous pouvez donc mettre les mains dans le cambouis vous aussi !

    http://www.wakaleo.com/books/jenkins-the-definitive-guide

  • Chapter 2. Vos premiers pas avecJenkins2.1. Introduction

    Dans ce chapitre, nous allons faire un tour rapide des fonctionnalits cl de Jenkins. Tout d'abord, vousverrez combien il est facile d'installer Jenkins et d'y configurer votre premire de build automatique.Nous n'entrerons pas dans les dtails - ceux-ci vous seront donns dans les chapitres suivants, ainsique dans un chapitre dtaill sur l'administration de Jenkins la fin de ce livre (Chapter 13, MaintenirJenkins). Ce chapitre n'est qu'une introduction. Cependant, quand vous terminerez la lecture de cechapitre vous aurez aussi eu un aperu des rapports de sur les rsultats des tests, la production de javadocet la publication de la couverture de test! Nous avons un long chemin parcourir, alors allons-y!

    2.2. Prparation de votre environnement

    Vous pouvez aborder ce chapitre de deux manires diffrentes. Vous le lisez entirement, sans toucherun clavier, pour vous faire une ide sur ce qu'est Jenkins. Ou, vous pouvez mettre les mains dans lecambouis, et suivre les tapes sur votre machine.

    Si vous voulez suivre tranquillement, il se peut que cela ncessite d'installer certains logiciels survotre machine. Souvenez-vous que la fonction principale de tout outil d'Intgration Continue est desurveiller du code source dans un outil de gestion de configuration, d'en extraire la dernire version etde la construire ds que des modifications sont apportes. Donc, il vous faudra un outil de gestion deconfiguration. Dans le cas qui nous occupe, nous utiliserons Git1. Le code source de notre simple projetse trouve hberg sur GitHub2. Ne vous inquitez pas, vous ne risquerez pas de perturber ce rfrentielavec vos modifications : vous travaillerez sur votre propre rplique et vous pourrez y faire ce que vousvoulez. Si vous n'avez jamais utilis Git et/ou si vous n'avez pas un compte sur GitHub, ne vous inquitezpas nous vous guiderons pour vos premiers pas et l'installation est trs bien documente sur le site webde GitHub. Nous vous expliquerons comment mettre tout cela en place par la suite.

    Dans ce chapitre, nous utiliserons Jenkins pour construire une application Java avec Apache Maven.Apache Maven est un outil de build trs largement utilis dans le monde Java, avec de nombreuses etpuissantes fonctionalits telles que la gestion dclarative des dpendances, le principe de conventionplutt que configuration et un trs grand nombre de plugins. Pour construire tout cela, nous utiliseronsles dernires versions du Java Development Kit (JDK) et d'Apache Maven, mais si vous ne les avezpas dj installes sur votre machine ne vous inquitez pas! Comme nous le verrons, Jenkins saura lesinstaller pour vous.

    1 http://git-scm.com2 https://github.com

    http://git-scm.comhttps://github.comhttp://git-scm.comhttps://github.com

  • 10

    2.2.1. Installation de Java

    La premire chose que vous allez devoir installer sur votre machine est Java. Hudson est une applicationweb Java web application, aussi vous aurez besoin au minimum du Java Runtime Environment, ou JRE pour l'excuter. Pour les exemples de ce chapite, vous devrez avoir une version rcente de Java 6 (cesexemples ont t crits avec Java 6 update 17 et la dernire version disponible au moment o j'cris cesmots est Java 6 update 19). Si vous n'tes pas sr, vous pouvez vrifier votre version depuis la ligne decommande (en ouvrant une console DOS sous Windows) et en excutant java -version. Si Java estinstall sur votre machine vous devriez obtenir un rsultat ressemblant ceci :

    $ java -versionjava version "1.6.0_17"Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

    Si vous n'avez une version dj installe ou si votre version est plus ancienne, tlchargez et isntallez ladernire version de la JRE depuis le site web de Java3, comme le montre Figure 2.1, Installer Java.

    Figure 2.1. Installer Java

    3 http://java.sun.com/javase/downloads/index.jsp

    http://java.sun.com/javase/downloads/index.jsphttp://java.sun.com/javase/downloads/index.jsp

  • 11

    2.2.2. Installation de Git

    Etant donn que nous utiliserons Git, il va vous falloir installer et configurer Git sur votre machine. Sivous tes novice en ce qui concerne Git, un petit tour sur le site de rfrence de Git4 peut vous treutile. Et si vous vous perdez en cours de route, la manire de procder est entirement dcrite dans lespages d'aide de GitHub5.

    Avant toute chose, il vous faut installer Git sur votre machine. Cela exige de tlcharger le programmed'installation appropri pour votre systme d'exploitation depuis le site web de Git6. Il existe desprogrammes d'installtion packags pour Windows et Mac OS X. Si vous utilisez GNU/Linux vous tessur le terrain de Git : les distributions GNU/Linux. Sur Ubunut ou toute autre distribution bases surDebian, vous pouvez excuter une commande comme celle-ci :

    $ sudo apt-get install git-core

    Sur Fedora ou toute distribution base sur RPM, il pouvez utiliser yum la place :

    $ sudo yum install git-core

    Et, puisqu'il s'agit de GNU/Linux, vous avez aussi la possibilit d'installer l'application partir dessources. Les instructions sont disponibles sur le site web de Git.

    Une fois cette opration ralise, vrifiez que Git est correctement install en excutant la commandesuivante :

    $ git --versiongit version 1.7.1

    2.2.3. Configurer un compte GitHub

    Ensuite, si vous n'en possdez pas dj un, vous devrez vous crer un compte Github. Cela est simpleet (pour notre usage du moins) gratuit, sans compter que tous les gars cools en ont un. Allez sur la paged'enregistrement de GitHub7 et choissisez l'option Create a free account. Vousn'aurez qu' fournir unnom d'utilisateur, un mot de passe et votre adresse e-mail (cf. Figure 2.2, Crer un compte GitHub).

    4 http://gitref.org5 http://help.github.com6 http://git-scm.com7 https://github.com/plans

    http://gitref.orghttp://help.github.comhttp://git-scm.comhttps://github.com/planshttps://github.com/planshttp://gitref.orghttp://help.github.comhttp://git-scm.comhttps://github.com/plans

  • 12

    Figure 2.2. Crer un compte GitHub

    2.2.4. Configurer les clefs SSH

    GitHub utilise les clefs SSH pour tablir une connexion scurise entre votre ordinateur et les serveursGithub. Les configurer n'est pas compliqu mais demande un peu d'effort : heureusement il existe desinstructions claires et dtailles pour chaque systme d'exploitation sur le site de GitHub8.

    2.2.5. Forker le dpt des exemples

    Comme nous l'avons mentionn plus tt, tout les exemples de code de ce livre sont stocks sur GitHub, l'URL suivante : https://github.com/wakaleo/game-of-life. C'est un dpt public, vous pouvez donclibrement voir les sources en ligne et rcuprer votre propre copie de travail. Toutefois, si vous voulezeffectuer des changements, vous devrez crer votre propre fork. Un fork est une copie personnelle d'undpt que vous pouvez utiliser votre guise. Pour crer un fork, connectez votre compte GitHub etcliquez sur l'URL du dpt9. Cliquez ensuite sur le bouton Fork (see Figure 2.3, Forker le dpt desexemples de code). Cela crera votre propre copie du dpt.

    Une fois que vous avez fork le dpt, vous devez cloner une copie locale pour vrifier que tout estcorrectement configur. Ouvrez la ligne de commande et excutez la commande suivante (en remplaant avec votre propre nom d'utilisateur GitHub):

    8 http://help.github.com/set-up-git-redirect9 https://github.com/wakaleo/game-of-life

    http://help.github.com/set-up-git-redirecthttps://github.com/wakaleo/game-of-lifehttps://github.com/wakaleo/game-of-lifehttp://help.github.com/set-up-git-redirecthttps://github.com/wakaleo/game-of-life

  • 13

    $ git clone git@github.com:/game-of-life.git

    Ceci va cloner (ou faire un check out, en termes Subversion) une copie du projet sur votre disque local :

    git clone git@github.com:john-smart/game-of-life.gitInitialized empty Git repository in /Users/johnsmart/.../game-of-life/.git/remote: Counting objects: 1783, done.remote: Compressing objects: 100% (589/589), done.remote: Total 1783 (delta 1116), reused 1783 (delta 1116)Receiving objects: 100% (1783/1783), 14.83 MiB | 119 KiB/s, done.Resolving deltas: 100% (1116/1116), done.

    Vous devriez prsent disposer d'une copie locale du projet que vous pouvez construire et excuter.Nous utiliserons ce projet plus tard pour dclencher des changements dans le dpt.

    Figure 2.3. Forker le dpt des exemples de code

  • 14

    2.3. Dmarrer Jenkins

    Il y a plusieurs faons d'excuter Jenkins sur votre machine. Une des plus faciles pour excuter Jenkinspour la premire fois est d'utiliser Java Web Start. Java Web Start est une technologie qui vous permetde dmarrer une application Java sur votre machine locale via une URL sur une page web cela vientprinstall avec le JRE Java. Dans notre cas, cela dmarrera un serveur Jenkins s'excutant sur votremachine, et vous permettra de l'exprimenter comme si vous l'aviez install localement. Tout ce dontvous avez besoin pour cela est de travailler avec une version rcente (Java 6 ou plus) du Java RuntimeEnvironment (JRE), que nous avons install dans la section prcdente.

    Par commodit, il y a un lien vers l'instance Java Web Start de Jenkins sur la page de ressources dulivre10. Vous y trouverez un large bouton orange dans la section Ressources du Livre (voir Figure 2.4,Excuter Jenkins en utilisant Java Web Start partir du site web du livre). Vous pouvez aussi trouverce lien sur la page Meet Jenkins sur le site Web de Jenkins11, o, si vous scrollez assez loin, vous devrieztrouver une section "Test Drive" avec un bouton "Launch" identique.

    10 http://www.wakaleo.com/books/jenkins-the-definitive-guide11 http://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

    http://www.wakaleo.com/books/jenkins-the-definitive-guidehttp://www.wakaleo.com/books/jenkins-the-definitive-guidehttp://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkinshttp://www.wakaleo.com/books/jenkins-the-definitive-guidehttp://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

  • 15

    Figure 2.4. Excuter Jenkins en utilisant Java Web Start partir du site web du livre

    Java Web Start semble fonctionner le mieux sur Firefox. Quand vous cliquez sur le bouton Launch surl'un de ces sites dans Firefox, le navigateur vous demandera si vous voulez ouvrir un fichier appeljenkins.jnlp en utilisant Java Web Start. Cliquez sur OK cela tlchargera Jenkins et le dmarrerasur votre machine (voir Figure 2.5, Java Web Start tlchargera et excutera la dernire version deJenkins).

  • 16

    Figure 2.5. Java Web Start tlchargera et excutera la dernire version de Jenkins

    Dans d'autres navigateurs, cliquer sur le bouton pourrait simplement tlcharger le fichier JNLP. DansInternet Explorer, vous pourriez mme avoir cliquer avec le bouton droit sur le lien et slectionnerEnregistrer sous pour enregistrer le fichier JNLP, et l'excuter depuis Windows Explorer. Toutefois,dans chacun de ces cas, quand vous ouvrez le fichier JNLP, Java Web Start tlchargera et dmarreraJenkins.

    Java Web Start n'aura besoin de tlcharger une version particulire de Jenkins qu'une seule fois. Apartir de ce moment, quand vous cliquez sur le bouton Launch nouveau, Java Web Start utiliseraune copie de Jenkins qu'il a dj tlcharge (jusqu' ce qu'une nouvelle version sorte). Ignorez toutmessage que votre systme d'exploitation ou votre anti-virus pourrait afficher il est parfaitement srd'excuter Jenkins sur votre machine locale.

    Une fois qu'il aura fini de tlcharger, il dmarrera Jenkins sur votre machine. Vous pourrez le voirs'excuter dans une petite fentre appele Console Jenkins (voir Figure 2.6, Java Web Start excutantJenkins). Pour arrter Jenkins tout moment, fermez simplement cette fentre.

    Figure 2.6. Java Web Start excutant Jenkins

  • 17

    Il y a aussi des installeurs disponibles pour les principaux systmes d'exploitations sur le site Web deJenkins12. Ou, si vous tes un utilisateur Java expriment vers dans les manipulations de fichiersWAR, vous pourriez prfrer simplement tlcharger la dernire version de Jenkins et l'excuter depuisla ligne de commande. Jenkins est fourni sous la forme d'un WAR excutable vous pouvez tlchargerla version la plus rcente partir de la page d'accueil13 du site de Jenkins. Par facilit, il y a un lien versla dernire version de Jenkins dans la section Ressources du site web14 de ce livre.

    Une fois tlcharg, vous pouvez dmarrer Jenkins depuis la ligne de commande comme montr ici :$ java -jar jenkins.war

    Si vous avez dmarr Jenkins en utilisant Java Web Start ou via la ligne de commande, Jenkins devrait prsent tourner sur votre machine locale. Par dfault, Jenkins s'excutera sur le port 8080, vous pouvezdonc accder Jenkins dans votre navigateur web sur http://localhost:8080.

    Sinon, si vous tes familier avec les serveurs d'application comme Tomcat, vous pouvez simplementdployer le WAR de Jenkins dans votre serveur d'application avec Tomcat, par exemple, vouspouvez simplement placer le fichier jenkins.war dans le rpertoire webapps de Tomcat. Si vousexcutez Jenkins sur un serveur d'application, l'URL utiliser pour accder Jenkins sera lgrementdiffrente. Sur une installation Tomcat par dfaut, par exemple, , vous pouvez accder Jenkins dansvotre navigateur web l'adresse http://localhost:8080/jenkins.

    Quand vous ouvrez Jenkins dans votre navigateur, vous devez voir un cran comme celui montr dansFigure 2.7, La page de dmarrage Jenkins. Vous tes maintenant prt faire vos premiers pas avecJenkins !

    Figure 2.7. La page de dmarrage Jenkins

    12 http://jenkins-ci.org13 http://http://jenkins-ci.org14 http://www.wakaleo.com/books/jenkins-the-definitive-guide

    http://jenkins-ci.orghttp://jenkins-ci.orghttp://http://jenkins-ci.orghttp://www.wakaleo.com/books/jenkins-the-definitive-guidehttp://localhost:8080http://localhost:8080/jenkinshttp://jenkins-ci.orghttp://http://jenkins-ci.orghttp://www.wakaleo.com/books/jenkins-the-definitive-guide

  • 18

    2.4. Configuring the Tools

    Before we get started, we do need to do a little configuration. More precisely, we need to tell Jenkinsabout the build tools and JDK versions we will be using for our builds.

    Click on the Manage Jenkins link on the home page (see Figure 2.7, La page de dmarrage Jenkins).This will take you to the Manage Jenkins page, the central one-stop-shop for all your Jenkinsconfiguration. From this screen, you can configure your Jenkins server, install and upgrade plugins,keep track of system load, manage distributed build servers, and more! For now, however, well keepit simple. Just click on the Configuring System link at the top of the list (see Figure 2.8, The ManageJenkins screen).

    Figure 2.8. The Manage Jenkins screen

    This will take you to Jenkinss main configuration screen (see Figure 2.9, The Configure Jenkinsscreen). From here you can configure everything from security configuration and build tools to emailservers, version control systems and integration with third-party software. The screen contains a lot ofinformation, but most of the fields contain sensible default values, so you can safely ignore them for now.

  • 19

    Figure 2.9. The Configure Jenkins screen

    For now, you will just need to configure the tools required to build our sample project. The applicationwe will be building is a Java application, built using Maven. So in this case, all we need to do is to setup a recent JDK and Maven installation.

    However before we start, take a look at the little blue question mark icons lined to the right of the screen.These are Jenkinss contextual help buttons. If you are curious about a particular field, click on the helpicon next to it and Jenkins will display a very detailed description about what it is and how it works.

    2.4.1. Configuring Your Maven Setup

    Our sample project uses Maven, so we will need to install and configure Maven first. Jenkins providesgreat out-of-the-box support for Maven. Scroll down until you reach the Maven section in the ConfigureSystem screen (see Figure 2.10, Configuring a Maven installation).

    Jenkins provides several options when it comes to configuring Maven. If you already have Maveninstalled on your machine, you can simply provide the path in the MAVEN_HOME field. Alternatively,you can install a Maven distribution by extracting a zip file located in a shared directory, or execute ahome-rolled installation script. Or you can let Jenkins do all the hard work and download Maven for you.To choose this option, just tick the Install automatically checkbox. Jenkins will download and installMaven from the Apache website the first time a build job needs it. Just choose the Maven version youwant to install and Jenkins will do the rest. You will also need to give a name for your Maven version(imaginatively called Maven 2.2.1 in the example), so that you can refer to it in your build jobs.

  • 20

    For this to work, you need to have an Internet connection. If you are behind a proxy, youll need toprovide your proxy informationwe discuss how to set this up in Section 4.9, Configurer un Proxy.

    Figure 2.10. Configuring a Maven installation

    One of the nice things about the Jenkins Maven installation process is how well it works with remotebuild agents. Later on in the book, well see how Jenkins can also run builds on remote build servers.You can define a standard way of installing Maven for all of your build servers (downloading from theInternet, unzipping a distribution bundle on a shared server, etc.)all of these options will work whenyou add a new remote build agent or set up a new build server using this Jenkins configuration.

    2.4.2. Configuring the JDK

    Once you have configured your Maven installation, you will also need to configure a JDK installation(see Figure 2.11, Configuring a JDK installation). Again, if you have a Java JDK (as opposed to a JavaRuntime Environmentthe JDK contains extra development tools such as the Java compiler) alreadyinstalled on your workstation, you can simply provide the path to your JDK in the JAVA_HOME field.Otherwise, you can ask Jenkins to download the JDK from the Oracle website15 the first time a buildjob requires it. This is similar to the automatic Maven installation featurejust pick the JDK versionyou need and Jenkins will take care of all the logistics. However, for licensing reasons, you will alsoneed to tick a checkbox to indicate that you agree with the Java SDK License Agreement.

    15 http://www.oracle.com/technetwork/java/index.html

    http://www.oracle.com/technetwork/java/index.htmlhttp://www.oracle.com/technetwork/java/index.html

  • 21

    Figure 2.11. Configuring a JDK installation

    Now go to the bottom of the screen and click on the Save button.

    2.4.3. Notification

    Another important aspect you would typically set up is notification. When a Jenkins build breaks, andwhen it works again, it can send out email messages to the team to spread the word. Using plugins, youcan also get it to send instant messages or SMS messages, post entries on Twitter, or get people notifiedin a few other ways. It all depends on what works best for your organizational culture. Email notificationis easy enough to set up if you know your local SMTP server addressjust provide this value in theEmail Notification section towards the bottom of the main configuration page. However, to keep thingssimple, were not going to worry about notifications just yet.

    2.4.4. Setting Up Git

    The last thing we need to configure for this demo is to get Jenkins working with Git. Jenkins comes withsupport for Subversion and CVS out of the box, but you will need to install the Jenkins Git plugin to beable to complete the rest of this tutorial. Dont worry, the process is pretty simple. First of all, click on theManage Jenkins link to the left of the screen to go back to the main configuration screen (see Figure 2.8,The Manage Jenkins screen). Then click on Manage Plugins. This will open the plugin configurationscreen, which is where you manage the extra features you want to install on your Jenkins server. Youshould see four tabs: Updates, Available, Installed, and Advanced (see Figure 2.12, Managing pluginsin Jenkins).

  • 22

    Figure 2.12. Managing plugins in Jenkins

    For now, just click on the Available tab. Here you will see a very long list of available plugins. Findthe Git Plugin entry in this list and tick the corresponding checkbox (see Figure 2.13, Installing the Gitplugin), and then scroll down to the bottom of the screen and click on Install. This will download andinstall the Jenkins Git plugin into your local Jenkins instance.

    Figure 2.13. Installing the Git plugin

    Once it is done, you will need to restart Jenkins for the changes to take effect. To do this, you can simplyclick on the Restart Jenkins when no jobs are running button displayed on the installation screen, oralternatively shut down and restart Jenkins by hand.

    That is all we need to configure at this stage. You are now ready to set up your first Jenkins build job!

    2.5. Your First Jenkins Build JobBuild jobs are at the heart of the Jenkins build process. Simply put, you can think of a Jenkins build jobas a particular task or step in your build process. This may involve simply compiling your source code

  • 23

    and running your unit tests. Or you might want a build job to do other related tasks, such as running yourintegration tests, measuring code coverage or code quality metrics, generating technical documentation,or even deploying your application to a web server. A real project usually requires many separate butrelated build jobs.

    Our sample application is a simple Java implementation of John Conways Game of Life.16 The Gameof Life is a mathematical game which takes place on a two dimensional grid of cells, which we willrefer to as the Universe. Each cell can be either alive or dead. Cells interact with their direct neighborsto determine whether they will live or die in the next generation of cells. For each new generation ofcells, the following rules are applied:

    Any live cell with fewer than two live neighbors dies of underpopulation.

    Any live cell with more than three live neighbors dies of overcrowding.

    Any live cell with two or three live neighbors lives on to the next generation.

    Any dead cell with exactly three live neighbors becomes a live cell.

    Our application is a Java module, built using Maven, that implements the core business logic of theGame of Life. Well worry about the user interfaces later on. For now, lets see how we can automatethis build in Jenkins. If you are not familiar with Maven, or prefer Ant or another build frameworkdont worry! The examples dont require much knowledge of Maven, and well be looking at plenty ofexamples of using other build tools later on in the book.

    For our first build job, we will keep it simple: we are just going to compile and test our sampleapplication. Click on the New Job link. You should get to a screen similar to Figure 2.14, Setting upyour first build job in Jenkins. Jenkins supports several different types of build jobs. The two mostcommonly-used are the freestyle builds and the Maven 2/3 builds. The freestyle projects allow you toconfigure just about any sort of build job: they are highly flexible and very configurable. The Maven2/3 builds understand the Maven project structure, and can use this to let you set up Maven build jobswith less effort and a few extra features. There are also plugins that provide support for other types ofbuild jobs. Nevertheless, although our project does use Maven, we are going to use a freestyle build job,just to keep things simple and general to start with. So choose Build a freestyle software project, asshown in Figure 2.14, Setting up your first build job in Jenkins.

    Youll also need to give your build job a sensible name. In this case, call it gameoflife-default, as it willbe the default CI build for our Game of Life project.

    16See http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life.

    http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

  • 24

    Figure 2.14. Setting up your first build job in Jenkins

    Once you click on OK, Jenkins will display the project configuration screen (see Figure 2.15, TellingJenkins where to find the source code).

    In a nutshell, Jenkins works by checking out the source code of your project and building it in its ownworkspace. So the next thing you need to do is to tell Jenkins where it can find the source code for yourproject. You do this in the Source Code Management section (see Figure 2.15, Telling Jenkins whereto find the source code). Jenkins provides support for CVS and Subversion out of the box, and manyothers such as Git, Mercurial, ClearCase, Perforce and many more via plugins.

    For this project, we will be getting the source code from the GitHub repository we set up earlier.On the Jenkins screen, choose Git and enter the Repository URL we defined in Section 2.2.5,Forker le dpt des exemples (see Figure 2.15, Telling Jenkins where to find the source code).Make sure this is the URL of your fork, and not of the original repository: it should have the formgit@github.com:/game-of-life.git, where is the username for your ownGitHub account. You can leave all of the other options up until here with their default values.

  • 25

    Figure 2.15. Telling Jenkins where to find the source code

    Once we have told Jenkins where to find the source code for our application, we need to tell it how oftenit should check for updates. We want Jenkins to monitor the repository and start a build whenever anychanges have been committed. This is a common way to set up a build job in a Continuous Integrationcontext, as it provides fast feedback if the build fails. Other approaches include building on regularintervals (for example, once a day), requiring a user to kick of the build manually, or even triggering abuild remotely using a post-commit hook in your SCM.

    We configure all of this in the Build Triggers section (see Figure 2.16, Scheduling the build jobs).Pick the Poll SCM option and enter * * * * * (thats five asterisks separated by spaces) in the Schedulebox. Jenkins schedules are configured using the cron syntax, well-known in the Unix world. The cronsyntax consists of five fields separated by white space, indicating respectively the minute (059), hour(023), day of the month (131), month (112) and the day of the week (07, with 0 and 7 being Sunday).The star is a wildcard character which accepts any valid value for that field. So five stars basically meansevery minute of every hour of every day. You can also provide ranges of values: * 9-17 * * * wouldmean every minute of every day, between 9am and 5pm. You can also space out the schedule usingintervals: */5 * * * * means every 5 minutes, for example. Finally, there are some other convenientshort-hands, such as @daily and @hourly.

  • 26

    Dont worry if your Unix skills are a little rustyif you click on the blue question mark icon on the sideof the schedule box, Jenkins will bring up a very complete refresher.

    Figure 2.16. Scheduling the build jobs

    The next step is to configure the actual build itself. In a freestyle build job, you can break down yourbuild job into a number of build steps. This makes it easier to organize builds in clean, separate stages.For example, a build might run a suite of functional tests in one step, and then tag the build in a secondstep if all of the functional tests succeed. In technical terms, a build step might involve invoking anAnt task or a Maven target, or running a shell script. There are also Jenkins plugins that let you useadditional types of build steps: Gant, Grails, Gradle, Rake, Ruby, MSBuild and many other build toolsare all supported.

    For now, we just want to run a simple Maven build. Scroll down to the Build section and click on theAdd build step and choose Invoke top-level Maven targets (see Figure 2.17, Adding a build step).Then enter clean package in the Goals field. If you are not familiar with Maven, this will delete anyprevious build artifacts, compile our code, run our unit tests, and generate a JAR file.

    Figure 2.17. Adding a build step

    By default, this build job will fail if the code does not compile or if any of the unit tests fail. Thatsthe most fundamental thing that youd expect of any build server. But Jenkins also does a great job ofhelping you display your test results and test result trends.

    The de facto standard for test reporting in the Java world is an XML format used by JUnit. This format isalso used by many other Java testing tools, such as TestNG, Spock and Easyb. Jenkins understands thisformat, so if your build produces JUnit XML test results, Jenkins can generate nice graphical test reportsand statistics on test results over time, and also let you view the details of any test failures. Jenkins also

  • 27

    keeps track of how long your tests take to run, both globally, and per testthis can come in handy ifyou need to track down performance issues.

    So the next thing we need to do is to get Jenkins to keep tabs on our unit tests.

    Go to the Post-build Actions section (see Figure 2.18, Configuring JUnit test reports and artifactarchiving) and tick Publish JUnit test result report checkbox. When Maven runs unit tests in a project,it automatically generates the XML test reports in a directory called surefire-reports in the targetdirectory. So enter **/target/surefire-reports/*.xml in the Test report XMLs field. The two asterisksat the start of the path (**) are a best practice to make the configuration a bit more robust: they allowJenkins to find the target directory no matter how we have configured Jenkins to check out the sourcecode.

    Another thing you often want to do is to archive your build results. Jenkins can store a copy of the binaryartifacts generated by your build, allowing you to download the binaries produced by a build directlyfrom the build results page. It will also post the latest binary artifacts on the project home page, which isa convenient way to distribute the latest and greatest version of your application. You can activate thisoption by ticking the Archive the artifacts checkbox and indicating which binary artifacts you wantJenkins to archive. In Figure 2.18, Configuring JUnit test reports and artifact archiving, for example,we have configured Jenkins to store all of the JAR files generated by this build job.

    Figure 2.18. Configuring JUnit test reports and artifact archiving

    Now were donejust click on the Save button at the bottom of the screen. Our build job should nowbe ready to run. So lets see it in action!

    2.6. Your First Build Job in ActionOnce you save your new build job, Jenkins will display the home page for this job (see Figure 2.19,Your first build job running). This is where Jenkins displays details about the latest build results andthe build history.

    If you wait a minute or so, the build should kick off automaticallyyou can see the stripy progress barin the Build History section in the bottom left hand corner of Figure 2.19, Your first build job running.Or, if you are impatient, you can also trigger the build manually using the Build Now button.

  • 28

    Figure 2.19. Your first build job running

    The build will also now figure proudly on your Jenkins servers home page (see Figure 2.20, TheJenkins dashboard). This page shows a summary of all of your build jobs, including the current buildstatus and general state of heath of each of your builds. It tells you when each build ran successfully forthe last time, and when it last failed, and also the result of the last build.

    Once of Jenkinss specialities is the way it lets you get an idea of build behavior over time. For example,Jenkins uses a weather metaphor to help give you an idea of the stability of your builds. Essentially,the more your builds fail, the worse the weather gets. This helps you get an idea of whether a particularbroken build is an isolated event, or if the build is breaking on a regular basis, in which case it mightneed some special attention.

    You can also manually trigger a build job here, using the build schedule button (thats the one that looksa bit like a green play button on top of a clock).

    Figure 2.20. The Jenkins dashboard

  • 29

    When the build finishes, the ball in the Build History box becomes solid blue. This means the build wasa success. Build failures are generally indicated by a red ball. For some types of project, you can alsodistinguish between a build error (such as a compiler error), indicated by a red ball, and other sorts ofbuild failures, such as unit test failures or insufficient code coverage, which are indicated by a yellowball. There are also some other details about the latest test results, when the last build was run, and so on.But before we look at the details, lets get back to the core business model of a Continuous Integrationserverkicking off builds when someone changes the code!

    We are going to commit a code change to GitHub and see what happens, using the source code wechecked out in Section 2.2.5, Forker le dpt des exemples. We now have Jenkins configured tomonitor our GitHub fork, so if we make any changes, Jenkins should be able to pick them up.

    So lets make a change. The idea is to introduce a code change that will cause the unit tests to fail. Ifyour Java is a bit rusty, dont worry, you wont need to know any Java to be able to break the buildjust follow the instructions!

    Now in normal development, you would first modify the unit test that describes this behaviour. Thenyou would verify that the test fails with the existing code, and implement the code to ensure that the testpasses. Then you would commit your changes to your version control system, allowing Jenkins to buildthem. However this would be a poor demonstration of how Jenkins handles unit test failures. So in thisexample, we will, against all best practices, simply modify the application code directly.

    First of all, open the Cell.java file, which you will find in the gameoflife-core/src/main/java/com/wakaleo/gameoflife/domain directory. Open this file in your favorite text editor. You shouldsee something like this:

    package com.wakaleo.gameoflife.domain;

    public enum Cell { LIVE_CELL("*"), DEAD_CELL(".");

    private String symbol;

    private Cell(String symbol) { this.symbol = symbol; }

    @Override public String toString() { return symbol; }

    static Cell fromSymbol(String symbol) { Cell cellRepresentedBySymbol = null; for (Cell cell : Cell.values()) { if (cell.symbol.equals(symbol)) { cellRepresentedBySymbol = cell; break; }

  • 30

    } return cellRepresentedBySymbol; }

    public String getSymbol() { return symbol; }}

    The application can print the state of the grid as a text array. Currently, the application prints our livecells as an asterisk (*), and dead cells appear as a minus character (). So a five-by-five grid containinga single living cell in the center would look like this:

    -------*-------

    Now users have asked for a change to the applicationthey want pluses (+) instead of stars! So we aregoing to make a slight change to the Cell class method, and rewrite it as follows (the modificationsare in bold):

    package com.wakaleo.gameoflife.domain;

    public enum Cell { LIVE_CELL("+"), DEAD_CELL(".");

    private String symbol;

    private Cell(String symbol) { this.symbol = symbol; }

    @Override public String toString() { return symbol; }

    static Cell fromSymbol(String symbol) { Cell cellRepresentedBySymbol = null; for (Cell cell : Cell.values()) { if (cell.symbol.equals(symbol)) { cellRepresentedBySymbol = cell; break; } } return cellRepresentedBySymbol; }

    public String getSymbol() { return symbol; }}

  • 31

    Save this change, and then commit them to the local Git repository by running git commit:

    $ git commit -a -m "Changes stars to pluses"[master 61ce946] Changes stars to pluses 1 files changed, 1 insertions(+), 1 deletions(-)

    This will commit the changes locally, but since Git is a distributed repository, you now have to pushthese changes through to your fork on GitHub. You do this by running git push:

    $ git pushCounting objects: 21, done.Delta compression using up to 4 threads.Compressing objects: 100% (7/7), done.Writing objects: 100% (11/11), 754 bytes, done.Total 11 (delta 4), reused 0 (delta 0)To git@github.com:john-smart/game-of-life.git 7882d5c..61ce946 master -> master

    Now go back to the Jenkins web page. After a minute or so, a new build should kick off, and fail. In fact,there are several other places which are affected by this change, and the regression tests related to thesefeatures are now failing. On the build job home page, you will see a second build in the build history withan ominous red ball (see Figure 2.21, A failed build)this tells you that the latest build has failed.

    You might also notice some clouds next to the Build History titlethis is the same weather icon thatwe saw on the home page, and serves the same purposeto give you a general idea of how stable yourbuild is over time.

    Figure 2.21. A failed build

    If you click on the new build history entry, Jenkins will give you some more details about what wentwrong (see Figure 2.22, The list of all the broken tests). Jenkins tells us that there were 11 new test

  • 32

    failures in this build, something which can be seen at a glance in the Test Result Trend graphredindicates test failures. You can even see which tests are failing, and how long they have been broken.

    Figure 2.22. The list of all the broken tests

    If you want to know exactly what went wrong, thats easy enough to figure out as well. If you click onthe failed test classes, Jenkins brings up the actual details of the test failures (see Figure 2.23, Detailsabout a failed test), which is a great help when it comes to reproducing and fixing the issue.

    Figure 2.23. Details about a failed test

  • 33

    Jenkins displays a host of information about the failed test in a very readable form, including the errormessage the test produced, the stack trace, how long the test has been broken, and how long it took torun. Often, this in itself is enough to put a developer on the right track towards fixing the issue.

    Now lets fix the build. To make things simple, well just back out our changes and recommit the codein its original state (the end users just changed their mind about the asterisks, anyway). So just undo thechanges you made to the Cell class (again, the changes are highlighted in bold):

    package com.wakaleo.gameoflife.domain;

    public enum Cell { LIVE_CELL("*"), DEAD_CELL(".");

    private String symbol;

    private Cell(String symbol) { this.symbol = symbol; }

    @Override public String toString() { return symbol; }

    static Cell fromSymbol(String symbol) { Cell cellRepresentedBySymbol = null; for (Cell cell : Cell.values()) { if (cell.symbol.equals(symbol)) { cellRepresentedBySymbol = cell; break; } } return cellRepresentedBySymbol; }

    public String getSymbol() { return symbol; }}

    When youve done this, commit your changes again:

    $ git commit -a -m "Restored the star"[master bc924be] Restored the star 1 files changed, 1 insertions(+), 1 deletions(-)$ git pushCounting objects: 21, done.Delta compression using up to 4 threads.Compressing objects: 100% (7/7), done.Writing objects: 100% (11/11), 752 bytes, done.Total 11 (delta 4), reused 6 (delta 0)To git@github.com:john-smart/game-of-life.git 61ce946..bc924be master -> master

  • 34

    Once youve committed these changes, Jenkins should pick them up and kick off a build. Once this isdone, you will be able to see the fruit of your work on the build job home page (see Figure 2.24, Nowthe build is back to normal)the build status is blue again and all is well. Also notice the way we arebuilding up a trend graph showing the number of succeeding unit tests over timethis sort of reportreally is one of Jenkinss strong points.

    Figure 2.24. Now the build is back to normal

    2.7. More ReportingDisplaying Javadocs

    For many Java projects, Javadoc comments are an important source of low-level technicaldocumentation. There are even tools, such as UmlGraph, that let you produce Javadoc with embeddedUML diagrams to give you a better picture of how the classes fit together in the application. This sort oftechnical documentation has the advantage of being cheap to produce, accurate and always up-to-date.

    Jenkins can integrate Javadoc API documentation directly into the Jenkins website. This way, everyonecan find the latest Javadoc easily, in a well known place. Often, this sort of task is performed in a separatebuild job, but for simplicity we are going to add another build step to the gameoflife-default build jobto generate and display Javadoc documention for the Game of Life API.

    Start off by going into the gameoflife-default configuration screen again. Click on Add build step,and add a new build step to Invoke top level Maven targets (see Figure 2.25, Adding a new build stepand report to generate Javadoc). In the Goals field, place javadoc:javadocthis will tell Maven togenerate the Javadoc documentation.

  • 35

    Figure 2.25. Adding a new build step and report to generate Javadoc

    Now go to the Post-build Action and tick the Publish Javadoc checkbox. This project is amultimodule project, so a separate subdirectory is generated for each module (core, services, web andso forth). For this example, we are interested in displaying the documentation for the core module. Inthe Javadoc directory field, enter gameoflife-core/target/site/apidocsthis is where Mavenwill place the Javadocs it generates for the core module. Jenkins may display an error message sayingthat this directory doesnt exist at first. Jenkins is correctthis directory wont exist until we run thejavadoc:javadoc goal, but since we havent run this command yet we can safely ignore the messageat this stage.

    If you tick Retain Javadoc for each successful build, Jenkins will also keep track of the Javadocs forprevious buildsnot always useful, but it can come in handy at times.

    Now trigger a build manually. You can do this either from the build jobs home page (using the BuildNow link), or directly from the server home page. Once the build is finished, open the build job summarypage. You should now see a Javadoc link featuring prominently on the screenthis link will open thelatest version of the Javadoc documentation (see Figure 2.26, Jenkins will add a Javadoc link to yourbuild results). You will also see this link on the build details page, where it will point to the Javadocfor that particular build, if you have asked Jenkins to store Javadoc for each build.

  • 36

    Figure 2.26. Jenkins will add a Javadoc link to your build results

    2.8. Adding Code Coverage and Other Metrics

    As we mentioned earlier, reporting is one of Jenkinss strong points. We have seen how easy it is todisplay test results and to publish Javadocs, but you can also publish a large number of other very usefulreports using Jenkinss plugins.

    Plugins are another one of Jenkinss selling pointsthere are plugins for doing just about anything,from integrating new build tools or version control systems to notification mechanisms and reporting.In addition, Jenkins plugins are very easy to install and integrate smoothly into the existing Jenkinsarchitecture.

    To see how the plugins work, we are going to integrate code coverage metrics using the Coberturaplugin. Code coverage is an indication of how much of your application code is actually executed duringyour testsit can be a useful tool in particular for finding areas of code that have not been tested byyour test suites. It can also give some indication as to how well a team is applying good testing practicessuch as Test-Driven Development or Behavior-Driven Development.

    Cobertura17 is an open source code coverage tool that works well with both Maven and Jenkins. OurMaven demonstration project is already configured to record code coverage metrics, so all we needto do is to install the Jenkins Cobertura plugin and generate the code coverage metrics for Jenkins torecord and display.

    17 http://cobertura.sourceforge.net

    http://cobertura.sourceforge.nethttp://cobertura.sourceforge.net

  • 37

    Figure 2.27. Jenkins has a large range of plugins available

    To install a new plugin, go to the Manage Jenkins page and click on the Manage Plugins entry. Thiswill display a list of the available plugins as well as the plugins already installed on your server (seeFigure 2.27, Jenkins has a large range of plugins available). If your build server doesnt have anInternet connection, you can also manually install a plugin by downloading the plugin file elsewhere anduploading it to your Jenkins installation (just open the Advanced tab in Figure 2.27, Jenkins has a largerange of plugins available), or by copying the plugin to the $JENKINS_HOME/plugins directory.

    In our case, we are interested in the Cobertura plugin, so go to the Available tab and scroll down untilyou find the Cobertura Plugin entry in the Build Reports section. Click on the checkbox and then clickon the Install button at the bottom of the screen.

    This will download and install the plugin for you. Once it is done, you will need to restart your Jenkinsinstance to see the fruits of your labor. When you have restarted Jenkins, go back to the Manage Pluginsscreen and click on the Installed tabthere should now be a Cobertura Plugin entry in the list of installedplugins on this page.

    Once you have made sure the plugin was successfully installed, go to the configuration page for thegameoflife-default build job.

    To set up code coverage metrics in our project, we need to do two things. First we need to generate theCobertura coverage data in an XML form that Jenkins can use; then we need to configure Jenkins todisplay the coverage reports.

    Our Game of Life project already has been configured to generate XML code coverage reports if weask it. All you need to do is to run mvn cobertura:cobertura to generate the reports in XML form.Cobertura can also generate HTML reports, but in our case we will be letting Jenkins take care of thereporting, so we can save on build time by not generating the For this example, for simplicity, we willjust add the cobertura:cobertura goal to the second build step (see Figure 2.28, Adding anotherMaven goal to generating test coverage metrics). You could also add a new build step just for the code

  • 38

    coverage metrics. In a real-world project, code quality metrics like this are typically placed in a distinctbuild job, which is run less frequently than the default build.

    Figure 2.28. Adding another Maven goal to generating test coverage metrics

    Next, we need to tell Jenkins to keep track of our code coverage metrics. Scroll down to the Post-buildActions section. You should see a new checkbox labeled Publish Cobertura Reports. Jenkins will oftenadd UI elements like this when you install a new plugin. When you tick this box, Jenkins will display theconfiguration options for the Cobertura plugin that we installed earlier (see Figure 2.29, Configuringthe test coverage metrics in Jenkins).

    Like most of the code-quality related plugins in Jenkins, the Cobertura plugin lets you fine-tune not onlythe way Jenkins displays the report data, but also how it interprets the data. In the Coverage MetricsTargets section, you can define what you consider to be the minimum acceptable levels of code coverage.In Figure 2.29, Configuring the test coverage metrics in Jenkins, we have configured Jenkins to listany builds with less than 50% test coverage as unstable (indicated by a yellow ball), and notify theteam accordingly.

  • 39

    Figure 2.29. Configuring the test coverage metrics in Jenkins

    This fine-tuning often comes in handy in real-world builds. For example, you may want to impose aspecial code coverage constraint in release builds, to ensure high code coverage in release versions.Another strategy that can be useful for legacy projects is to gradually increase the minimum toleratedcode coverage level over time. This way you can avoid having to retro-fit unit tests on legacy code justto raise the code coverage, but you do encourage all new code and bug fixes to be well tested.

    Now trigger a build manually. The first time you run the build job with Cobertura reporting activated,you will see coverage statistics for your build displayed on the build home page, along with a CoverageReport link when you can go for more details (see Figure 2.30, Jenkins displays code coverage metricson the build home page). The Cobertura report shows different types of code coverage for the buildwe just ran. Since we have only run the test coverage metrics once, the coverage will be displayed asred and green bars.

  • 40

    Figure 2.30. Jenkins displays code coverage metrics on the build home page

    If you click on the Coverage Report icon, you will see code coverage for each package in yourapplication, and even drill down to see the code coverage (or lack thereof) for an individual class (seeFigure 2.31, Jenkins lets you display code coverage metrics for packages and classes). When you getto this level, Jenkins displays both the overall coverage statistics for the class, and also highlights thelines that were executed in green, and those that werent in red.

    This reporting gets better with time. Jenkins not only reports metrics data for the latest build, but alsokeeps track of metrics over time, so that you can see how they evolve throughout the life of the project.

    For example, if you drill down into the coverage reports, you will notice that certain parts of this codeare not tested (for example the Cell.java class in Figure 2.31, Jenkins lets you display code coveragemetrics for packages and classes).

  • 41

    Figure 2.31. Jenkins lets you display code coverage metrics for packages and classes

    Code coverage metrics are a great way to isolate code that has not been tested, in order to add extratests for corner cases that were not properly tested during the initial development, for example. TheJenkins code coverage graphs are also a great way of keeping track of your code coverage metrics asthe project grows. Indeed, as you add new tests, you will notice that Jenkins will display a graph ofcode coverage over time, not just the latest results (see Figure 2.32, Jenkins also displays a graph ofcode coverage over time).

  • 42

    Figure 2.32. Jenkins also displays a graph of code coverage over time

    Note that our objective here is not to improve the code coverage just for the sake of improving codecoveragewe are adding an extra test to verify some code that was not previously tested, and as a resultthe code coverage goes up. There is a subtle but important difference herecode coverage, as with anyother metric, is very much a means to an end (high code quality and low maintenance costs), and notan end in itself.

    Nevertheless, metrics like this can give you a great insight into the health of your project, and Jenkinspresents them in a particularly accessible way.

    This is just one of the code quality metrics plugins that have been written for Jenkins. There are manymore (over fifty reporting plugins alone at the time of writing). Well look at some more of them inChapter 9, Qualit du Code.

    2.9. ConclusionIn this chapter, we have gone through what you need to know to get started with Jenkins. You shouldbe able to set up a new build job, and setting up reporting on JUnit test results and javadocs. And youhave seen how to add a reporting plugin and keep tabs on code coverage. Well done! But theres still alot more to learn about Jenkinsin the following chapters, we will be looking at how Jenkins can helpyou improve your build automation process in many other areas as well.

  • Chapter 3. Installer Jenkins3.1. Introduction L'une des premires choses que vous avez d remarquer propos de Jenkins, c'est qu'il est trs simple installer. En effet, en moins de cinq minutes, vous pouvez avoir un serveur Jenkins install et disponible.Nanmoins, comme toujours, dans le monde rel, les choses ne sont pas aussi simples, et il y a quelquesdtails auxquelles vous devez penser lorsque vous installez un serveur Jenkins en production. Dans cechapitre, nous allons voir comment installer Jenkins sur votre poste de travail ou sur un vritable serveur.Nous allons galement voir comment entretenir votre installation de Jenkins une fois en production, etcomment raliser les actions de maintenance simples comme les sauvegardes et les mises jour.

    3.2. Tlcharger et installer JenkinsJenkings est simple installer, et vous pouvez le faire tourner n'importe o. Vous pouvez le lancer soitcomme une application, ou le dployer dans un conteneur d'application Java classique comme Tomcatou JBoss. La premire option est simple mettre oeuvre, et permet de tester Jenkins sur votre postede travail, en quelques minutes, vous pouvez installer et lancer une version minimaliste de Jenkins.

    Jenkins tant une application Java, vous aurez besoin d'une version rcente de Java sur votre machine.Plus prcisment, vous aurez besoin de Java 5. En fait, sur votre serveur, vous aurez mme certainementbesoin du Java Development Kit (JDK) 5.0 ou d'une version suprieure pour excuter vos builds. Sivous n'en tes pas sr, vous pouvez vrifier en xcutant la commande suivante sur votre machine :java -version

    $ java -version java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

    Jenkins est disponible sous la forme d'une application Java package (un fichier WAR). Vous pouveztlcharger la dernire version sur le site web de Jenkins ( http://jenkins-ci.org voir Figure 3.1, Vouspouvez tlcharger les binaires de Jenkins sur le site web de Jenkins ) ou depuis le site web du livre.Jenkins est un projet actif, et de nouvelles versions sont disponibles rgulirement.

    Pour les utilisateurs de Windows, il existe un installateur Windows pour Jenkins. L'installateur seprsente sous la forme d'un fichier zip contenant un package MSI pour Jenkins, ainsi qu'un fichiersetup.exe pouvant tre utilis pour installer les librairies .NET si elles n'ont pas dj t installes survotre poste. Dans la plupart des cas, tout ce que vous aurez faire sera de dcompresser le fichier zip etde lancer le fichier jenkins-x.x.msi (voir Figure 3.2, L'assistant de configuration sous Windows

    http://jenkins-ci.org

  • 44

    ). L'installateur MSI est livr avec une version du JRE intgr, il n'est donc pas ncessaire d'avoir uneversion de Java installe.

    Figure 3.1. Vous pouvez tlcharger les binaires de Jenkins sur le site web de Jenkins

    Une fois que vous avez lanc l'installateur, Jenkins dmarrera automatiquement sur le port 8080 (voirFigure 3.3, La page d'accueil de Jenkins ). L'installateur crra un service Jenkins pour vous, que vouspourrez dmarrer et arrter comme n'importe quel autre service Windows.

    Il existe galement de trs bon installateurs pour Mac OS X et galement pour la plupart des distributionsLinux, comme Ubuntu, RedHat (incluant CentOS et Fedora) et OpenSolaris. Nous expliqueronscomment installer Jenkins sur Ubuntu et RedHat plus loin.

    Si vous n'installez pas Jenkins via l'une des installations natives, vous pouvez simplement tlchargerla dernire installation depuis le site web de Jenkins. Une fois que vous aurez tlcharg la dernireinstallation de Jenkins, copiez le dans un rpertoire appropri sur votre serveur de build. Dansun environnement Windows, vous devriez installer Jenkins dans un rpertoire comme C:\Tools\Jenkins (il est prfrable de ne pas installer Jenkins dans un rpertoire contenant des espaces, commepar exemple C:\Program Files , cel peut causer des problmes dans certains cas). Sur un serveurLinux ou Unix, vous pouvez l'installer dans /usr/local/jenkins , /opt/jenkins , ou dans unautre rpertoire, selon vos conventions et les prfrences de votre administrateur systme.

  • 45

    Figure 3.2. L'assistant de configuration sous Windows

    Avant d'aller plus loin, dmarrons simplement Jenkins et jetons-y un coup d'oeil. Si vous ne l'avez pasencore test dans les chapitres prcdents, il est temps de vous salir les mains. Ouvrez une invite decommande dans le rpertoire contenant le fichier jenkins.war et lancez la commande suivante:

    $ java -jar jenkins.war [Winstone 2008/07/01 20:54:53] - Beginning extraction from war file ... INFO: Took 35 ms to load ... [Winstone 2008/07/01 20:55:08] - HTTP Listener started: port=8080 [Winstone 2008/07/01 20:55:08] - Winstone Servlet Engine v0.9.10 running: controlPort=disabled [Winstone 2008/07/01 20:55:08] - AJP13 Listener started: port=8009

    Jenkins devrait tre disponible sur le port 8080. Ouvrez votre navigateur et allez l'adresse http://localhost:8080 et jetez y un oeil. (voir Figure 3.3, La page d'accueil de Jenkins ).

    http://localhost:8080http://localhost:8080

  • 46

    Figure 3.3. La page d'accueil de Jenkins

    3.3. Prparation d'un serveur de build pour JenkinsL'installation de Jenkins sur votre machine locale de dveloppement est une chose, mais l'installationde Jenkins sur un bon serveur de build mrite un peu plus de prvoyance et de planification.

    Avant de commencer votre installation, la premire chose dont vous aurez besoin est un serveur debuild. Pour fonctionner correctement, Jenkins a besoin la fois d'un processeur puissant et de mmoire.Jenkins, pour sa part, est une application web Java relativement modeste. Cependant, pour la majoritdes configurations, au moins une partie des builds sera excute sur le serveur de build principal. Lesbuilds ont tendance tre la fois gourmand en mmoire et en temps processeur, et Jenkins peut treconfigur pour excuter plusieurs builds en parallle. Selon le nombre de tches de build que vous grez,Jenkins aura aussi besoin de mmoire ddie pour son propre usage interne. La quantit de mmoirencessaire dpendra en grande partie de la nature de vos builds, mais la mmoire n'est pas cher cestemps-ci (du moins pour des environnements non hbergs), et il vaut mieux ne pas tre avare.

    Un serveur de build a aussi besoin d'un CPU puissant. En rgle gnrale, vous aurez besoin d'unprocesseur par build parallle, mme si, dans la practique, vous pouvez capitaliser sur les dlais d'E/S pour faire un peu mieux que cela. Il est galement dans votre intrt de ddier votre serveur debuild, autant que possible, la tche de gestion des builds continus. En particulier, vous devriez viterles applications gourmandes en mmoire ou en CPU tels que les serveurs de test, les applicationsd'enterprise fortement utilises, les base de donnes d'entreprise tel que Oracle, les serveurs demessagerie d'entreprise, et ainsi de suite .

    Une option vraiment pratique, disponible dans de nombreuses organisations aujourd'hui, est d'utliserune machine virtuelle. De cette faon, vous pouvez choisir la quantit de mmoire et le nombre deprocesseurs que vous jugez appropris pour votre installation initiale, et d'ajouter facilement de la

  • 47

    mmoire et des processeurs plus tard si ncessaire. Cependant, si vous utilisez une machine virtuelle,assurez-vous qu'elle dispose de suffisamment de mmoire pour supporter le nombre maximal debuilds en parallle auquel vous vous attendez tre excut. L'utilisation de la mmoire d'un serveurd'intgration continue peut-tre vue comme des dents de scie Jenkins crera, au besoin, des JVMssupplmentaires pour ses tches de build, et celles-ci ont besoin de mmoire.

    Une autre approche utile est de configurer plusieurs machines de build. Jenkins rend facile la miseen place d'esclaves sur d'autres machines qui peuvent tre utilises pour excuter des tches de buildadditionnelles. Les esclaves restent inactifs jusqu' ce qu'une nouvelle tche de build soit demande puis l'installation principale de Jenkins envoie la tche de build un esclave et rend compte des rsultats.C'est une excellente faon d'absorber les pointes soudaines de l'activit de build, par exemple juste avantune livraison majeure de votre principal produit. C'est aussi une stratgie utile si certains gros builds onttendance accaparer le serveur de build principal il suffit de les mettre sur leur propre agent debuild ! Nous verrons comment faire cela en dtail plus loin dans ce livre.

    Si vous installez Jenkins sur un serveur de build Linux ou Unix, cela peut-tre une bonne ide de crerun utilisateur spcial (et un groupe utilisateur) pour Jenkins. Cela rend plus facile de surveiller d'un coupd'oeil les ressources systme utilises par les builds de Jenkins, et ainsi rsoudre les builds qui posentproblme en conditions relles. Les paquets d'installation des binaires natifs dcrits ci-dessous font celapour vous. Si vous n'avez pas utilis l'un d'entre eux, vous pouvez crer un utilisateur Jenkins ddidepuis la ligne de commande comme montr ici:

    $ sudo groupadd build $ sudo useradd --create-home --shell /bin/bash --groups build jenkins

    Les dtails exacts peuvent varier en fonction de votre environnement. Par exemple, vous prfrerez peut-tre utiliser une console d'administration graphique au lieu de la ligne de commande, ou, sur un serveurLinux bas sur une Debian (comme Ubuntu), vous pouvez utiliser des commandes plus convivialescomme : adduser et addgroup .

    Dans la majorit des environnements, vous devrez configurer correctement Java pour cet utilisateur. Parexemple, vous pouvez le faire en dfinissant les variables JAVA_HOME et PATH dans le fichier .bashrc, comme montr ici:

    export JAVA_HOME=/usr/local/java/jdk1.6.0 export PATH=$JAVA_HOME/bin:$PATH

    Vous devriez maintenant tre en mesure d'utiliser cet utilisateur pour excuter Jenkins dans unenvironnement isol.

  • 48

    3.4. Le rpertoire de travail de Jenkins Avant que nous installions Jenkins, toutefois, il y a certaines choses que vous devez savoir sur la faondont Jenkins stocke ses donnes. En effet, peu importe o vous stockez le fichier WAR de Jenkins,Jenkins conserve toutes ses donnes importantes dans un rpertoire spcial spar appel le rpertoirede travail Jenkins. Ici, Jenkins stocke les informations sur la configuration de votre serveur de build, vostches de build, les artefacts de build, les comptes utilisateur, et d'autres informations utiles, ainsi quetous les plugins que vous avez install. Le formart du rpertoire de travail de Jenkins est rtro compatibleentre les versions, donc vous pouvez librement mettre jour ou r-installer votre excutable Jenkinssans affecter votre rpertoire de travail Jenkins.

    Il va sans dire que ce rpertoire aura besoin de beaucoup d'espace disque.

    Par dfaut, le rpertoire de travail Jenkins sera appel .jenkins, et sera plac dans votre rprtoire detravail. Par exemple, si vous utilisez une machine sous Windows 7 et si votre nom d'utilisateur est john,vous trouverez le rpertoire de travail Jenkins sous C:\Users\john\.jenkins . Sous Windows XP,ce serait C:\Documents and Settings\John\.jenkins . Sur une machine Linux, ce seraitprobablement sous /home/john/.jenkins . Et ainsi de suite.

    Vous pouvez forcer Jenkins utiliser un rpertoire diffrent pour son rpertoire de travail en dfinissantla variable d'environnement JENKINS_HOME . Vous pourriez avoir besoin de le faire sur une serveurde build pour vous conformer aux conventions du rpertoire local ou pour rendre votre administrateursystme heureux. Par exemple, si votre fichier WAR Jenkins est install dans /usr/local/jenkins ,et que le rpertoire de travail Jenkins a besoin d'tre dans le rpertoire /data/jenkins , vous pourriezcrire un script de dmarrage comme suit :

    export JENKINS_BASE=/usr/local/jenkins export JENKINS_HOME=/var/jenkins-data java -jar ${JENKINS_BASE}/jenkins.war

    Si vous utilisez Jenkins dans un conteneur Java EE comme Tomcat ou JBoss, vous pouvez configurer lawebapp pour exposer ses propres variables d'environnement. Par exemple, si vous utilisez Tomcat, vouspouvez crer un fichier appel jenkins.xml dans le rpertoire $CATALINA_BASE/conf/localhost:

    Dans une vie antrieure, Jenkins tait connu sous le nom de Hudson. Jenkins reste compatible avec lesinstallations prcdentes de Hudson, et le passage de Hudson Jenkins peut-tre aussi simple que deremplacer l'ancien fichier hudson.war par jenkins.war . Jenkins cherchera son rpertoire de travaildans les places suivantes (par ordre de prsance):

  • 49

    1. Une entre d'environnement JNDI appele JENKINS_HOME

    2. Une entre d'environnement JNDI appele HUDSON_HOME

    3. Une proprit systme nomme JENKINS_HOME

    4. Une proprit systme nomme HUDSON_HOME

    5. Une variable d'environnement nomme JENKINS_HOME

    6. Une variable d'environnement nomme HUDSON_HOME

    7. Le rpertoire .hudson dans le rpertoire de travail utilisateur, s'il existe dj

    8. Le rpertoire .jenkins dans le rpertoire de travail utilisateur

    3.5. Installer Jenkins sur Debian ou Ubuntu Si vous installez Jenkins sur Debian et Ubuntu, il est commode d'installer le paquet binaire natif pources plates-formes. Cela est assez simple faire, mme si ces binaires ne sont pas fournis dans les dptsstandard en raison de la frquence leve des mises jour. Premirement, vous devez ajouter la cl votre systme comme indiqu ici:

    $ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key \ | sudo apt-key add - $ sudo echo "deb http://pkg.jenkins-ci.org/debian binary/" > \ /etc/apt/sources.list.d/jenkins.list

    Maintenant, mettez jour le rfrentiel des paquets Debian :

    $ sudo aptitude update

    Une fois que cela est fait, vous pouvez installer Jenkins en utilisant l'outil aptitude :

    $ sudo aptitude install -y jenkins

    Ceci installera Jenkins comme un service, avec un script de dmarrage correctement configur dans /etc/init.d/jenkins et un utilisateur systme correspondant nomm jenkins. Si vous n'avez pas

  • 50

    dj Java d'install sur votre serveur, ceci installera aussi la verion OpenJDK de Java. Par dfaut, voustrouverez le fichier WAR de Jenkins dans le rpertoire /usr/share/jenkins , et le rpertoire detravail de Jenkins dans /var/lib/jenkins .

    Le processus d'installation devrait avoir dmarr Jenkins. En gnral, pour dmarrer Jenkins, excutezsimplement ce script:

    $ sudo /etc/init.d/jenkins start

    Jenkins va maintenant tre excut sur le port par dfaut : 8080 ( http://localhost:8080/ ).

    Vous pouvez arrter Jenkins comme il suit :

    $ sudo /etc/inid.d/jenkins stop

    Jenkins crira les fichiers de journalisation dans /var/log/jenkins/jenkins.log . Vous pouvezaussi affiner les paramtres de configuration dans le fichier /etc/default/jenkins . Ceci peut-treutile si vous avez besoin de modifier les arguments de de dmarrage de Java (JAVA_ARGS). Vouspouvez aussi utiliser ce fichier pour configurer les arguments qui seront passs Jenkins, comme le portHTTP ou le contexte d'application web (voir Section 3.8, Excuter Jenkins comme une applicationautonome ).

    3.6. Installer Jenkins sur Redhat, Fedora ou CentOS Il existe galement des paquets binaires natifs pour Redhat, Fedora et CentOS. Il vous faut d'abordconfigurer le rfrentiel comme il suit :

    $ sudo wget -O /etc/yum.repos.d/jenkins.repo \ http://jenkins-ci.org/redhat/jenkins.repo $ sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

    Sur une nouvelle installation, vous devrez peut-tre installer le JDK:

    $ sudo yum install java-1.6.0-openjdk

    http://localhost:8080/

  • 51

    Ensuite, vous pouvez installer le paquet comme montr ici :

    $ sudo yum install jenkins

    Ceci installera la dernire version de Jenkins dans le rpertoire /usr/lib/jenkins . Le rpertoire detravail par dfaut de Jenkins sera /var/lib/jenkins .

    Vous pouvez maintenant dmarrer Jenkins en utilisant la commande de service :

    $ sudo service jenkins start

    Jenkins va maintenant tre excut sur le port par dfaut : 8080 ( http://localhost:8080/ ).

    Les paramtres de configuration de Jenkins sont placs dans le fichier /etc/sysconfig/jenkins. Cependant, au moment de l'criture de ce livre, les options de configuration sont plus limites quecelles fournies par le paquet Ubuntu : vous pouvez dfinir le port HTTP en utilisant le paramtreJENKINS_PORT, par exemple, mais pour spcifier un contexte d'application vous devez modifier lescript de dmarrage la main. Les principales options de configuration sont listes ici :

    JENKINS_JAVA_CMDLa version de Java que vous voulez utiliser pour excuter Jenkins

    JENKINS_JAVA_OPTIONSLes options de ligne de commande passer Java, tels que les options de mmoire

    JENKINS_PORTLe port sur lequel Jenkins sera excut

    3.7. Installer Jenkins sur SUSE ou OpenSUSELes paquets binaires sont aussi disponibles pour SUSE et OpenSUSE, donc le processus d'installationprocess sur ces plates-formes est simple. Premirement, vous devez ajouter le dpt Jenkins la listedes dpts SUSE :

    $ sudo zypper addrepo http://pkg.jenkins-ci.org/opensuse/ jenkins

    Enfin, il vous suffit d'installer Jenkins en utilisant la commande zypper :

    http://localhost:8080/

  • 52

    $ sudo zypper install jenkins

    Comme vous pouvez le voir sur la sortie de la console, ceci installera la fois Jenkins et le dernierJDK de Sun, si ce dernier n'est pas dj install. Les installations OpenSuse ont gnralement la versionOpenJDK de Java, mais Jenkins prfre celle de Sun. Lors du tlchargement JDK de Sun, il vous serademand de valider la licence de Java Sun avant de continuer l'installation.

    Ce processus d'installation crera aussi un utilisateur jenkins et installera Jenkins en tant queservice, de sorte qu'il se lancera automatiquement chaque dmarrage de la machine. Pour dmarrermanuellement Jenkins, vous pouvez appeler le script de dmarrage jenkins depuis le rpertoire /etc/init.d :

    $ sudo /etc/init.d/jenkins jenkins start

    Jenkins sera maintenant excut par dfaut sur le port 8080 ( http://localhost:8080/ ).

    Les options de configuration sont similaires celles de l'installation pour Redhat (voir Section 3.6,Installer Jenkins sur Redhat, Fedora ou CentOS ). Vous pouvez dfinir un nombre limit devariables de configuration dans le fichier /etc/sysconfig/jenkins , mais pour toutes les options deconfiguration avances, vous devrez modifier le script de dmarrage dans /etc/init.d/jenkins .

    L'outil zypper facilite aussi la mise jour de votre instance Jenkins:

    $ sudo zypper update jenkins

    Ceci tlchargera et installera la dernire version de Jenkins depuis le site de Jenkins .

    3.8. Excuter Jenkins comme une application autonomeVous pouvez excuter le serveur Jenkins d'une des deux manires suivantes : soit comme uneapplication autonome, soit deploy comme une application web standard sur un conteneur de servletsJava ou un serveur d'application comme Tomcat, JBoss, ou GlassFish. Les deux approches ont leursavantages et leurs inconvnients, nous allons donc examiner les deux ici.

    Jenkins est fourni sous la forme d'un fichier WAR que vous pouvez excuter directement en utilisantun conteneur de servlet intgr. Jenkins utilise le moteur de servlet lger Winstone pour vous permettred'excuter le serveur directement, sans avoir configurer un serveur web par vous-mme. C'estprobablement la meilleure faon de commencer, vous permettant d'tre oprationnel avec Jenkins enquelques minutes. C'est aussi une option trs flexible, offrant quelques fonctionnalits supplmentaires

    http://localhost:8080/

  • 53

    non-accessibles si vous dployez Jenkins sur un serveur d'application classique. En particulier, si vousexcutez Jenkins en tant que serveur autonome, vous serez en mesure d'installer et mettre jour lesplugins la vole, et de redmarrer Jenkins directement depuis les crans d'administration.

    Pour excuter Jenkins en utilisant le conteneur de servlet intgr, allez la ligne de commande et entrezla commande suivante :

    C:\Program Files\Jenkins> java -jar jenkins.war [Winstone 2011/07/01 20:54:53] - Beginning extraction from war file [Winstone 2011/07/01 20:55:07] - No webapp classes folder found - C:\Users\john\ .jenkins\war\WEB-INF\classes jenkins home directory: C:\Users\john\.jenkins ... INFO: Took 35 ms to load ... [Winstone 2011/07/01 20:55:08] - HTTP Listener started: port=8080 [Winstone 2011/07/01 20:55:08] - Winstone Servlet Engine v0.9.10 running: controlPort=disabled [Winstone 2011/07/01 20:55:08] - AJP13 Listener started: port=8009

    Dans un environnement Linux, la procure est similaire. Notez comment mous dmarrons le serveurJenkins partir du compte utilisateur jenkins que nous avons cr plus tt :

    john@lambton:~$ sudo su - jenkins jenkins@lambton:~$ java -jar /usr/local/jeknins/jenkins.war [Winstone 2011/07/16 02:11:24] - Beginning extraction from war file [Winstone 2011/07/16 02:11:27] - No webapp classes folder found - /home/jenkins/ .jenkins/war/WEB-INF/classes jenkins home directory: /home/jenkins/.jenkins ... [Winstone 2011/07/16 02:11:31] - HTTP Listener started: port=8080 [Winstone 2011/07/16 02:11:31] - AJP13 Listener started: port=8009 [Winstone 2011/07/16 02:11:31] - Winstone Servlet Engine v0.9.10 running: controlPort=disabled

    Cela dmarrera le moteur de servlet intgr dans la fentre de la console. L'application Web Jenkins seramaintenant disponible sur le port 8080. Lorsque vous excutez Jenkins en utilisant le serveur intgr,il n'y a pas de contexte d'application Web, donc vous accdez Jenkins directement en utilisant l'URLdu serveur (e.g., http://localhost:8080 ).

    Pour arrter Jenkins, pressez simplement Ctrl-C.

    Par dfaut, Jenkins s'excutera sur le port 8080. Si cela ne convient pas votre environnement, vouspouvez spcifier le port manuellement, en utilisant l'option --httpPort :

    http://localhost:8080

  • 54

    $ java -jar jenkins.war --httpPort=8081

    Dans une architecture relle, Jenkins peut ne pas tre la seule application Web s'excuter sur votreserveur de build. Selon la capacit de votre serveur, Jenkins peut avoir cohabiter avec d'autresapplications Web ou des gestionnaires de dpts Maven, par exemple. Si vous excutez Jenkins auxcts d'un autre serveur d'application, tels que Tomcat, Jetty ou GlassFish, vous aurez aussi besoin deremplacer le port ajp13, en utilisant l'option --ajp13Port :

    $ java -jar jenkins.war --httpPort=8081 --ajp13Port=8010

    Quelques autres options utiles sont :

    --prefix

    Cet option vous permet de dfinir un chemin de contexte pour votre serveur Jenkins. Par dfautJenkins s'excutera sur le port 8080 sans chemin de contexte ( http://localhost:8080 ). Toutefois, sivous utilisez cette option, vous pouvez forcer Jenkins utiliser n'importe quel chemin de contextequi vous plat, par exemple:

    $ java -jar jenkins.war --prefix=jenkins

    Dans ce cas, Jenkins sera accessible depuis http://localhost:8080/jenkins .

    Cette option est souvent utilise lors de l'intgration d'une instance autonome de Jenkins avecApache.

    --daemon

    Si vous excutez Jenkins sur une machine Unix, vous pouvez utiliser cette option pour dmarrerJenkins comme une tche de fond, s'excutant comme un dmon unix.

    --logfile

    Par dfaut, Jenkins crit son fichier de journalisation dans le rpertoire courant. Cependant, surun serveur, vous avez souvent besoin d'crire vos fichier de journalisation dans un rpertoireprdtermin. Vous pouvez utiliser cette option pour rediriger vos messages vers un autre fichier :

    $ java -jar jenkins.war --logfile=/var/log/jenkins.log

    http://localhost:8080http://localhost:8080/jenkins

  • 55

    Stopping Jenkins using Ctrl-C is a little brutal, of coursein practice, you would set up a script to startand stop your server automatically.

    If you are running Jenkins using the embedded Winstone application server, you can also restart andshutdown Jenkins elegantly by calling the Winstone server directly. To do this, you need to specify thecontrolPort option when you start Jenkins, as shown here:

    $ java -jar jenkins.war --controlPort=8001

    A slightly more complete example in a Unix environment might look like this:

    $ nohup java -jar jenkins.war --controlPort=8001 > /var/log/jenkins.log 2>&1 &

    The key here is the controlPort option. This option gives you the means of stopping or restartingJenkins directly via the Winstone tools. The only problem is that you need a matching version of theWinstone JAR file. Fortunately, one comes bundled with your Jenkins installation, so you dont haveto look far.

    To restart the server, you can run the following command:

    $ java -cp $JENKINS_HOME/war/winstone.jar winstone.tools.WinstoneControl reload: \ --host=localhost --port=8001

    And to shut it down completely, you can use the following:

    $ java -cp $JENKINS_HOME/war/winstone.jar winstone.tools.WinstoneControl shutdown \ --host=localhost --port=8001

    Another way to shut down Jenkins cleanly is to invoke the special /exit URL, as shown here:

    $ wget http://localhost:8080/exit

  • 56

    On a real server, you would typically have set up security, so that only a system administrator couldaccess this URL. In this case, you will need to provide a username and a password:

    $ wget --user=admin --password=secret http://localhost:8080/exit

    Note that you can actually do this from a different server, not just the local machine:

    $ wget --user=admin --password=secret http://buildserver.acme.com:8080/exit

    Note that while both these methods will shut down Jenkins relatively cleanly (more so than killing theprocess directly, for example), they will interrupt any builds in progress. So it is recommended practiceto prepare the shutdown cleanly by using the Prepare for Shutdown button on the Manage Jenkins screen(see Section 4.2, Le tableau de bord de configuration L'cran Administrer Jenkins ).

    Running Jenkins as a stand-alone application may not be to everyones taste. For a production server,you might want to take advantage of the more sophisticated monitoring and administration features ofa full blown Java application server such as JBoss, GlassFish, or WebSphere Application Server. Andsystem administrators may be wary of the relatively little-known Winstone server, or may simply preferJenkins to fit into a known pattern of Java web application development. If this is the case, you mayprefer to, or be obliged to, deploy Jenkins as a standard Java web application. We look at this optionin the following section.

    3.9. Running Jenkins Behind an Apache ServerIf you are running Jenkins in a Unix environment, you may want to hide it behind an Apache HTTPserver in order to harmonize the server URLs and simplify maintenance and access. This way, userscan access the Jenkins server using a URL like http://myserver.myorg.com/jenkins rather than http://myserver.myorg.com:8081 .

    One way to do this is to use the Apache mod_proxy and mod_proxy_ajp modules. These modules letyou use implement proxying on your Apache server using the AJP13 (Apache JServer Protocol version1.3). Using this module, Apache will transfer requests to particular URL patterns on your Apache server(running on port 80) directly to the Jenkins server running on a different port. So when a user opensa URL like http://www.myorg.com/jenkins , Apache will transparently forward traffic to your Jenkinsserver running on http://buildserver.myorg.com:8081/jenkins .Technically, this is known as ReverseProxying, as the client has no knowledge that the server is doing any proxying, or where the proxiedserver is located. So you can safely tuck your Jenkins server away behind a firewall, while still providingbroader access to your Jenkins instance via the public-facing URL.

  • 57

    The exact configuration of this module will vary depending on the details of your Apache version andinstallation details, but one possible approach is shown here.

    First of all, if you are running Jenkins as a stand-alone application, make sure you start up Jenkins usingthe --prefix option. The prefix you choose must match the suffix in the public-facing URL you wantto use. So if you want to access Jenkins via the URL http://myserver.myorg.com/jenkins , you will needto provide jenkins as a prefix:

    $ java -jar jenkins.war --httpPort=8081 --ajp13Port=8010 --prefix=jenkins

    If you are running Jenkins on an application server such as Tomcat, it will already be running under aparticular web context ( /jenkins by default).

    Next, make sure the mod_proxy and mod_proxy_ajp modules are activated. In your httpd.conffile (often in the /etc/httpf/conf directory), you should have the following line:

    LoadModule proxy_module modules/mod_proxy.so

    The proxy is actually configured in the proxy_ajp.conf file (often in the /etc/httpd/conf.ddirectory). Note that the name of the proxy path ( /jenkins in this example) must match the prefix orweb context that Jenkins is using. An example of such a configuration file is given here:

    LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

    ProxyPass /jenkins http://localhost:8081/jenkins ProxyPassReverse /jenkins http://localhost:8081/jenkins ProxyRequests Off

    Once this is done, you just need to restart your Apache server:

    $ sudo /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ]

    Now you should be able to access your Jenkins server using a URL like http://myserver.myorg.com/jenkins .

    3.10. Running Jenkins on an Application ServerSince Jenkins is distributed as an ordinary WAR file, it is easy to deploy it on any standard Javaapplication server such as Tomcat, Jetty, or GlassFish. Running Jenkins on an application server is

  • 58

    arguably more complicated to setup and to maintain. You also loose certain nice administration featuressuch as the ability to upgrade Jenkins or restart the server directly from within Jenkins. On the otherhand, your system administrators might be more familiar with maintaining an application running onTomcat or GlassFish than on the more obscure Winstone server.

    Lets look at how you would typically deploy Jenkins onto a Tomcat server. The easiest approach isundoubtedly to simply unzip the Tomcat binary distribution onto your disk (if it is not already installed)and copy the jenkins.war file into the Tomcat webapps directory. You can download the Tomcatbinaries from the Tomcat website1 .

    You start Tomcat by running the startup.bat or startup.sh script in the Tomcat bin directory.Jenkins will be available when you start Tomcat. You should note that, in this case, Jenkins will beexecuted in its own web application context (typically jenkins ), so you will need to include this inthe URL you use to access your Jenkins server (e.g., http://localhost:8080/jenkins ).

    However, this approach is not necessarily the most flexible or robust option. If your build server is aWindows box, for example, you probably should install Tomcat as a Windows service, so that you canensure that it starts automatically whenever the server reboots. Similarly, if you are installing Tomcatin a Unix environment, it should be set up as a service.

    3.11. Memory ConsiderationsContinuous Integration servers use a lot of memory. This is the nature of the beastbuilds will consumememory, and multiple builds being run in parallel will consume still more memory. So you shouldensure that your build server has enough RAM to cope with however many builds you intend to runsimultaneously.

    Jenkins naturally needs RAM to run, but if you need to support a large number of build processes, it isnot enough just to give Jenkins a lot of memory. In fact Jenkins spans a new Java process each time itkicks off a build, so during a large build, the build process needs the memory, not Jenkins.

    You can define build-specific memory options for your Jenkins build jobswe will see how to do thislater on in the book. However if you have a lot of builds to maintain, you might want to define theJAVA_OPTS , MAVEN_OPTS and ANT_OPTS environment variables to be used as default values for yourbuilds. The JAVA_OPTS options will apply for the main Jenkins process, whereas the other two optionswill be used when Jenkins kicks off new JVM processes for Maven and Ant build jobs respectively.

    Here is an example of how these variables might be configured on a Unix machine in the .profile file:

    export JAVA_OPTS=-Djava.awt.headless=true -Xmx512m -DJENKINS_HOME=/data/jenkins export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=256m" export ANT_OPTS="-Xmx512m -XX:MaxPermSize=256m"

    1 http://tomcat.apache.org

    http://tomcat.apache.orghttp://localhost:8080/jenkinshttp://tomcat.apache.org

  • 59

    3.12. Installing Jenkins as a Windows Service

    If you are running a production installation of Jenkins on a Windows box, it is essential to have itrunning as a Windows service. This way, Jenkins will automatically start whenever the server reboots,and can be managed using the standard Windows administration tools.

    One of the advantages of running Jenkins on an application server such as Tomcat is that it is generallyfairly easy to configure these servers to run as a Windows service. However, it is also fairly easy toinstall Jenkins as a service, without having to install Tomcat.

    Jenkins has a very convenient feature designed to make it easy to install Jenkins as a Windows servers.There is currently no graphical installer that does this for you, but you get the next best thinga web-based graphical installer.

    First, you need to start the Jenkins server on your target machine. The simplest approach is to run Jenkinsusing Java Web Start (see Figure 3.4, Starting Jenkins using Java Web Start ). Alternatively, you cando this by downloading Jenkins and running it from the command line, as we discussed earlier:

    C:\jenkins> java -jar jenkins.war

    This second option is useful if the default Jenkins port (8080) is already being used by anotherapplication. It doesnt actually matter which port you useyou can change this later.

  • 60

    Figure 3.4. Starting Jenkins using Java Web Start

    Once you have Jenkins running, connect to this server and go to the Manage Jenkins screen. Here youwill find an Install as Windows Service button. This will create a Jenkins service on the server thatwill automatically start and stop Jenkins in an orderly manner (see Figure 3.5, Installing Jenkins as aWindows service ).

    Jenkins will prompt you for an installation directory. This will be the Jenkins home directory (JENKINS_HOME ). The default value is the default JENKINS_HOME value: a directory called .jenkinsin the current users home directory. This is often not a good choice for a Windows installation. Whenrunning Jenkins on Windows XP, you should avoid installing your Jenkins home directory anywherenear your C:\\Documents And Settings directorynot only is it a ridiculously long name, thespaces can wreak havoc with your Ant and Maven builds and any tests using classpath-based resources.It is much better to use a short and sensible name such as C:\Jenkins . The Vista and Windows 7home directory paths like C:\Users\john will also work fine.

  • 61

    Figure 3.5. Installing Jenkins as a Windows service

    A short home directory path is sometimes required for other reasons, too. On many versions of Windows(Windows XP, Windows Server 2003, etc.), file path lengths are limited to around 260 characters. Ifyou combine a nested Jenkins work directory and a deep class path, you can often overrun this, whichwill result in very obscure build errors. To minimize the risks of over-running the Windows file pathlimits, you need to redefine the JENKINS_HOME environment variable to point to a shorter path, as wediscussed above.

    This approach wont always work with Windows Vista or Windows 7. An alternative strategy isto use the jenkins.exe program that the Web Start installation process will have installed in thedirectory you specified above. Open the command line prompt as an administrator (right-click, Run asadministrator) and run the jenkins.exe executable with the install option:

    C:\Jenkins> jenkins.exe install

    This basic installation will work fine in a simple context, but you will often need to fine-tune yourservice. For example, by default, the Jenkins service will be running under the local System account.However, if you are using Maven, Jenkins will need an .m2 directory and a settings.xml file in thehome directory. Similarly, if you are using Groovy, you might need a .groovy/lib directory. And soon. To allow this, and to make testing your Jenkins install easier, make sure you run this service undera real user account with the correct development environment set up (see Figure 3.6, Configuring theJenkins Windows Service ). Alternatively, run the application as the system user, but use the SystemInformation page in Jenkins to check the /jenkins-guide-complet directory, and place any filesthat must be placed in the user home directory here.

  • 62

    Figure 3.6. Configuring the Jenkins Windows Service

    You configure the finer details of the Jenkins service in a file called jenkins.xml , in the same directoryas your jenkins.war file. Here you can configure (or reconfigure) ports, JVM options, an the Jenkinswork directory. In the following example, we give Jenkins a bit more memory and get it to run on port8081:

    jenkins Jenkins This service runs the Jenkins continuous integration system java -Xrs -Xmx512m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8081 --ajp13Port=8010

    Finally, if you need to uninstall the Jenkins service, you can do one of two things. The simplest is torun the Jenkins executable with the uninstall option:

    C:\jenkins> jenkins.exe uninstall

    The other option is to use the Windows service tool sc :

    C:>

  • 63

    sc delete jenkins

    3.13. Whats in the Jenkins Home Directory

    The Jenkins home directory contains all the details of your Jenkins server configuration, details thatyou configure in the Manage Jenkins screen. These configuration details are stored in the form of a setof XML files. Much of the core configuration, for example, is stored in the config.xml file. Othertools-specific configuration is stored in other appropriately-named XML files: the details of your Maveninstallations, for example, are stored in a file called hudson.tasks.Maven.xml . You rarely need tomodify these files by hand, though occasionally it can come in handy.

    The Jenkins home directory also contains a number of subdirectories (see Figure 3.7, The Jenkinshome directory ). Not all of the files and directories will be present after a fresh installation, as someare created when required by Jenkins. And if you look at an existing Jenkins installation, you will seeadditional XML files relating to Jenkins configuration and plugins.

    The main directories are described in more detail in Table 3.1, The Jenkins home directory structure .

    Table 3.1. The Jenkins home directory structure

    Directory Description

    .jenkins The default Jenkins home directory (may be .hudson in olderinstallations).

    fingerprints This directory is used by Jenkins to keep track of artifactfingerprints. We look at how to track artifacts later on in the book.

    jobs This directory contains configuration details about the build jobsthat Jenkins manages, as well as the artifacts and data resulting fromthese builds. We look at this directory in detail below.

    plugins This directory contains any plugins that you have installed. Pluginsallow you to extend Jenkins by adding extra feature. Note that,with the exception of the Jenkins core plugins (subversion, cvs,ssh-slaves, maven, and scid-ad), plugins are not stored with thejenkins executable, or in the expanded web application directory.This means that you can update your Jenkins executable and nothave to reinstall all your plugins.

    updates This is an internal directory used by Jenkins to store informationabout available plugin updates.

    userContent You can use this directory to place your own custom contentonto your Jenkins server. You can access files in this directory athttp://myserver/hudson/userContent (if you are running Jenkins on

  • 64

    Directory Descriptionan application server) or http://myserver/userContent (if you arerunning in stand-alone mode).

    users If you are using the native Jenkins user database, user accounts willbe stored in this directory.

    war This directory contains the expanded web application. When youstart Jenkins as a stand-alone application, it will extract the webapplication into this directory.

    Figure 3.7. The Jenkins home directory

    The jobs directory is a crucial part of the Jenkins directory structure, and deserves a bit more attention.You can see an example of a real Jenkins jobs directory in Figure 3.8, The Jenkins jobs directory .

  • 65

    Figure 3.8. The Jenkins jobs directory

    This directory contains a subdirectory for each Jenkins build job being managed by this instance ofJenkins. Each job directory in turn contains two subdirectories: builds and workspace , alongwith some other files. In particular, it contains the build job config.xml file, which contains, asyou might expect, the configuration details for this build job. There are also some other files usedinternally by Jenkins, that you usually wouldnt touch, such as the nextBuildNumber file (whichcontains the number that will be assigned to the next build in this build job), as well as symbolic linksto the most recent successful build and the last stable one. A successful build is one that does not haveany compilation errors. A stable build is a successful build that has passed whatever quality criteria youmay have configured, such as unit tests, code coverage and so forth.

    Both the build and the workspace directories are important. The workspace directory is whereJenkins builds your project: it contains the source code Jenkins checks out, plus any files generated bythe build itself. This workspace is reused for each successive buildthere is only ever one workspacedirectory per project, and the disk space it requires tends to be relatively stable.

    The builds directory contains a history of the builds executed for this job. You rarely need to intervenedirectly in these directories, but it can be useful to know what they contain. You can see a real exampleof the builds directory in Figure 3.9, The builds directory , where three builds have been performed.Jenkins stores build history and artifacts for each build it performs in a directory labeled with atimestamp (2010-03-12_20-42-05 and so forth in Figure 3.9, The builds directory ). It also containssymbolic links with the actual build numbers that point to the build history directories.

  • 66

    Figure 3.9. The builds directory

    Each build directory contains information such as the build result log file, the Subversion revisionnumber used for this build (if you are using Subversion), the changes that triggered this build, and anyother data or metrics that you have asked Jenkins to keep track of. For example, if your build job keepstrack of unit test results or test coverage metrics, this data will be stored here for each build. The builddirectory also contains any artifacts you are storingbinary artifacts, but also other generated files suchas javadoc or code coverage metrics. Some types of build jobs, such as the Jenkins Maven build jobs,will also archive binary artifacts by default.

    The size of the build directory will naturally grow over time, as the build history cumulates. You willprobably want to take this into account when designing your build server directory structure, especiallyif your build server is running in a Unix-style environment with multiple disk partitions. A lot of thisdata takes the form of text or XML files, which does not consume a large amount of extra space for eachbuild. However, if your build archives some of your build artifacts, such as JAR or WAR files, theytoo will be stored here. The size of these artifacts should be factored into your disk space requirements.We will see later on how to limit the number of builds stored for a particular build job if space is anissue. Limiting the number of build jobs that Jenkins stores is always a trade-off between disk spaceand keeping useful build statistics, as Jenkins does rely on this build history for its powerful reportingfeatures.

  • 67

    Jenkins uses the files in this directory extensively to display build history and metrics data, so you shouldbe particularly careful not to delete any of the build history directories without knowing exactly whatyou are doing.

    3.14. Backing Up Your Jenkins Data

    It is important to ensure that your Jenkins data is regularly backed up. This applies in particular to theJenkins home directory, which contains your server configuration details as well as your build artifactsand build histories. This directory should be backed up frequently and automatically. The Jenkinsexecutable itself is less critical, as it can easily be reinstalled without affecting your build environment.

    3.15. Upgrading Your Jenkins Installation

    Upgrading Jenkins is easyyou simply replace your local copy of the jenkins.war file and restartJenkins. However you should make sure there are no builds running when you restart your server. Sinceyour build environment configuration details, plugins, and build history are stored in the Jenkins homedirectory, upgrading your Jenkins executable will have no impact on your installation. You can alwayscheck what version of Jenkins you are currently running by referring to the version number in the bottomright corner of every screen.

    If you have installed Jenkins using one of the Linux packages, Jenkins can be upgraded using the sameprocess as the other system packages on the server.

    If you are running Jenkins as a stand-alone instance, you can also upgrade your Jenkins installationdirectly from the web interface, in the Manage Jenkins section. Jenkins will indicate if a more recentversion is available, and give you the option to either download it manually or upgrade automatically(see Figure 3.10, Upgrading Jenkins from the web interface ).

  • 68

    Figure 3.10. Upgrading Jenkins from the web interface

    Once Jenkins has downloaded the upgrade, you can also tell it to restart when no jobs are running. Thisis probably the most convenient way to upgrade Jenkins, although it will not work in all environments.In particular, you need to be running Jenkins as a stand-alone application, and the user running Jenkinsneeds to have read-write access to the jenkins.war file.

    If you are running Jenkins on an application server such as Tomcat or JBoss, you might need to doa bit more tidying up when you upgrade your Jenkins instance. Tomcat, for example, places compiledJSP pages in the CATALINA_BASE/work directory. When you upgrade your Jenkins version, these filesneed to be removed to prevent the possibility of any stale pages being served.

    Any plugins you have installed will be unaffected by your Jenkins upgrades. However, plugins can alsobe upgraded, independently of the main Jenkins executable. You upgrade your plugins directly in theJenkins web application, using the Jenkins Plugin Manager. We discuss plugins in more detail further on in this book.

    3.16. ConclusionIn this chapter, we have seen how to install and run Jenkins in different environments, and learned a fewbasic tips on how to maintain your Jenkins installation once running. Jenkins is easy to install, both as astand-alone application and as a WAR file deployed to an existing application server. The main thingsyou need to consider when choosing a build server to host Jenkins are CPU, memory, and disk space.

  • Chapter 4. Configurer votre serveurJenkins4.1. Introduction

    Avant de commencer crer vos tches de build dans Jenkins, vous devez faire un peu de configurationpour vous assurer que votre serveur Jenkins fonctionnera sans problme dans votre environnementspcifique. Jenkins est hautement configurable, et bien que la plupart des options soient fournies avecdes valeurs raisonnables par dfaut, ou que l'outil soit capable de trouver les bons outils de build dansle PATH ou dans les variables d'environnement, c'est toujours une bonne ide de savoir exactement ceque votre serveur de build fait.

    Jenkins est globalement trs simple configurer. Les crans d'administration sont intuitifs, et l'aidecontextuelle (les icnes en forme de point d'interrogation bleu ct de chaque champ) est dtaille etprcise. Dans ce chapitre, nous allons voir comment configurer votre serveur basique en dtail. Nousverrons notamment comment configurer Jenkins pour qu'il utilise diffrentes versions de Java, d'outilsde build comme Ant ou Maven, et d'outils de gestion de version comme CVS et Subversion. Plus loindans le livre, nous regarderons aussi des configurations de serveur plus avances, comme l'utilisationd'autres systmes de gestion de version ou d'outils de notifications.

    4.2. Le tableau de bord de configuration L'cranAdministrer Jenkins

    Dans Jenkins, vous grez pratiquement tous les aspects de la configuration du systme dans l'cranAdministrer Jenkins (voir Figure 4.1, Configurer son installation Jenkins dans l'cran AdministrerJenkins). Vous pouvez aussi atteindre cet cran directement depuis n'importe o dans l'application entapant manage dans la bote de recherche Jenkins. Cet cran change en fonction des plugins que vousinstallez, ne soyez donc pas surpris si vous voyez plus de choses que ce que nous montrons ici.

  • 70

    Figure 4.1. Configurer son installation Jenkins dans l'cran Administrer Jenkins

    Cet cran vous permet de configurer diffrents aspects de votre serveur Jenkins. Chaque lien sur cettepage vous amne un cran de configuration ddi, o vous pouvez grer diffrentes parties du serveurJenkins. Quelques-unes des options les plus intressantes sont discutes ici :

    Configurer le systmeC'est l que vous grez les chemins vers les diffrents outils que vous utilisez dans vos builds,comme les JDKs, les versions de Ant et Maven, les options de scurit, les serveurs d'email,et autres dtails de configuration de niveau systme. Plusieurs des plugins que vous installerezncessiteront aussi d'tre configurs ici Jenkins ajoutera les champs dynamiquement l'installation des plugins.

    Recharger la configuration partir du disqueComme nous l'avons vu dans le prcdent chapitre, Jenkins stocke tous les dtails deconfiguration du systme et des tches de build dans des fichiers XML localiss dans le rpertoirede travail de Jenkins (voir Section 3.4, Le rpertoire de travail de Jenkins). Il stocke aussitout l'historique des builds dans le mme rpertoire. Si vous migrez des tches de build d'uneinstance Jenkins une autre, ou archivez de vieilles tches de build, vous aurez besoin d'ajouterou d'enlever les diffrents rpertoires de tches de build du rpertoire builds de Jenkins.Vous n'avez pas besoin de dsactiver Jenkins pour faire cela vous pouvez simplementutiliser l'option Recharger la configuration partir du disque pour recharger directement la

  • 71

    configuration systme de Jenkins et des tches de build. Ce processus peut tre un peu lent s'ily a beaucoup d'historique de build, pendant que Jenkins charge non seulement la configurationdes builds mais aussi les donnes de l'historique.

    Gestion des pluginsL'une des meilleures fonctionnalits de Jenkins est son architecture extensible. Il y a unlarge cosystme de plugins open source tierces disponibles, vous permettant d'ajouter desfonctionnalits votre serveur de build, du support des diffrents outils de gestion de sourcescomme Git, Mercurial ou ClearCase, aux mtriques de qualit du code et de couverture de code.Nous regarderons plusieurs des plugins les plus populaires et utiles travers ce livre. Les pluginspeuvent tre installs, mis jour et enlevs via l'cran Grer les Plugins. Notez qu'enlever desplugins ncessite un certain soin, parce que cela peut parfois affecter la stabilit de votre instanceJenkins nous verrons cela plus en dtails dans Section 13.6, Migrer les tches de build.

    Information SystmeCet cran affiche une liste de toutes les proprits systme Java et les variables d'environnementsystme. Ici, vous pouvez vrifier dans quelle version exacte de Java Jenkins est en train defonctionner, avec quel utilisateur, etc. Vous pouvez aussi vrifier que Jenkins utilise le bonparamtrage des variables d'environnement. Cet cran sert principalement pour le dpannage.Il vous permet de vous assurer que votre serveur fonctionne avec les proprits systme et lesvariables d'environnement que vous pensez.

    Log systmeL'cran Log systme est un moyen pratique de voir les fichiers de log Jenkins en temps rel.Encore une fois, ceci sert principalement au dpannage.

    Vous pouvez aussi souscrire aux flux RSS pour diffrents niveaux de messages de logs. Parexemple, en tant qu'administrateur Jenkins, il peut tre une bonne ide de souscrire tous lesmessages de log de niveau ERROR et WARNING.

    Statistiques d'utilisationJenkins garde la trace du niveau d'activit de votre serveur en fonction du nombre de buildsconcurrents et de la longueur de la file d'attente de build (ce qui vous donne une ide de ladure pendant laquelle vos builds doivent attendre avant d'tre excuts). Ces statistiques peuventvous aider savoir si vous avez besoin d'ajouter de la capacit additionnelle ou des nudssupplmentaires votre infrastructure.

    Console de scriptCet cran vous permet d'excuter des scripts Groovy sur le serveur. C'est utile pour le dpannageavanc : cela requiert en effet une connaissance profonde de l'architecture interne de Jenkins. Cetcran est donc principalement utile pour les dveloppeurs de plugins et consorts.

    Grer les nudsJenkins gre aussi bien les builds parallles que distribus. Dans cet cran, vous pouvezconfigurer le nombre de builds que vous voulez. Jenkins les excute simultanment, et, si vous

  • 72

    utilisez des builds distribus, configure les nuds de build. Un nud de build est une autremachine que Jenkins peut utiliser pour excuter ses builds. Nous regarderons comment configurerles builds distribus en dtail dans Chapter 11, Builds distribus.

    Prparer la fermetureSi vous avez besoin d'teindre Jenkins, ou le serveur sur lequel il fonctionne, c'est mieux de nepas le faire lorsqu'un build est en cours. Pour fermer Jenkins proprement, vous pouvez utiliserle lien Prparer la fermeture, qui empche le dmarrage de tout nouveau build. Finalement,lorsque tous les builds en cours seront termins, vous pourrez teindre Jenkins proprement.

    Nous reviendrons sur certaines de ces fonctionnalits en dtails plus loin dans le livre. Dans les sectionssuivantes, nous nous concentrerons sur comment configurer les paramtres systmes les plus importantsde Jenkins .

    4.3. Configurer l'environnement systmeLa page d'administration la plus importante de Jenkins est l'cran Configurer le systme (Figure 4.2,Configuration du systme dans Jenkins). Ici, vous paramtrez la plupart des outils fondamentaux dontJenkins a besoin pour son travail quotidien. L'cran par dfaut contient un certain nombre de sections,chacune concernant un domaine diffrent ou un outil externe. De plus, quand vous installez des plugins,leur configuration systme globale est aussi souvent effectue dans cet cran.

    Figure 4.2. Configuration du systme dans Jenkins

  • 73

    L'cran Configurer le systme vous permet de dfinir les paramtres globaux pour votre installationJenkins, et aussi pour vos outils externes ncessaires au processus de build. La premire partie de cetcran permet de dfinir certains paramtres de niveau systme.

    Le rpertoire de travail de Jenkins est indiqu, pour rfrence. De cette faon, vous pouvez vrifier d'uncoup d'il que vous travaillez avec le rpertoire de travail auquel vous vous attendez. Rappelez-vous,vous pouvez changer ce rpertoire en positionnant la variable d'environnement JENKINS_HOME dansvotre environnement (voir Section 3.4, Le rpertoire de travail de Jenkins).

    Le champ Message du systme sert plusieurs choses. Ce texte est affich en haut de votre paged'accueil Jenkins. Vous pouvez utiliser des balises HTML, c'est donc un moyen simple de personnaliservotre serveur de build en incluant le nom de votre serveur et un petit laus sur son rle. Vous pouvezaussi l'utiliser pour afficher des messages pour tous les utilisateurs, pour annoncer par exemple desindisponibilits du systme, etc.

    La Priode d'attente est utile pour les outils de gestion de sources comme CVS qui committent les fichiersun par un, au lieu de les grouper ensemble en une seule transaction atomique. Normalement, Jenkinsdclenchera un build ds qu'il dtectera un changement dans le dpt de sources. Toutefois, cela neconvient pas tous les environnements. Si vous utilisez un outil comme CVS, vous ne devriez pas lancerun build ds que le premier changement arrive, parce que le dpt sera dans un tat inconsistant tant quetous les changements n'auront pas t committs. Vous pouvez utiliser le champ Priode d'attente pourviter des problmes de ce genre. Si vous mettez une valeur cet endroit, Jenkins attendra qu'aucunchangement n'ait t dtect pendant le nombre spcifi de secondes avant de dclencher le build. Cecipermet de s'assurer que tous les changements ont t committs et que le dpt est dans un tat stableavant de dmarrer le build.

    Pour les systmes de gestion de version modernes, comme Subversion, Git ou Mercurial, les commitssont atomiques. Cela signifie que des changements dans plusieurs fichiers sont soumis au dpt commeunit simple, et le code source sur le dpt est garanti d'tre tout moment dans un tat stable. Toutefois,certaines quipes utilisent encore une approche o un changement logique est livr en plusieurs commits.Dans ce cas, vous pouvez utiliser la Priode d'attente pour vous assurer que le build utilise toujours uneversion stable de code source.

    La valeur de Priode d'attente spcifie est la valeur par dfaut au niveau systme si ncessaire, vouspouvez redfinir cette valeur individuellement pour chaque projet.

    Vous pouvez aussi grer les comptes utilisateurs et les droits ici. Par dfaut, Jenkins laisse n'importe quelutilisateur faire ce qu'il souhaite. Si vous souhaitez une approche plus restrictive, vous devrez activer lascurit de Jenkins en slectionnant le champ Activer la scurit. Il y a plusieurs faons de grer cela,nous regarderons cet aspect de Jenkins plus tard (voir Chapter 7, Scuriser Jenkins).

    4.4. Configurer les proprits globalesLa section Proprits globales (voir Figure 4.3, Configurer les variables d'environnement dansJenkins) vous permet de dfinir des variables de faon centralise et de les utiliser dans toutes vos

  • 74

    tches de build. Vous pouvez ajouter autant de proprits que vous voulez, et les utiliser dans vos tches.Jenkins les rendra disponible l'intrieur de l'environnement de vos tches de build, vous permettantde les utiliser facilement dans vos scripts Ant ou Maven. A noter que vous ne devez pas mettre depoints (.) dans les noms de proprits, parce qu'ils ne seront pas traits correctement. Utilisez doncldapserver ou ldap_server, mais pas ldap.server.

    Figure 4.3. Configurer les variables d'environnement dans Jenkins

    Il y a deux faons principales d'utiliser ces variables. Premirement, vous pouvez les utiliser directementdans votre script de build, en utilisant la notation ${key} ou $key (donc ${ldapserver} ou$ldapserver dans l'exemple donn ci-dessus). C'est l'approche la plus simple, mais cela signifie qu'ily a un couplage fort entre la configuration de votre tche et vos scripts de build.

    Si votre script utilise un nom de proprit diffrent (un contenant des points, par exemple), vouspouvez aussi passer la valeur votre script de build dans la configuration de votre tche de build. DansFigure 4.4, Utiliser une variable d'environnement configure nous passons la valeur de la propritldapserver dfinie dans Figure 4.3, Configurer les variables d'environnement dans Jenkins unetche de build Maven. Utiliser l'option -D signifie que cette valeur sera accessible l'intrieur du script.C'est une approche flexible, parce qu'on peut assigner les proprits globales dfinies dans Jenkins des variables spcifiques nos scripts de build. Dans Figure 4.4, Utiliser une variable d'environnementconfigure, par exemple, la proprit ldapserver sera disponible l'intrieur du build Maven via laproprit ${ldap.server}.

    Figure 4.4. Utiliser une variable d'environnement configure

    4.5. Configurer vos JDKsHistoriquement, l'une des utilisations les plus communes de Jenkins tait de construire des applicationsJava. Jenkins fournit donc naturellement un support intgr pour Java.

    Par dfaut, Jenkins construira les applications Java en utilisant la version de Java qu'il trouve dans lePATH, qui est habituellement celle avec laquelle Jenkins fonctionne. Toutefois, pour un serveur de

  • 75

    build de production, vous voudrez probablement plus de contrle que cela. Par exemple, vous pourriezexcuter votre serveur Jenkins avec Java 6, pour des raisons de performance. Par contre, votre serveurde production pourrait tourner avec Java 5 ou mme Java 1.4. Les grosses organisations sont souventtrs prcautionneuses lorsqu'il s'agit de mettre jour les versions de Java dans leurs environnementsde production, et certains des serveurs d'application poids-lourds du march sont de notorit publiquelents tre certifis avec les derniers JDKs.

    Dans tous les cas, c'est toujours une sage pratique que de construire votre application en utilisant uneversion de Java proche de celle utilise sur votre serveur de production. Bien qu'une application compileavec Java 1.4 tournera gnralement avec Java 6, l'inverse n'est pas toujours vrai. Vous pourriez aussiavoir plusieurs applications qui ncessitent d'tre construites avec diffrentes versions de Java.

    Jenkins fournit un bon support pour travailler avec de multiples JVMs. En effet, Jenkins rend trs facilela configuration et l'utilisation de plusieurs versions de Java. Comme la plupart des configurations deniveau systme, cela se paramtre dans l'cran Configurer le systme (voir Figure 4.2, Configurationdu systme dans Jenkins). A cet endroit, vous trouverez une section appele JDK qui vous permettrade grer les installations de JDK avec lesquelles vous voulez que Jenkins travaille.

    Le moyen le plus simple de dclarer une installation de JDK est de fournir un nom appropri (qui seraensuite utilis pour identifier cette installation de Java lors de la configuration de vos builds), et unchemin vers le rpertoire de l'installation Java (le mme chemin que vous utiliseriez pour la variableJAVA_HOME), comme montr sur Figure 4.5, Configuration des JDKs dans Jenkins. Bien que vousdeviez entrer le chemin manuellement, Jenkins vrifiera en temps rel la fois que le rpertoire existeet que a ressemble un rpertoire JDK valide.

    Figure 4.5. Configuration des JDKs dans Jenkins

    Vous pouvez aussi demander Jenkins d'installer Java pour vous. Dans ce cas, Jenkins tlchargeral'installeur du JDK et installera une copie sur votre machine (voir Figure 4.6, Installer un JDK

  • 76

    automatiquement). La premire fois qu'une construction a besoin d'utiliser ce JDK, Jenkins tlchargeraet installera la version spcifie de Java dans le rpertoire tools du rpertoire racine de Jenkins. Si lebuild est excut sur un nouvel agent de build qui n'a pas ce JDK install, il le tlchargera et l'installerasur celui-ci de la mme faon.

    C'est aussi un formidable moyen de configurer les agents de construction. Comme nous le verrons plusloin dans le livre, Jenkins peut dlguer des tches de build d'autres machines, ou d'autres agents deconstruction. Un agent de construction (ou esclave) est simplement un autre ordinateur que Jenkinspeut utiliser pour excuter certains de ses builds. Si vous utilisez l'option d'installation automatique deJenkins, vous n'avez pas installer toutes les versions du JDK dont vous avez besoin sur les machinesagent de construction Jenkins le fera pour vous la premire fois que cela lui sera ncessaire.

    Par dfaut, Jenkins propose de tlcharger le JDK partir du site web d'Oracle. Si votre installationJenkins est derrire un serveur proxy, vous pourrez avoir besoin de modifier votre configuration de proxypour permettre Jenkins d'accder aux sites externes de tlchargement (voir Section 4.9, Configurerun Proxy). Une autre option est de fournir une URL pointant sur votre propre copie interne des binairesdu JDK (soit sous la forme d'un ZIP soit sous la forme d'un fichier TAR compress avec GZip), stocksur un serveur local l'intrieur de votre organisation. Cela vous permet de fournir des installationsnormalises sur un serveur local et d'acclrer les installations automatiques. Quand vous utilisez cetteoption, Jenkins vous permet aussi de spcifier un label, ce qui resteindra l'utilisation de cette installationaux noeuds ayant ce label. C'est une technique utile si vous avez besoin d'installer une version spcifiqued'un outil sur certaines machines de build. La mme approche peut aussi tre utilise pour les autresoutils de build (comme Maven et Ant).

    Figure 4.6. Installer un JDK automatiquement

    L'installeur automatique ne fonctionnera pas dans tous les environnements (s'il ne parvient pas trouverou identifier un systme d'exploitation satisfaisant, par exemple, l'installation chouera), mais c'estnanmoins un moyen utile et agrable de configurer de nouveaux serveurs de build ou des agents deconstruction distribus de manire consistante.

  • 77

    4.6. Configurer vos outils de buildLes outils de build sont l'essence mme de tout serveur de build, et Jenkins n'est pas une exception.En standard, Jenkins supporte trois outils de build principaux : Ant, Maven, et le basique shell-script(ou script Batch sous Windows). En utilisant les plugins Jenkins, vous pouvez aussi ajouter le supportd'autres outils de build et d'autres langages, comme Gant, Grails, MSBuild, et beaucoup d'autres.

    4.6.1. Maven

    Maven est un framework de scripting de haut-niveau pour Java qui utilise des notions telles qu'unestructure normalise d'arborescence et des cycles de vie normaliss, "Convention over Configuration",et une gestion dclarative des dpendances pour simplifier le scripting de bas-niveau que l'on trouvesouvent dans un script de build Ant typique. Avec Maven, votre projet utilise un cycle de vie normaliset bien dfini compile, test, package, deploy, etc. Chaque phase de cycle est associe avec un pluginMaven. Les diffrents plugins Maven utilisent la structure d'arborescence normalise pour traiter cestches avec un minimum d'intervention de votre part. Vous pouvez aussi tendre Maven en redfinissantles configurations de plugin par dfaut ou en invoquant des plugins supplmentaires.

    Jenkins fournit un excellent support pour Maven, et comprend parfaitement les structures de projet et lesdpendances Maven. Vous pouvez soit demander Jenkins d'installer automatiquement une version deMaven (comme nous le faisons avec Maven 3 dans l'exemple), ou fournir un chemin vers une installationlocale de Maven (voir Figure 4.7, Configurer Maven dans Jenkins). Vous pouvez configurer autantde versions de Maven pour vos projets de build que vous le voulez, et utiliser diffrentes versions deMaven pour diffrents projets.

    Figure 4.7. Configurer Maven dans Jenkins

  • 78

    Si vous cochez la case cocher Installer automatiquement, Jenkins tlchargera et installera la versionsdemande de Maven pour vous. Vous pouvez soit demander Jenkins de tlcharger Maven directementdepuis le site Apache, soit depuis une URL (a priori locale) de votre choix. C'est un excellent choixsi vous utilisez des builds distribus, et puisque Maven est multi-plateformes, cela fonctionnera surn'importe quelle machine. Vous n'avez pas besoin d'installer explicitement Maven sur chaque machinede build la premire fois qu'une machine de build aura besoin d'utiliser Maven, elle en tlchargeraune copie et l'installera dans le rpertoire tools du rpertoire racine de Jenkins.

    Il est parfois ncessaire de passer des options systme votre processus de construction Maven. Parexemple, il est souvent utile de donner Maven un peu plus de mmoire pour des tches lourdes commela couverture de code ou la gnration de site. Maven vous permet de faire cela en positionnant lavariable MAVEN_OPTS. Dans Jenkins, vous pouvez dfinir une valeur par dfaut pour tout le systme,afin de l'utiliser dans tous les projets (voir Figure 4.8, Configurer la variable systme MVN_OPTS).C'est pratique si vous voulez utiliser des options standards de mmoire (par exemple) pour tous vosprojets, sans avoir le configurer dans chaque projet la main.

    Figure 4.8. Configurer la variable systme MVN_OPTS

    4.6.2. Ant

    Ant est un langage de script de build pour Java largement utilis et trs connu. C'est un langagede scripting flexible, extensible, relativement bas-niveau utilis dans un grand nombre de projetsopensource. Un script de build Ant (typiquement nomm build.xml) est constitu d'un certain nombrede targets. Chaque target effectue une tche particulire dans le processus de build, comme compilervotre code ou excuter vos tests unitaires. Il fonctionne en excutant des tasks, qui portent une partiespcifique de la tche de build, comme invoquer javac pour compiler votre code, ou crer un nouveaurpertoire. Les targets ont aussi des dependencies, indiquant l'ordre dans lequel vos tches de builddoivent tre excutes. Par exemple, vous devez compiler votre code avant de lancer vos tests unitaires.

    Jenkins fournit en standard un support excellent pour Ant vous pouvez invoquer les tches Ant depuisvotre tche de build, en fournissant les proprits permettant de personnaliser le processus comme celaest ncessaire. Nous regardons comment faire cela en dtail plus loin dans le livre.

    Si Ant est disponible dans le path systme, Jenkins le trouvera. Toutefois, si vous voulez savoirprcisment quelle version de Ant vous tes en train d'utiliser, ou si vous avez besoin de pouvoir utiliserdiffrentes versions de Ant sur diffrentes tches de build, vous pouvez configurer autant d'installationsde Ant que vous le souhaitez (voir Figure 4.9, Configurer Ant dans Jenkins). Fournissez simplement un

  • 79

    nom et un rpertoire d'installation pour chaque version de Ant dans la section Ant de l'cran Configurerle systme. Vous pourrez ensuite choisir quelle version de Ant vous voulez utiliser pour chaque projet.

    Si vous cochez la case cocher Installer automatiquent, Jenkins tlchargera et installera Ant dansle rpertoire tools du rpertoire racine de Jenkins, exactement comme il le fait pour Maven. Iltlchargera une installation de Ant la premire fois qu'une tche de build aura besoin d'utiliser Ant, soitdepuis le site web Apache, soit depuis une URL locale. Encore une fois, ceci est un moyen formidablede normaliser vos serveurs de build et de faciliter l'ajout de nouveaux serveurs de builds distribus une infrastructure existante.

    Figure 4.9. Configurer Ant dans Jenkins

    4.6.3. Langage de scripts Shell

    Si vous excutez votre serveur de build sous Unix ou Linux, Jenkins vous permettra d'insrer des scriptsshells dans vos tches de build. C'est pratique pour effectuer des tches bas-niveau, lies l'OS que vousne voulez pas faire avec Ant ou Maven. Dans la section Shell, vous dfinissez le Shell par dfaut quisera utilis pour excuter ces scripts Shell. Par dfaut, c'est /bin/sh, mais parfois vous pouvez vouloirmodifier cela pour utiliser un autre interprteur de commande comme bash ou Perl.

    Sous Windows, la section Shell ne s'applique pas vous utilisez le scripting batch Windows la place.Donc, sur un serveur de build Windows, vous devriez laisser ce champ vierge.

    4.7. Configurer vos outils de gestion de version

    Jenkins arrive de base pr-install avec des plugins pour CVS et Subversion. Les autres systmes degestion de version sont supports par des plugins que vous pouvez tlcharger depuis l'cran Grer lesplugins.

  • 80

    4.7.1. Configurer Subversion

    Subversion ne ncessite pas de configuration spciale, puisque Jenkins utilise des bibliothques Javanatives pour interagir avec des dpts Subversion. Si vous avez besoin de vous authentifier pourvous connecter un dpt, Jenkins vous le demandera quand vous entrerez l'URL Subversion dans laconfiguration de la tche de build.

    4.7.2. Configurer CVS

    CVS ncessite peu voire aucune configuration. Par dfaut, Jenkins cherchera des outils comme CVSdans le chemin systme, bien que vous puissiez fournir le chemin explicitement s'il ne s'y trouve pas.CVS garde le login et le mot de passe dans un fichier appel .cvspass, qui se trouve habituellementdans votre rpertoire utilisateur. Si ce n'est pas le cas, vous pouvez fournir un chemin o Jenkins pourratrouver ce fichier.

    4.8. Configurer le serveur de messagerie lectroniqueLa dernire des options de configuration basique que vous devez mettre en place est la configurationdu serveur de messagerie lectronique. L'email est la technique de notification la plus fondamentale deJenkins quand un build choue, il envoie un email au dveloppeur qui a committ les changements,et optionnellement aux autres membres de l'quipe. Jenkins a donc besoin de connatre votre serveur demessagerie lectronique (voir Figure 4.10, Configurer un serveur d'email dans Jenkins).

    Figure 4.10. Configurer un serveur d'email dans Jenkins

    L'email de l'administrateur systme est l'adresse depuis laquelle les messages de notification sontenvoys. Vous pouvez aussi utiliser ce champ pour tester la configuration email si vous cliquez surle bouton Tester la configuration, Jenkins enverra un email de test cette adresse.

    Dans de nombreuses organisations, vous pouvez driver l'adresse email de l'utilisateur partir de sonlogin en ajoutant le nom de domaine de l'organisation. Par exemple, chez ACME, l'utilisateur MarcelTartampion aura un login "mtartampion" et une adresse email "mtartampion@acme.com. Si celas'tend votre systme de gestion de version, Jenkins peut vous conomiser un bon nombre d'efforts de

  • 81

    configuration dans ce domaine. Dans l'exemple prcdent, vous pourriez simplement spcifier le suffixeemail utilisateur par dfaut et Jenkins devinera le reste.

    Vous devrez aussi fournir une URL de base correcte pour votre serveur Jenkins (une qui n'utilise paslocalhost). Jenkins utilise cette URL dans les notifications email pour que les utilisateurs puissent allerdirectement de l'email l'cran d'chec du build sur Jenkins.

    Jenkins fournit aussi une configuration email plus sophistique, en utilisant des fonctionnalits plusavances comme l'authentification SMTP et SSL. Si vous tes dans ce cas, cliquez sur le bouton Avancpour configurer ces options.

    Par exemple, plusieurs organisations utilisent Google Apps pour leurs services de messagerie. Vouspouvez configurer Jenkins pour travailler avec le service Gmail comme montr dans Figure 4.11,Configurer un serveur d'email pour utiliser un domaine Google Apps. Tout ce que vous avez besoin defaire dans ce cas est d'utiliser le serveur SMTP Gmail, et de fournir votre nom d'utilisateur Gmail et votremot de passe dans Authentication SMTP (vous devez aussi utiliser SSL et le port non-standard 465).

    Figure 4.11. Configurer un serveur d'email pour utiliser un domaine Google Apps

    4.9. Configurer un ProxyDans la plupart des environnements d'entreprise, votre serveur Jenkins sera situ derrire un pare-feu,et n'aura pas un accs direct Internet. Jenkins a besoin d'un accs Internet pour tlcharger les pluginset les mises jour, et aussi pour installer les outils tels que le JDK, Ant et Maven depuis des sitesdistants. Si vous avez besoin de passer par un serveur proxy HTTP pour accder Internet, vous pouvezconfigurer les dtails de connexion (le serveur et le port, et si ncessaire le nom utilisateur et le mot depasse) dans l'onglet Avanc de l'cran Gestionnaire de plugins (voir Figure 4.12, Configurer Jenkinspour utiliser un proxy).

  • 82

    Si votre proxy utilise le systme d'authentification Microsoft NTLM, vous devrez alors fournir un nomde domaine en plus d'un nom d'utilisateur. Vous pouvez placer les deux dans le champ Nom d'utilisateur :entrez simplement le nom de domaine, suivi par anti-slash (\), puis par le nom utilisateur, comme parexemple MonDomain\Joe Bloggs.

    Figure 4.12. Configurer Jenkins pour utiliser un proxy

    Enfin, si vous mettez en place un accs Proxy sur votre serveur Jenkins, rappelez-vous que tous lesautres outils de ce serveur auront besoin de connatre aussi l'existence de ce proxy. En particulier, celainclut des outils comme Subversion (si vous accdez un dpt externe) et Maven (si vous n'utilisezpas un Enterprise Repository Manager).

    4.10. ConclusionVous n'avez pas besoin d'normment de configuration pour dmarrer avec Jenkins. La configurationrequise est plutt vidente, et est centralise dans l'cran Configurer le systme. Une fois que c'est fait,vous tes prt crer votre premire tche de build Jenkins !

  • Chapter 5. Configurer vos tches deBuild5.1. Introduction

    Les tches de build sont les lments de base d'un serveur d'Intgration Continue.

    Une tche de build est une manire de compiler, tester, empaqueter, dployer ou d'effectuer des actionssur votre projet. Les tches de build apparaissent sous plusieurs formes ; vous pouvez compiler et testerunitairement votre application, crer des rapports qualimtriques pour votre code source, gnrer dela documentation, empaqueter une application pour une livraison, la dployer en environnement deproduction, excuter un test de fume automatis ou n'importe quelles autres tches similaires.

    Un projet logiciel aura gnralement plusieurs tches de build attaches. Vous pourriez dmarrer avecune tche de build ddie qui excute tous les tests unitaires par exemple. Si ceux-ci se terminent avecsuccs, vous pourriez poursuivre avec une tche de build excutant des tests d'intgration plus longs,faire tourner la qualimtrie sur le code ou gnrer la documentation technique avant d'empaqueter votreapplication web pour la dployer sur un serveur de test.

    Dans Jenkins, les tches de build sont simples configurer. Dans ce chapitre, nous verrons les diffrentstypes de tches de build et la manire de les configurer. Dans les chapitres suivants, nous irons plusloin en regardant comment organiser plusieurs tches de build, comment configurer un squenage pourla promotion de builds et comment automatiser la procdure de dploiement. Dmarrons pour l'instantavec la manire de configurer une tche basique de build dans Jenkins.

    5.2. Tches de Build Jenkins

    Crer une nouvelle tche de build dans Jenkins est simple : cliquez simplement sur le lien NouveauJob du menu dans le tableau de bord de Jenkins. Jenkins supporte diffrents types de tches de build quivous sont prsents lorsque vous choisissez de crer un nouveau job (voir Figure 5.1, Jenkins supportequatre principaux types de tches de build).

    Projet free-styleLes tches de build free-style sont des tches de build gnrales apportant une grande flexibilit.

    Projet Apache MavenLe projet maven2/3 est une tche de build spcialement adapte aux projets Apache Maven.Jenkins comprend les fichiers pom et la structure des projets Apache Maven et peut utiliser lesinformations glanes dans le fichier pom pour rduire les efforts de configuration ncessaires la configuration de votre projet.

  • 84

    Contrler un job externeLa tache de build Contrler un job externe vous permet de garder un oeil sur des processusnon-interactifs externes comme des tches cron.

    Projet multi-configurationLe projet multi-configuration (galement rfrenc comme projet matrix) vous permetde faire tourner la mme tche de build avec diffrentes configurations. Cette puissantefonctionnalit peut tre utile pour tester une application dans des environnements diffrents, avecdiffrentes bases de donnes ou mme sur diffrentes machines de build. Nous regarderons plusen dtails la manire de configurer ces tches de build multi-configuration plus loin dans ce livre.

    Figure 5.1. Jenkins supporte quatre principaux types de tches de build

    Vous pouvez galement copier un job existant ce qui est une trs bonne faon de crer un nouveau jobavec une configuration trs similaire une tche de build existante, l'exception de quelques dtailsde configuration.

    Dans ce chapitre, nous nous concentrerons sur les deux premiers types de tches de build qui sont lesplus couramment utilises. Les autres seront discuts plus loin. Dmarrons avec l'option la plus flexible :la tche de build free-style.

    5.3. Crer une tche de build free-styleLa tche de build free-style est l'option la plus flexible et la plus configurable et peut tre utilisepour n'importe quel type de projet. Elle est assez rapide mettre en place et la plupart des options deconfiguration vues ici sont galement disponible dans les autres types de tches de build.

    5.3.1. Options Gnrales

    La premire section que vous voyez lorsque vous crez un job de type free-style contient les informationsgnrales du projet comme son nom unique ou sa description ainsi que d'autres indiquant comment eto la tche de build doit tre excute (voir Figure 5.2, Crer une nouvelle tche de build).

  • 85

    Figure 5.2. Crer une nouvelle tche de build

    Le nom du projet peut tre n'importe lequel mais il est bon de noter qu'il sera utilis comme repertoiredu projet et dans les URLs du job. J'vite donc gnralement d'utiliser des noms avec des espaces. Ladescription du projet apparatra sur la page de dmarrage du projet utilisez la pour donner une idegnrale sur le but de la tche de build et son contexte. Les tags HTML y sont accepts.

    Les autres options sont plus techniques et nous reviendrons sur quelques unes plus en dtails dans lasuite de ce guide.

    Un des aspects importants est la manire dont vous allez grer l'historique de vos builds. Les tchesde build peuvent consommer beaucoup d'espace disque particulirement si vous archivez les artefactsde vos builds (les fichiers binaires tels que JARs, WARs, TARs, etc. gnrs par votre tche de build).Mme sans artefacts, garder un enregistrement pour chaque tche de build consomme de la mmoire etde l'espace disque supplmentaire et cela n'est peut tre pas justifi selon la nature de votre tche de build.Par exemple, pour un job de qualimtrie gnrant des rapports sur l'analyse statique et la couverture devotre code dans le temps, vous pourriez vouloir garder une trace de vos builds pendant toute la dure duprojet. Cependant, pour une tche de build qui dploie automatiquement une application sur un serveurde test, garder un historique et les artefacts pour la postrit est peut tre beaucoup moins important.

    L'option de suppression des anciens builds vous permet de limiter le nombre de builds conservs dansl'historique. Vous pouvez aussi bien demander Jenkins de ne garder que les builds rcents (Jenkinssupprimera les builds aprs un certain nombre de jours) ou ne garder pas plus qu'un nombre dterminde builds. Si un build en particulier a une valeur sentimentale pour vous, vous pouvez toujours demander Jenkins de le conserver tout jamais en utilisant le bouton de conservation sans limite de temps surla page de dtails du build (voir Figure 5.3, Conserver un build sans limite de temps). Notez que cebouton n'apparaitra que si vous avez demand Jenkins de supprimer les anciens builds.

  • 86

    Figure 5.3. Conserver un build sans limite de temps

    En plus de cela, Jenkins ne supprimera jamais le dernier build stable qui s'est termin avec succs, peuimporte son anciennet. Par exemple, si vous limitez Jenkins pour ne conserver que les vingt derniersbuilds et que votre dernier build qui s'est termin avec succs s'est excut trente builds plus tt, Jenkinsle conservera en plus des vingt derniers builds chous.

    Vous avez aussi la possibilit de dsactiver une tche. Une tche dsactive ne sera pas excutetant que vous ne l'aurez pas ractive. Utiliser cette option lorsque vous venez de crer votre job estcependant assez rare. D'un autre ct, cette option est souvent utile lorsque vous devez suspendretemporairement une tche pendant une maintenance ou une grande refactorisation du projet et plusgnralement lorsqu'une notification d'echec de la tche de build ne sera pas utile l'quipe.

    5.3.2. Options avances du projet

    Les options avances du projet contiennent, comme l'indique le nom de cette section, des options deconfiguration moins courantes. Vous devrez cliquer sur le bouton Avanc pour les faire apparaitre. (voirFigure 5.4, Pour afficher les options avances, vous devez cliquer sur le bouton Avanc...).

    Figure 5.4. Pour afficher les options avances, vous devez cliquer sur le bouton Avanc...

    L'option priode d'attente dans la configuration du job vous permet simplement d'outrepasser la prioded'attente dfinie globalement dans la configuration du systme de Jenkins (voir Section 4.3, Configurerl'environnement systme). Cette option est principalement utilise pour les systmes de gestion deversion qui ne supportent pas les commits atomiques, comme par exemple CVS, mais galement dansles quipes o les dveloppeurs ont pour habitude de diviser le commit de leur travail en plusieurs petitescontributions.

    L'option Empcher le build quand un projet en amont est en cours de build est utile lorsque plusieursprojets lis sont affects par un seul commit mais qu'ils doivent tre construits dans un ordre spcifique.Si vous activez cette option, Jenkins attendra que toutes les tches de build en amont (voir Section 5.5,Dclencheurs de build) soient termines avant de dmarrer le build.

  • 87

    Par exemple, lorsque vous livrez une nouvelle version d'un projet Apache Maven multimodule, la mise jour du numro de version se fera dans plusieurs, voir l'ensemble, des modules du projet. Supposons quenous ayons ajout une application web au projet Game of Life que nous avons utilis dans le Chapter 2,Vos premiers pas avec Jenkins, et que nous l'ayons ajout sous la forme d'un projet Apache Mavenspar. Lorsque nous livrons une nouvelle version de ce projet, aussi bien le numro de version ducore que celui de l'application web seront mis jour (voir Figure 5.5, L'option Empcher le buildquand un projet en aval est en cours de build est utile quand un simple commit affecte plusieurs projetsdpendants les uns des autres.). Avant de pouvoir construire l'application web, nous devons construireune nouvelle version du module core de Game of Life. Cependant, si vous avez des tches de buildfree-style spares pour chaque module, les tches de build de l'application web et du core devraientdmarrer simultanment. Le build de l'application web chouera si le build du core n'a pas produit denouvelle version du module du core, mme s'il n'y a pas de test chou.

    Pour viter ce problme, vous pourriez configurer la tche de build de l'application web pour dmarrerseulement si le build du core s'est termin avec succs. Cependant, cela signifie que l'application webne serait jamais construite si des changements taient effectus uniquement pour celle-ci et non pour lemodule core. Une meilleure approche est alors d'utiliser l'option Construire la suite d'autres projets(projets en amont). Dans ce cas, lorsqu'un numro de version a t mis jour dans le contrle de version,Jenkins programmera les deux builds pour leur excution. Il attendra cependant que le build du modulecore se soit termin pour dmarrer le build de l'application web.

    game-of-life-coreversion 1.0.0-SNAPSHOT

    revision 101revision 100

    game-of-life-coreversion 1.0.0

    game-of-life-webversion 1.0.0-SNAPSHOT

    game-of-life-webversion 1.0.0

    Subversion revisions

    Figure 5.5. L'option Empcher le build quand un projet en aval est en cours de build est utile quandun simple commit affecte plusieurs projets dpendants les uns des autres.

    Vous pouvez galement surcharger l'espace de travail par dfaut utilis par Jenkins pour y tirer le codesource et construire votre projet. De manire gnrale, Jenkins crera un espace de travail spcifiquepour votre projet accessible dans le rpertoire de la tche de build de votre projet (voir Section 3.13,Whats in the Jenkins Home Directory). Cela fonctionne dans presque tous les cas. Il y a cependantdes cas dans lesquels vous pourriez avoir besoin de forcer Jenkins utiliser un espace de travail diffrentgrce cette option. Un exemple serait le cas o vous auriez besoin de construire plusieurs tches debuild dans un mme espace de travail. Vous pouvez dfinir un rpertoire de travail diffrent en cochantl'option Utiliser un rpertoire de travail spcifique et en spcifiant le chemin vous mme. Ce cheminpeut aussi bien tre absolu ou relatif au rpertoire de base de Jenkins.

  • 88

    Nous verrons d'autres options avances qui apparaissent dans cette section plus loin dans ce livre.

    5.4. Configurer la Gestion du Code SourceDans son rle le plus basique, un serveur d'Intgration Continue surveille votre systme de gestion deversion et vrifie les derniers changements au fur et mesure. Le serveur compile et test alors la versionla plus rcente du code. Il peut alternativement rcuprer et construire simplement la dernire versionde votre code source de manire rgulire. Dans tous les cas, une forte intgration avec votre systmede gestion de version est essentielle.

    De par leur rle fondamental, les options de configuration du SCM sont identiques au travers detous les types de tches de build dans Jenkins. Jenkins supporte CVS et Subversion nativement,embarque un support pour Git et s'intgre avec un grand nombre d'autres systmes de gestion de versionvia des plugins. A l'criture de ce livre, le support par plugin inclus Accurev, Bazaar, BitKeeper,ClearCase, CMVC, Darcs, Dimensions, Git, CA Harvest, Mercurial, Perforce, PVCS, Rational TeamConcert, StarTeam, Surround SCM, CM/Synergy, Microsoft Team Foundation Server et mme VisualSourceSafe. Dans le reste de cette section, nous verrons comment configurer quelques uns des SCMles plus courants.

    5.4.1. Travailler avec Subversion

    Subversion est l'un des systmes de gestion de version parmi les plus utiliss, et Jenkins embarqueun support complet de Subversion (voir Figure 5.6, Jenkins embarque par dfaut le support pourSubversion). Pour utiliser du code source provenant d'un dpt Subversion, vous devez simplementfournir l'URL correspondante - cela fonctionnera parfaitement avec n'importe lequel des trois protocolesutiliss par Subversion (http, svn ou file). Jenkins vrifiera que l'URL est valide aussitt que vous l'aurezremplie. Si le dpt ncessite une authentification, Jenkins vous questionnera alors sur vos identifiantsautomatiquement et les enregistrera pour tout autre tche de build qui aura besoin d'accder ce mmedpt.

    Figure 5.6. Jenkins embarque par dfaut le support pour Subversion

  • 89

    Par dfaut, Jenkins rcuprera le contenu du dpt dans un sous-rpertoire de votre espace de travail,dont le nom sera celui du dernier lment de l'URL Subversion. Donc si votre URL Subversion est svn://localhost/gameoflife/trunk, Jenkins rcuprera le contenu du dpt dans une rpertoire nomm trunkdans l'espace de travail de votre tche de build. Si vous prfrez nommer votre rpertoire diffremment,remplissez le nom que vous souhaitez dans le champ Local module directory. Mettez un point(.) dans le champ si vous souhaitez mettre le code source directement la racine de l'espace de travail.

    Occasionnellement, vous aurez besoin de rcuprer du code source de plusieurs URLs Subversion. Dansce cas, utilisez le bouton Add more locations... pour ajouter autant de dpts sources que vous enavez besoin.

    Une bonne procdure de build ne devrait pas modifier le code source ou laisser de fichierssupplmentaires qui pourrait porter confusion votre systme de gestion de version ou la procdure debuild. Les artefacts gnrs et fichiers temporaires (comme les fichiers de journaux, rapports, donnesde test ou bases de donnes fichier) devraient tre crs dans un rpertoire spar et cr spcifiquementpour ce besoin (tout comme le rpertoire target dans les builds Apache Maven), et/ou tre configurspour tre ignors par le dpt de votre systme de gestion de version. Ces fichiers devrait galement tresupprims par la procdure de build, une fois que le build n'en a plus besoin. Cela prend galement unegrande importance dans l'assurance de construire une procdure de build propre et reproductiblepourune version donne de votre code source, le build devrait se comporter exactement de la mme manire,peu importe o et quand il est excut. Les changements locaux, et la prsence de fichiers temporaires,peuvent potentiellement compromettre cela.

    Vous pouvez finement configurer la manire dont Jenkins rcupre la dernire version de votre codesource en slectionnant la valeur attendue dans la liste droulante Check-out Strategy. Si votre projet estcorrectement configur, vous pouvez cependant acclrer grandement les choses en choisissant Usesvn update as much as possible. Il s'agit de l'option la plus rapide mais elle laisse les artefacts etfichiers des builds prcdents dans votre espace de travail. Pour vous positionner du ct de la scurit,vous pouvez choisir la seconde option (Use svn update as much as possible, with svn revert beforeupdate), qui excutera systmatiquement svn revert avant de lancer svn update. Cela vousassurera qu'aucun fichier n'aura t modifi localement. Cependant, cela ne supprimera pas les fichiersnouvellement crs pendant la procdure de build. Sinon, vous pouvez demander Jenkins de supprimertous les fichiers ignorer ou non versionns avant de faire un svn update ou encore jouer la carte dela scurit et rcuprer une copie propre et complte chaque build.

    Une autre fonctionnalit de Jenkins particulirement utile est sont intgration avec les navigateursde code source. Un bon navigateur de code source est un lment important de votre configurationd'Intgration Continue. Cela vous permet de voir d'un coup d'il les changements qui sont l'origine dulancement de votre build, ce qui est trs utile quand vous avez besoin de localiser un problme lors d'unbuild chou (voir Figure 5.7, Navigateur de code source montrant les changements dans le code quiont caus le build.). Jenkins intgre la plupart des principaux navigateurs de source code, y compris desoutils open source comme WebSVN ou Sventon, ainsi que ceux commerciaux tels qu'Atlassian FishEye.

    svn://localhost/gameoflife/trunksvn://localhost/gameoflife/trunk

  • 90

    Figure 5.7. Navigateur de code source montrant les changements dans le code qui ont caus le build.

    Jenkins vous permet galement d'affiner la slection des changements qui dclencheront un build.Dans la section avance, vous pouvez utiliser le champ Rgions exclues pour dire Jenkins de ne pasdclencher de build si certains fichiers sont modifis. Ce champ prend en compte une liste d'expressionsrgulires qui identifient les fichiers qui ne doivent pas dclencher de build. Par exemple, supposez quevous ne voulez pas que Jenkins dmarre un build si seulement des images ont t modifies. Pour cefaire, vous pouvez utiliser un groupe d'expressions rgulires comme celles qui suivent :

    /trunk/gameoflife/gameoflife-web/src/main/webapp/.*\.jpg/trunk/gameoflife/gameoflife-web/src/main/webapp/.*\.gif/trunk/gameoflife/gameoflife-web/src/main/webapp/.*\.png

    De manire alternative, vous pouvez spcifier uniquement les Rgions Incluses, si vous n'tes intressque par les changements d'une partie de votre arbre de code source. Vous pouvez mme combiner leschamps Rgions exclues et Rgions Incluses dans ce cas, un fichier modifi ne dclenchera un buildque s'il est inclus dans les Rgions Incluses mais pas dans les Rgions Exclues.

    Vous pouvez galement ignorer les changements provenant de certains utilisateurs (Utilisateurs Exclus),ou pour certains messages de commit en particulier (Excluded Commit Messages). Par exemple, sivotre projet utilise Maven, vous pourrez tre amen utiliser le plugin Maven Release Plugin pourpromouvoir votre application d'une version snapshot vers une version release officielle. Ce pluginpoussera automatiquement le numro de version de votre application depuis sa version snapshot utilisependant le dveloppement (comme par exemple 1.0.1-SNAPSHOT) vers une version release (1.0.1),empaquettera, dploiera votre application avec ce numro de version et le mettra jour avec le prochain

  • 91

    numro de version snapshot (par exemple 1.0.2-SNAPSHOT) pour les dveloppements futurs. Pendantcette procdure, Apache Maven s'occupe de multiples tapes comptables comme d'effectuer le commitdu nouveau numro de version, de crer la nouvelle tiquette pour la livraison de votre application etenfin faire l'opration de commit pour le nouveau numro de version snapshot.

    Supposez maintenant que vous avez une tche de build spcifique pour effectuer une nouvelle livraisonutilisant cette procdure. Les diffrentes oprations de commits gnres par le plugin Maven ReleasePlugin devraient normalement dclencher des tches de build dans Jenkins. Cependant, comme votretache de build de livraison est dj en train de compiler et tester cette version de votre application,vous n'avez pas besoin que Jenkins le fasse nouveau dans une autre tche de build. Pour s'assurer queJenkins ne dclenche pas un autre build dans ce cas, vous pouvez utiliser le champ Excluded CommitMessages avec la valeur suivante :

    [maven-release-plugin] prepare release.*

    Cela vous assurera que Jenkins sautera les changements correspondant des nouvelles versions derelease mais pas ceux correspondant la prochaine version snapshot.

    5.4.2. Travailler avec Git

    Contribu par Matthew McCullough

    Git1 est un systme de gestion de version distribu qui est le successeur logique de Subversion2 et unconcurrent Mercurial3 partageant le mme esprit. Le support de Git dans Jenkins est mature et complet.Il y a galement plusieurs plugins qui peuvent contribuer au workflow gnral de Git dans Jenkins. Nouscommencerons par nous intresser au plugin Git qui apporte le support des fonctions principales de Git.Nous aborderons le sujet des plugins supplmentaires brivement.

    5.4.2.1. Installation du plugin

    Le plugin Git est disponible dans le Gestionnaire de Plugins Jenkins et est document sur sa proprepage de wiki4. Le plugin suppose que Git (version 1.3.3 ou ultrieure) a t install sur le serveur debuild. Vous devrez donc vous en assurer pralablement. Vous pouvez vous en assurer en excutant lacommande suivante sur votre serveur de build :

    $ git --versiongit version 1.7.1

    Revenez ensuite Jenkins et cochez la case correspondante dans le gestionnaire de plugins Jenkins etcliquez sur le bouton d'installation.

    1 http://git-scm.com/2 http://subversion.tigris.org/3 http://mercurial.selenic.com/4 https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin

    http://git-scm.com/http://subversion.tigris.org/http://mercurial.selenic.com/https://wiki.jenkins-ci.org/display/JENKINS/Git+Pluginhttp://git-scm.com/http://subversion.tigris.org/http://mercurial.selenic.com/https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin

  • 92

    5.4.2.1.1. Configuration systme du plugin

    Aprs l'installation du plugin Git, une nouvelle section de configuration est disponible dans la pageAdministrer Jenkins#Configurer le systme (voir Figure 5.8, Configuration systme du plugin Git).Vous devez en particulier fournir le chemin vers l'excutable de Git. Si Git est dj install sur votresystme, entrez simplement git dans le champ.

    Figure 5.8. Configuration systme du plugin Git

    5.4.2.1.2. Configuration de la cl SSH

    Si le dpt Git auquel vous accdez utilise SSH sans mot de passe comme moyen d'authentificationpar exemple si l'adresse d'accs ressemble git@github.com:matthewmccullough/some-repo.gitvous devrez fournir la partie prive de la cl sous forme de fichier ~/.ssh/id_rsa o ~est le rpertoire racine du compte utilisateur excutant Jenkins.

    L'empreinte du serveur distant devra additionnellement tre ajoute dans ~/.ssh/known_hosts pourviter que Jenkins ne vous invite accepter l'autorisation vers le serveur Git lors du premier accs alorsque la console sera non interactive.

    Alternativement, si vous avez la possibilit de vous connecter avec l'utilisateur jenkins, accdez parSSH la machine Jenkins en tant que jenkins et faites une tentative manuelle de cloner un dpt Gitdistant. Cela testera la configuration de votre cl prive et remplira le fichier known_hosts dans lerpertoire ~/.ssh. C'est probablement la solution la plus simple de vous familiariser avec les subtilitsde la configuration SSH.

    5.4.2.2. Utilisation du plugin

    Que cela soit dans un nouveau projet Jenkins ou dans un projet existant, une nouvelle option de Gestiondu Code Source pour Git sera affiche. Ds lors, vous pouvez configurer une ou plusieurs adresses dedpts (voir Figure 5.9, Remplir une URL de dpt Git). Un seul dpt est utilis dans la majorit desprojets. Ajouter un second dpt peut tre utile dans des cas plus compliqus et vous permet de spcifierdes cibles distinctes pour les oprations de pull et de push.

  • 93

    5.4.2.2.1. Configuration avance par projet de la gestion du code source

    Dans la plupart des cas, l'URL du dpt Git que vous utilisez devrait tre suffisante. Cependant, si vousavez besoin de plus d'options, cliquez sur le bouton Avanc (voir Figure 5.10, Configuration avanced'une URL de dpt Git). Cela apporte un contrle plus prcis sur le comportement du pull.

    Le Nom du dpt est un titre raccourci (ou remote en langage Git) pour un dpt donn auquel vouspouvez vous reporter plus tard dans la configuration de l'action de merge.

    La Refspec est un terme5 spcifique du langage Git pour contrler prcisment ce qui est rcupr depuisles serveurs distants et sous quel espace de nom c'est stock localement.

    5.4.2.2.2. Branches construire

    Le champ Branch Specifier (Figure 5.11, Configuration avance des branches Git construire) peuttre utilis l'aide d'un caractre gnrique ou en spcifiant le nom d'une branche construire parJenkins. Si le champ est laiss vide, toutes les branches seront construites. Pour le moment, lorsque voussauvegardez votre tche pour la premire fois et qu'elle est configure avec ce champ vide, il est alorsrempli avec **, ce qui signifie "construire toutes les branches".

    Figure 5.9. Remplir une URL de dpt Git

    5 http://progit.org/book/ch9-5.html

    http://progit.org/book/ch9-5.htmlhttp://progit.org/book/ch9-5.html

  • 94

    Figure 5.10. Configuration avance d'une URL de dpt Git

    Figure 5.11. Configuration avance des branches Git construire

    5.4.2.2.3. Rgions exclues

    Les rgions (vues dans Figure 5.12, Branches et rgions) sont des chemins nomms spcifiquementou gnriques de votre code source qui, mme une fois modifis, ne doivent pas dclencher de build.Il s'agit gnralement de fichiers non compils tels que les archives de locales ou d'images qui n'ont priori pas d'effet sur les tests unitaires ou d'intgration.

  • 95

    Figure 5.12. Branches et rgions

    5.4.2.2.4. Utilisateurs Exclus

    Le plugin Git vous permet galement d'ignorer certains utilisateurs mme s'ils effectuent deschangements du code source qui auraient d normalement dclencher un build.

    Cette action n'est pas aussi mchante qu'elle peut paraitre : les utilisateurs exclus sont gnralementdes utilisateurs automatiss ou des dveloppeurs non humains, qui ont des comptes distincts avec desdroits de commit sur le gestionnaire de code source. Ces utilisateurs automatiss font gnralementde petites oprations comme incrmenter la version d'un fichier pom.xml plutt que de vritableschangements dans la logique de votre application. Si vous souhaitez exclure plusieurs utilisateurs,ajoutez les simplement sur des lignes spares.

    5.4.2.2.5. Rcuprer/fusionner sur une branche locale

    Parfois vous aurez le besoin de rcuprer directement le HEAD de manire spare dans une brancheau travers du hash d'un commit. Dans ce cas, spcifiez votre branche locale dans le champ Checkout/merge to a local branch.

  • 96

    Il est plus simple de l'illustrer par un exemple. Sans spcifier de branche locale, le plugin ferait quelquechose comme cela :

    git checkout 73434e4a0af0f51c242f5ae8efc51a88383afc8a

    Autrement, si vous utilisiez une branche nomme maBranche, Jenkins ferait la chose suivante :

    git branch -D maBranchegit checkout -b maBranche 73434e4a0af0f51c242f5ae8efc51a88383afc8a

    5.4.2.2.6. Dpt dans un sous-rpertoire local

    Par dfaut, Jenkins clonera le dpt Git directement dans l'espace de travail de votre tche de build. Sivous prfrez utiliser un rpertoire diffrent, vous pouvez le spcifier ici. Notez que ce rpertoire estrelatif l'espace de travail de votre tche de build.

    5.4.2.2.7. Fusionner avant le build

    Le cas typique d'utilisation de cette option est le remplissage d'une branche d'intgration proche de labranche master. N'oubliez pas que seulement les fusions ne prsentant pas de conflit seront effectuesautomatiquement. Les fusions plus complexes qui requirent une intervention manuelle feront chouerle build.

    La branche fusionne qui en rsulte ne sera pas pousse automatiquement moins que l'action de pushne soit active dans les actions post-build.

    5.4.2.2.8. Tailler les branches distantes avant le build

    Le taillage supprime les copies locales de branches distantes qui proviennent d'un clone prcdent maisqui ne sont plus prsentent sur le dpt distant. En rsum, il s'agit du nettoyage du clone local pourqu'il soit parfaitement synchronis avec son jumeau distant.

    5.4.2.2.9. Nettoyer aprs rcupration

    Active la purge de tout fichier ou rpertoire non versionn, ramenant le votre copie de travail sontt vierge.

    5.4.2.2.10. Mise jour rcursive des sous-modules

    Si vous utilisez les fonctionnalits de sous-modules de Git dans votre projet, cette option vous assureque chaque sous-module est jour grce un appel explicite la commande update, mme si les sous-modules sont imbriqus dans d'autres sous-modules.

    5.4.2.2.11. Utiliser l'auteur du commit dans changelog

    Jenkins note et affiche l'auteur du changement de code dans une vue synthtique. Git note l'auteur etle commiter du code distinctement, et cette option vous permet de choisir lequel apparatra dans lechangelog.

  • 97

    5.4.2.2.12. Effacer l'espace de travail

    Typiquement Jenkins rutilisera l'espace de travail, le rafrachissant simplement si ncessaire et sivous avez activ l'option Clean after checkout, nettoiera les fichiers non versionns. Cependant, sivous prfrez avoir un espace de travail compltement propre, vous pouvez utiliser l'option Wipe outworkspace pour supprimer et reconstruire l'espace de travail de zro. Gardez l'esprit que cela allongerasignificativement le temps d'initialisation et de construction du projet.

    5.4.2.2.13. Choix de la stratgie

    Jenkins decide quelle branches il doit construire en se basant sur une certaine stratgie (voir Figure 5.13,Choix de la stratgie). Les utilisateurs peuvent influencer cette procdure de recherche de branche. Lechoix par dfaut est de rechercher tous les HEADs de branche. Si le plugin Gerrit est install, d'autresoptions pour construire tous les commits notifis par Gerrit seront affiches.

    Figure 5.13. Choix de la stratgie

    5.4.2.2.14. Excutable Git

    Dans les options globales de Jenkins (voir Figure 5.14, Configuration globale de l'excutable de Git),plusieurs excutables Git peuvent tre configurs et utiliss build par build. Cela est rarement utilis etl'est seulement lorsqu'un clone ou d'autres oprations Git sont sensibles une version particulire deGit. Git tend tre trs flexible quant ses numro de version ; les dpts lgrement anciens peuventtre clons trs facilement avec une nouvelle version de Git et inversement.

  • 98

    Figure 5.14. Configuration globale de l'excutable de Git

    5.4.2.2.15. Navigateur de dpt

    Tout comme Subversion, Git a plusieurs navigateurs de source qu'il peut utiliser. Les plus courammentutiliss sont Gitorious, Git Web, ou GitHub. Si vous fournissez l'URL correspondante votre navigateurde dpt, Jenkins pourra alors afficher un lien direct vers les changements de votre code source qui ontdclench le build (voir Figure 5.15, Navigateur de dpt).

    Figure 5.15. Navigateur de dpt

    5.4.2.3. Dclencheurs de build

    Le plugin Git de base offre la possibilit de scruter l'outil de gestion de version rgulirement et devrifier si de nouveau changements ont eu lieu depuis la dernire requte. Si des changements sont

  • 99

    prsents, un build est alors lanc. Le journal de scrutation (montr dans Figure 5.16, Journal descrutation) est accessible par un lien dans la partie gauche de la page dans la barre de navigation lorsquevous visitez une tche spcifique. Vous y trouverez les informations sur la dernire fois que le dpt a tscrut et s'il a renvoy une liste de changements (voir Figure 5.17, Rsultats de la scrutation de Git).

    Figure 5.16. Journal de scrutation

    La scrutation de Git est disponible dans un format plus orient dveloppeur qui montre les commentairesde commit ainsi que des hyperliens pointant vers une vue plus dtaille des utilisateurs et des fichiersmodifis.

    Figure 5.17. Rsultats de la scrutation de Git

    Installer le Gerrit Build Trigger ajoute une option Gerrit event qui peut tre plus efficace et prcise quede simplement scruter le dpt.

    5.4.2.3.1. Dclenchement par Gerrit

    Gerrit6 est une application web open source qui facilite les revues de code7 pour les projets dont lessources sont gres par Git. Il lit le dpt Git traditionnel et apporte une comparaison cte--cte deschangements. Lorsque le code est revu, Gerrit apporte alors un lieu pour commenter et dplacer le patchdans un tat ouvert, fusionn ou abandonn.

    6 http://code.google.com/p/gerrit/7 https://review.source.android.com/#q,status:open,n,z

    http://code.google.com/p/gerrit/https://review.source.android.com/#q,status:open,n,zhttp://code.google.com/p/gerrit/https://review.source.android.com/#q,status:open,n,z

  • 100

    Le Gerrit Trigger8 est un plugin Jenkins qui peut dclencher un build Jenkins sur du code quandn'importe quelle activit lie un utilisateur spcifique survient dans le projet d'un utilisateur dfini dudpt Git (voir Figure 5.18, Dclenchement par Gerrit). Il s'agit d'une alternative aux options plusrgulirement utilises comme la construction priodique ou la scrutation de l'outil de gestion de version.

    Figure 5.18. Dclenchement par Gerrit

    La configuration de ce plugin est minimale et focalise sur le Type du Projet et son Pattern ainsi quele Type de Branches et leur Pattern. Dans chaque paire, le type peut tre Plain, Path ou bien RegExp descriptif de ce qu'il faut observer et la valeur (pattern) valuer en utilisant le type type commeguide.

    5.4.2.4. Actions post-build

    Le plugin Git pour Jenkins ajoute des capacits spcifiques Git au post-traitement des artefacts dubuild. Plus spcifiquement, le Git Publisher (montr dans Figure 5.19, Git Publisher) permet lesactions de merge et de push. Cochez la case du Git Publisher pour afficher ses quatres options.

    8 http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Trigger

    http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Triggerhttp://wiki.hudson-ci.org/display/HUDSON/Gerrit+Trigger

  • 101

    Figure 5.19. Git Publisher

    5.4.2.4.1. Pousser seulement si le build est russi

    Si une fusion ou tout autre action entranant la cration d'un commit a t faite pendant le build Jenkins,cette option peut alors tre active pour pousser les changements dans le dpt distant.

    5.4.2.4.2. Fusionner les rsultats

    Si une fusion au dbut du build a t configure, la branche rsultante est alors pousse vers son origine(voir Figure 5.20, Fusionner les rsultats).

  • 102

    Figure 5.20. Fusionner les rsultats

    5.4.2.4.3. tiquettes

    Lorsque vous poussez des tiquettes, chacune d'elle peut tre nomme et choisie d'tre cre si ellen'existe pas (ce qui choue si elle existe dj). Les variables d'environnement peuvent tre utilisesdans le nom des tiquettes. Par exemple vous pouvez utiliser l'ID du process avec HUDSON_BUILD_$PPID ou mme le numro de build s'il est fourni par un plugin Jenkins avec $HUDSON_AUTOTAG_$BUILDNUM. Les tiquettes peuvent tre cibles sur un dpt distant spcifique comme origin ouintegrationrepo.

    5.4.2.4.4. Branches

    Le HEAD courant utilis dans le build Jenkins d'une application peut tre pouss dans d'autres dptsdistants lors d'une tape suivant le build. Vous n'avez spcifier que la branche de destination et le nomdu dpt distant.

    Les noms des dpts distants sont valids en comparaison la configuration prcdemment faite duplugin. Si le dpt n'existe pas, un avertissement est affich.

    5.4.2.5. Plugin GitHub

    Le plugin GitHub offre deux points d'intgration. Premirement, il apporte un lien optionnel vers lapage de dmarrage du projet sur GitHub. Entrez simplement l'URL du projet (sans la partie tree/masterou tree/branch). Par exemple, http://github.com/matthewmccullough/git-workshop.

    Ensuite, le plugin GitHub plugin permet d'obtenir un lien par fichier modifi qui sera reli directementau navigateur de dpt via la section de gestion du code source (voir Figure 5.21, Navigateur de dptGitHub).

  • 103

    Figure 5.21. Navigateur de dpt GitHub

    Avec le choix de githubweb comme navigateur de dpt, tout fichier sur lequel des changementsauront t dtects sera li la page web de visualisation du source approprie sur GitHub (Figure 5.22,Navigateur de dpt GitHub).

    Figure 5.22. Navigateur de dpt GitHub

    5.5. Dclencheurs de buildUne fois que vous avez configur votre systme de gestion de version, vous devez dire Jenkins quanddmarrer un build. Vous pouvez configurer cela dans la section Ce qui dclenche le build.

    Dans un build free-style, il y a trois manires basiques de dclencher une tche de build (voir Figure 5.23,Il y a de multiples manires de configurer Jenkins pour le dmarrage d'une tche de build):

    Dmarrer une tche de build une fois qu'une autre s'est termine

    Lancer des builds des intervalles priodiques

    Scruter les changements sur le SCM

    Figure 5.23. Il y a de multiples manires de configurer Jenkins pour le dmarrage d'une tche de build

  • 104

    5.5.1. Dclencher une tche de build lorsqu'une autre tche de buildse termine

    La premire option vous permet de configurer un build qui se lancera chaque fois qu'un autre buildse terminera. C'est une manire facile de construire une squence de build. Par exemple, vous pourriezconfigurer une tche de build initiale qui lancera des tests unitaires et des tests d'intgration, suivie d'uneautre tche de build spare qui lancera de l'analyse statique de code, plus gourmande en CPU. Vousremplissez simplement le nom du job prcdent dans ce champ. Si la tche de build peut tre lancepar plusieurs autres tches de build, listez simplement leurs noms ici en les sparant par des virgules.Dans ce cas l, la tche de build sera dclenche chaque fois que des tches de build prsentes dansla liste se termineront.

    Il y a un champ symtrique dans la section des Actions la suite du build appele Construire d'autresprojets. Ce champ sera mis jour automatiquement dans les tches de build correspondantes encohrence avec ce que vous aurez rempli ici. Cependant, au contraire de Construire la suite d'autresprojets, vous avez la possibilit de dclencher une autre tche de build mme si le build est instable(voir Figure 5.24, Dclencher une autre tche de build mme si celle-ci est instable.). Cela est utilepar exemple si vous voulez excuter une tche de build sur des indicateurs de qualit du code mme s'ily a des tests unitaires qui ont chou dans la premire tche de build.

    Figure 5.24. Dclencher une autre tche de build mme si celle-ci est instable.

    5.5.2. Tches de build priodiques

    Une autre stratgie est simplement de dclencher une tche de build intervalle rgulier. Il est importantde faire remarquer qu'il ne s'agit plus d'Intgration Continue ; il s'agit simplement de builds priodiques,chose que vous pourriez tout aussi bien faire, par exemple, avec une tche cron sous Unix. Aux dbutsdes builds automatiss, et toujours aujourd'hui dans beaucoup d'entreprises, les builds ne sont pasexcuts en rponse aux changements commits dans le systme de contrle de version mais seulementla nuit (build nocturne journalier). Cependant, pour tre efficace, le serveur d'Intgration Continue doitapporter un retour d'information beaucoup plus rapidement qu'une seule fois par jour.

    Il y a toutefois quelques cas o les tches priodiques auront une utilit. Cela inclut les trs longues tchesde build, lorsqu'un retour rapide est moins critique. Par exemple, des tests de charge et de performanceintensifs qui prennent plusieurs heures s'excuter ou des tches de build Sonar. Sonar est une excellentemanire de conserver une vue sur vos indicateurs de qualit du code de vos projets et au fur et mesureque le temps passe mais il ne permet de conserver qu'un seul lot de donnes par jour. Il n'est donc pasncessaire d'excuter des builds Sonar plus frquemment que cela.

    Pour toutes les tches priodiques, Jenkins utilise une syntaxe ressemblant celle de cron. Cette syntaxeest constitue de cinq champs spars par des espaces blancs au format suivant :

  • 105

    MINUTES HEURES JOURMOIS MOIS JOURSEMAINE

    Les valeurs suivantes sont possibles pour chaque champ :

    MINUTESLes minutes dans une heure (0-59)

    HEURESLes heures dans une journe (0-23)

    JOURMOISLe jour dans un mois (1-31)

    MOISLe mois (1-12)

    JOURSEMAINELe jour de la semaine (0-7) o 0 et 7 reprsentent le dimanche

    Il existe galement quelques raccourcis :

    * reprsente l'ensemble des valeurs possibles. Par exemple, * * * * * signifie toutes lesminutes.

    Vous pouvez dfinir des espaces en utilisant la notation MN. Par exemple 1-5 dans le champJOURSEMAINE signifie lundi vendredi.

    Vous pouvez utiliser la notation slash pour dfinir des sauts dans un espace. Par exemple, */5dans le champ MINUTES signifie toutes les cinq minutes.

    Une liste dont les lments sont spars par des virgules indique une liste de valeur prises encompte. Par exemple, 15,45 dans le champ MINUTES signifie aux minutes 15 et 45 de chaqueheure.

    Vous pouvez aussi utiliser les raccourcis suivants : @yearly, @annually, @monthly,@weekly, @daily, @midnight, et @hourly.

    Gnralement vous n'aurez besoin que d'une seule ligne dans ce champ mais pour des configurations depriodicit plus compliques, vous aurez peut-tre besoin de plusieurs lignes.

    5.5.3. Scruter le SCM

    Comme nous avons pu le voir, les tches de build priodiques ne sont gnralement pas la meilleurestratgie pour la plupart des tches de build d'Intgration Continue. La valeur du retour d'informationest proportionnelle la vitesse laquelle vous recevez ce retour et il n'y a pas d'exception en ce quiconcerne l'Intgration Continue. C'est pour cette raison que scruter le SCM est gnralement une bienmeilleure option.

  • 106

    La scrutation implique l'interrogation intervalles rguliers du serveur de contrle de version poursavoir si des changements ont t ajouts. Si des changements ont t faits dans le code source du projet,Jenkins lance alors un build. Scruter est habituellement une opration peu coteuse, vous pouvez doncle faire frquemment pour vous assurer qu'un build sera lanc rapidement aprs tout commit de codesource. Plus vous scruterez frquemment, plus votre tche dmarrera rapidement et plus prcis sera leretour d'information li aux changements effectus dans le cas o le build choue.

    Dans Jenkins, la scrutation du SCM est trs facile configurer et utilise la mme syntaxe cronprcdemment prsente.

    Naturellement vous aurez l'envie de scruter le SCM le plus souvent possible (par exemple en utilisant ** * * * pour chaque minute). Comme Jenkins n'utilise que des requtes simples et ne lance de build quelorsque le code source a t modifi, cette approche est souvent raisonnable pour de petits projets. Celamontre cependant des limites quand il y a un grand nombre de tches de build car cela pourrait saturer leserveur SCM et le rseau avec les requtes dont beaucoup sont inutiles. Dans ce cas, une approche plusprcise sera plus approprie avec un dclenchement de la tche de build directement par le SCM lorsqu'ilreoit un changement. Cette option est discute dans Section 5.5.4, Dclencher des builds distance.

    Si des changements sont commits trs frquemment et dans un grand nombre de projets, cela peutcauser la cration d'une longue liste d'attente de tches de build et ainsi retarder le retour d'informationpar la suite. Vous pouvez donc partiellement rduire la file d'attente de builds en scrutant moinsrgulirement le SCM mais au prix d'un retour d'information moins prcis.

    Si vous utilisez CVS, scruter n'est peut tre pas une bonne option. Lorsque CVS vrifie les nouveauxchangements d'un projet, il vrifie chaque fichier un par un ce qui une procdure lente et fastidieuse.La meilleure solution est de migrer vers un systme de contrle de version plus moderne tel que Gitou Subversion. La deuxime meilleure solution sera de scruter des intervalles beaucoup plus espacs(toutes les 30 minutes par exemple).

    5.5.4. Dclencher des builds distance

    Scruter peut tre une stratgie efficace pour des petits projets projects mais cela ne s'adapte pas trs bien un grand nombre de jobs. Cela utilise inutilement beaucoup de ressources rseau et il y a toujours uncourt dlai entre le commit de nouveau code et le dmarrage de la tche de build. La stratgie sera doncde dlguer votre systme de gestion de version le dclenchement du build dans Jenkins ds qu'unchangement est commit.

    Il est facile de dmarrer une tche de build Jenkins distance. Vous devez simplement invoquer uneURL de la forme suivante :

    http://SERVER/jenkins/job/PROJECTNAME/build

    Par exemple, si mon serveur Jenkins est accessible http://myserver:8080/jenkins, je pourrais dmarrerla tche de build gameoflife en invoquant l'URL suivante en utilisant un outil tel que wget ou curl :

    $ wget http://myserver:8080/jenkins/job/gameoflife/build

  • 107

    L'astuce alors est de faire faire cette invocation directement par votre serveur de contrle de versionds qu'un changement est commit. Les dtails dans la manire de faire sont diffrent pour chaquesystme de contrle de version. Dans Subversion, par exemple, vous devrez crire un script excutautomatiquement aprs la soumission de code pour faire dclencher le build. Votre script pourrait parexemple parcourir l'URL de votre dpt, en extraire le nom du projet et ensuite effectuer une oprationde wget sur l'URL correspondante la tche de build :

    JENKINS_SERVER=http://myserver:8080/jenkinsREPOS="$1"

    PROJECT=/usr/bin/wget $JENKINS_SERVER/job/${PROJECT}/build

    Utilisez une expression rgulire pour extraire le nom de votre projet de l'URL de votre dptSubversion.

    Cette approche ne dclenchera cependant qu'un build en particulier et se repose sur une convention denommage qui veut que la tche de build par dfaut se base sur le nom de votre dpt Subversion. Vouspouvez opter pour une approche plus flexible avec Subversion en utilisant directement l'API Subversionde Jenkins comme cela est dmontr ici :

    JENKINS_SERVER=http://myserver:8080/jenkinsREPOS="$1"REV="$2"UUID=`svnlook uuid $REPOS`/usr/bin/wget \ --header "Content-Type:text/plain;charset=UTF-8" \ --post-data "`svnlook changed --revision $REV $REPOS`" \ --output-document "-" \ --timeout=2 \ $JENKINS_SERVER/subversion/${UUID}/notifyCommit?rev=$REV

    Cela dclenchera automatiquement n'importe quelle tche de build Jenkins qui surveille ce dptSubversion.

    Si vous avez activ la scurit dans Jenkins, les choses peuvent devenir un peu plus compliques. Dansle plus simple des cas (o n'importe quel utilisateur peut faire ce qu'il veut), vous n'avez qu' activerl'option Dclencher les builds distance (voir Figure 5.25, Dclencher un build via une URL enutilisant un jeton), et fournir une chane de caractres spcifique qui pourra tre utilise dans l'URL :

    http://SERVER/jenkins/job/PROJECTNAME/build?token=DOIT

  • 108

    Figure 5.25. Dclencher un build via une URL en utilisant un jeton

    Cela ne fonctionnera pas si les utilisateurs ont besoin d'tre authentifis pour dclencher un build (parexemple si vous utilisez une scurit par projet ou base sur une matrice). Dans ce cas, vous aurez besoinde fournir un nom d'utilisateur et un mot de passe, comme montr dans l'exemple suivant :

    $ wget http://scott:tiger@myserver:8080/jenkins/job/gameoflife/build

    ou :

    $ curl -u scott:tiger http://scott:tiger@myserver:8080/jenkins/job/gameoflife/build

    5.5.5. Construction manuelle de tches

    Une construction ne doit pas forcment tre dclenche automatiquement. Certaines tches de builddoivent seulement tre dmarres manuellement, par une intervention humaine. Par exemple, vouspourriez avoir besoin de configurer un dploiement automatique dans un environnement de test devalidation (UAT), qui ne devra tre dmarr qu' la demande de vos collgues de la validation (QA).Dans ce cas, laissez simplement la section Ce qui dclenche le build vide.

    5.6. Les tapes de buildsMaintenant, Jenkins sait o et quelle frquence obtenir le code source du projet. La prochaine choseque vous devez expliquer Jenkins est quest ce quil doit faire avec le code source. Dans un buildFreestyle, vous pouvez faire ceci en dfinissant des tapes de build. Les tapes de build sont des blocsbasiques de construction pour le processus de build Freestyle de Jenkins. Cest ce qui permet de dire Jenkins exactement comment vous voulez que votre projet soit construit.

    Une tche de build peut avoir une tape, ou plusieurs. Il peut ventuellement nen avoir aucune. Dans unbuild Freestyle, vous pouvez ajouter autant dtapes de build que vous le souhaitez dans la section Buildde la configuration de votre projet (voir la figure Figure 5.26, Ajouter une tape de build une tche debuild Freestyle). Dans une installation Jenkins basique, vous serez capable dajouter des tapes pour

  • 109

    invoquer Maven et Ant, aussi bien que lancer des commandes shell spcifique lOS ou des batchsWindows. Et en installant des plugins additionnels, vous pouvez aussi intgrer dautres outils, commeGroovy, Gradle, Grailes, Jython, MSBuild, Phing, Python, Rake, et Ruby, juste pour nommer certainsdes outils les plus connus.

    Dans le reste de cette section, nous allons plonger dans quelques-uns des types dtapes de build lesplus communs.

    5.6.1. Les tapes de build Maven

    Jenkins a un excellent support de Maven, et les tapes de build Maven sont faciles configurer et trsflexibles. Il suffit de choisir Invoquer les cibles Maven de haut niveau depuis la liste des tapes debuild, choisir une version de Maven lancer (si vous avez plusieurs versions installes), et entrer lesgoals Maven que vous souhaitez lancer. Les tches de build Freestyle de Jenkins fonctionnent biensavec Maven 2 et Maven 3.

    Tout comme en ligne de commande, vous pouvez spcifier autant de goals individuels que vous lesouhaitez. Vous pouvez aussi fournir des options en ligne de commande. Quelques options utiles deMaven dans un contexte IC sont :

    -B, --batch-modeCette option indique Maven de ne pas demander dentre lutilisateur, en utilisant les valeurspar dfaut si ncessaire. Si Maven demande nimporte quelle entre durant un build Jenkins, lebuild sera bloqu indfiniment.

    -U, --update-snapshotsForce Maven vrifier les mises jour des dpendances de type release ou snapshot sur le dptdistant. Cela vous permet dtre sr que vous tes en train de construire avec les dernires et lesplus grandes dpendances snapshot, et pas uniquement les vieilles copies locales qui ne sont pasforcment synchronises avec le code source.

    -Dsurefire.useFile=false

    Cette option force Maven crire la sortie JUnit dans la console, au lieu de le faire dans desfichiers textes dans le rpertoire target comme cest fait dhabitude. Avec ceci, nimporte quelsdtails de test en chec seront visibles directement dans la sortie console de la tche de build. Lesfichiers XML dont Jenkins a besoin pour ses rapports de test seront toujours gnrs.

  • 110

    Figure 5.26. Ajouter une tape de build une tche de build Freestyle

    Les options avances sont galement utiles (cliquez sur le bouton Avanc).

    Le champ optionnel POM permet de surcharger lemplacement par dfaut du fichier pom.xml. Cestlquivalent de lancer Maven en ligne de commande avec loption -f ou --file. Cest utile pourcertains projets multi modules o le fichier agrg pom.xml (celui contenant les sections )est situ dans un sous rpertoire et non au niveau suprieur.

    Le champ Properties vous permet de spcifier des valeurs de proprit qui seront passes au processusde build Maven, en utilisant le format standard de fichier illustr ici :

    # Selenium test configurationselenium.host=testserver.acme.comselenium.port=8080selenium.broswer=firefox

    Ces proprits sont passes Maven en tant quoptions de ligne de commande, comme montr ici :

    $ mvn verify -Dselenium.host=testserver.acme.com ...

    Le champ JVM Options vous permet de spcifier des options standards de la machine virtuelle Java pourvotre tche de build. Donc, si votre processus de build est particulirement consommateur de mmoire,vous pourriez ajouter plus despace pour la heap avec loption -Xmx (par exemple, -Xmx512m peutspcifier la taille maximum de la heap 512 Mo).

    La dernire option que vous pouvez configurer est un dpt priv Maven pour cette tche de build.Normalement, Maven utilisera le dpt Maven par dfaut (usuellement le dossier .m2/repositorydans le rpertoire personnel de lutilisateur). Parfois, cela peut mener des interfrences entre tchesde build, ou utiliser des versions snapshot inconsistantes dun build un autre. Pour tre sr que votre

  • 111

    build est lanc dans des conditions de laboratoire, vous pouvez activer cette option. Votre tche de buildaura son propre dpt priv, rserv pour son utilisation exclusive. Sur le plan ngatif, la premire foisque la tche de build lancera un build, cela prendra du temps pour tlcharger tous les artefacts Maven,et les dpts privs peuvent prendre beaucoup de place. Cependant, cest la meilleure faon de garantirque votre build est lanc dans un environnement vraiment isol.

    5.6.2. Les tapes de build Ant

    Les tches de build Freestyle fonctionnent galement biens avec Ant. Apache Ant9 est un outil descripting de build Java largement utilis et bien connu. En effet, un nombre important de projets Javasont lis des scripts de build Ant.

    Ant nest pas seulement utilis comme un outil de build principal mme si votre projet utilise Maven,vous pouvez recourir lappel de scripts Ant pour faire des tches spcifiques. Il y a des librairies Antdisponibles pour beaucoup doutils de dveloppement et des tches bas niveau, comme utiliser SSH, outravailler avec des serveurs dapplication propritaires.

    Dans da forme la plus basique, configurer une tape de build Ant est trs simple, en effet, il vous suffitde fournir la version de Ant que vous souhaitez utiliser et le nom de la target que vous voulez invoquer.Dans la Figure 5.27, Configurer une tape de build Ant, par exemple, nous invoquons un script Antpour dmarrer un script de test JMeter.

    Figure 5.27. Configurer une tape de build Ant

    Comme dans une tape de build Maven, le bouton Avanc vous fournit plus doptions dtailles,comme spcifier un script de build different, ou un script de build dans un rpertoire diffrent (celuipar dfaut sera build.xml dans le rpertoire racine). Vous pouvez aussi spcifier des proprits et desoptions de la JVM, comme vous pouvez le faire pour Maven.

    5.6.3. Excuter une commande Batch Shell ou Windows

    Occasionnellement, vous pouvez avoir besoin dexcuter une commande directement au niveau dusystme dexploitation. Certains processus de build anciens sont lis des scripts spcifiques lOS, par

    9 http://ant.apache.org/

    http://ant.apache.org/http://ant.apache.org/

  • 112

    exemple. Dans dautres cas, vous pourriez avoir besoin deffectuer un oprateur bas niveau qui seraitplus facilement faite avec une commande au niveau OS.

    Vous pouvez faire ceci avec Jenkins avec une commande Excuter un script shell (pour Unix)ou Excuter une ligne de commande batch Windows (pour Windows). Par exemple, dans laFigure 5.28, Configurer une tape Excuter un script Shell, nous avons ajout une tape pour excuterla commande Unix ls.

    Figure 5.28. Configurer une tape Excuter un script Shell

    La sortie de ltape de build est montre ici :

    [workspace] $ /bin/sh -xe /var/folders/.../jenkins2542160238803334344.s+ ls -altotal 64drwxr-xr-x 14 johnsmart staff 476 30 Oct 15:21 .drwxr-xr-x 9 johnsmart staff 306 30 Oct 15:21 ..-rw-r--r--@ 1 johnsmart staff 294 22 Sep 01:40 .checkstyle-rw-r--r--@ 1 johnsmart staff 651 22 Sep 01:40 .classpath-rw-r--r--@ 1 johnsmart staff 947 22 Sep 01:40 .projectdrwxr-xr-x 5 johnsmart staff 170 22 Sep 01:40 .settings-rw-r--r--@ 1 johnsmart staff 437 22 Sep 01:40 .springBeansdrwxr-xr-x 9 johnsmart staff 306 30 Oct 15:21 .svn-rw-r--r--@ 1 johnsmart staff 1228 22 Sep 01:40 build.xml-rw-r--r--@ 1 johnsmart staff 50 22 Sep 01:40 infinitest.filters-rw-r--r-- 1 johnsmart staff 6112 30 Oct 15:21 pom.xmldrwxr-xr-x 5 johnsmart staff 170 22 Sep 01:40 srcdrwxr-xr-x 3 johnsmart staff 102 22 Sep 01:40 targetdrwxr-xr-x 5 johnsmart staff 170 22 Sep 01:40 tools

    Vous pouvez soit excuter une commande spcifique lOS (ex : ls), soit stocker un script pluscompliqu comme un fichier dans votre gestionnaire de contrle de version, et excuter ce script. Sivous excutez un script, vous navez juste qu faire rfrence au nom de votre script relativement parrapport au rpertoire de travail.

    Les scripts Shell sont excuts en utilisant loption -ex les commandes sont affiches dans la console,comme si ctait la sortie. Si nimporte laquelle des commandes excutes retourne une valeur diffrentede zro, le build chouera.

    Lorsque Jenkins excute un script, il spcifie un nombre en tant que variable denvironnement quevous pouvez utiliser lintrieur de votre script. Nous discutons de ces variables plus en dtail dansle prochaine section.

  • 113

    En ralit, il y a beaucoup de bonnes raisons pour lesquelles vous devriez viter dutiliser des scriptsde niveau OS dans vos tches de build si vous pouvez les viter. En particulier, il rend votre tche debuild au meilleur des cas, spcifique lOS, et dans le pire dpendant de la configuration prcise de lamachine. Une alternative plus portable pour excuter des scripts spcifiques lOS est dcrire un scriptquivalent dans un langage de script plus portable, comme Groovy ou Gant.

    5.6.4. Utiliser les variables denvironnement Jenkins dans vos builds

    Une astuce utile qui peut tre utilise dans pratiquement nimporte quelle tape de build est dobtenirdes informations de la part de Jenkins sur la tche de build courante. En ralit, lorsque Jenkins dmarreune tape de build, il met disposition les variables denvironnement suivantes dans le script de build :

    BUILD_NUMBER Le numro du build courant, comme 153.

    BUILD_ID Un horodatage pour identifier le build courant, sous le format YYYY-MM-DD_hh-mm-ss.

    JOB_NAME Le nom du job, comme game-of-life.

    BUILD_TAG Un moyen commode didentifier la tche de build courante, sousla forme jenkins-${JOB_NAME}-${BUILD_NUMBER} (ex : jenkins-game-of-life-2010-10-30_23-59-59).

    EXECUTOR_NUMBER Un nombre identifiant lexcuteur ayant dmarr cette construction parmi les excuteurs sur lamme machine. Cest le nombre que vous voyez dans Etat du lanceur de construction , lexception que ce nombre commence de 0, pas 1.

    NODE_NAME Le nom de lesclave si ce build est en train dtre lanc sur un esclave, ou "" si le build est entrain dtre lanc sur le matre.

    NODE_LABELS La liste des libells associs au nud sur lequel le build est dmarr.

    JAVA_HOME Si votre tche est configure pour utiliser une version spcifique de JDK, cette variable contient lavaleur du JAVA_HOME correspondant au JDK spcifi. Lorsque cette variable est fixe, la variablePATH est aussi mise jour pour avoir $JAVA_HOME/bin.

    WORKSPACE Le chemin absolu du rpertoire de travail.

  • 114

    HUDSON_URL LURL complte du serveur Jenkins, par exemple http://ci.acme.com:8080/jenkins/.

    JOB_URL LURL complte pour cette tche de build, par exemple http://ci.acme.com:8080/jenkins/game-of-life.

    BUILD_URL LURL complte de ce build, par exemple http://ci.acme.com:8080/jenkins/game-of-life/20.

    SVN_REVISION Pour les projets bass sur Subversion, cette variable contient le numro de la rvision courante.

    CVS_BRANCH Pour les projets bass sur CVS, cette variable contient la branche du module. Si CVS est configurpour consulter le trunk, cette variable denvironnement ne sera pas spcifie.

    Ces variables sont faciles utiliser. Dans un script Ant, vous pouvez y accder avec le tag comme montr ici :

    Dans Maven, vous pouvez accder au variables soit de la mme manire (en utilisant le prefix env. ),soit directement en utilisant la variable denvironnement Jenkins. Par exemple, dans le fichier pom.xml,lURL du projet pointera sur la tche de build Jenkins qui a lanc le build mvn site :

    ... com.wakaleo.gameoflife gameoflife-core 0.0.55-SNAPSHOT gameoflife-core ${JOB_URL}

    Alternativement, si vous construises une application web, vous pouvez aussi utiliser maven-war-plugin pour insrer le numro de la tche de build dans le manifest de lapplication web, ex :

    ... ... maven-war-plugin

  • 115

    true Continuous Integration with Hudson (French Content) 0.0.4-SNAPSHOT ${BUILD_TAG} ... ...

    Cela produire un fichier MANIFEST.MF avec les lignes suivantes :

    Manifest-Version: 1.0Archiver-Version: Plexus ArchiverCreated-By: Apache MavenBuilt-By: johnsmartBuild-Jdk: 1.6.0_22Jenkins-Build-Number: 63Jenkins-Project: game-of-lifeJenkins-Version: 1.382Implementation-Version: jenkins-game-of-life-63Specification-Title: gameoflife-webSpecification-Version: 0.0.55-SNAPSHOT

    Dans un script Groovy, elles peuvent tre accder via la mthode System.getenv() :

    def env = System.getenv()env.each { println it}

    ou :

    def env = System.getenv()println env['BUILD_NUMBER']

    5.6.5. Excuter des scripts Groovy

    Groovy nest pas seulement un langage dynamique populaire de la JVM, cest aussi un langage quiconvient pour le scripting de bas niveau. Le plugin Groovy10 de Jenkins vous permet dexcuter des

    10 http://wiki.jenkins-ci.org//display/HUDSON/Groovy+Plugin

    http://wiki.jenkins-ci.org//display/HUDSON/Groovy+Pluginhttp://wiki.jenkins-ci.org//display/HUDSON/Groovy+Plugin

  • 116

    commandes Groovy arbitraires, ou invoquer des scripts Groovy, dans le cadre de votre processus debuild.

    Une fois que vous avez install le plugin Groovy avec la manire habituelle, vous aurez besoin dajouterune rfrence de votre installation Groovy dans la page de configuration du systme (voir la figureFigure 5.29, Ajouter une installation Groovy Jenkins).

    Figure 5.29. Ajouter une installation Groovy Jenkins

    Maintenant, vous pouvez ajouter du script Groovy dans votre tche de build. Lorsque vous cliquez surAjouter une tape de build, vous verrez deux nouvelles entres dans le menu droulant : Excuterun script Groovy et Excuter un script Groovy Systme . La premire option est gnralementcelle que vous souhaitez cela excutera simplement un script Groovy dans une JVM spare, commesi vous linvoquiez depuis la ligne de commande. La deuxime option lance des commandes Groovydepuis la JVM de Jenkins, avec un accs interne complet Jenkins, et est principalement utilis pourmanipuler les tches de build de Jenkins ou le processus de build lui-mme. Cest un sujet plus avancdont nous discuterons plus loin dans ce livre.

    Une tape de build Groovy peut prendre une forme sur deux. Pour les cas simples, vous pouvezjuste ajouter un petit bout de Groovy, comme montr dans la Figure 5.30, Lancer des commandesGroovy dans le cadre dune tche de build. Pour les cas plus complexes ou compliqus, vous pouvezprobablement crire un script Groovy et le placer sous un systme de contrle de version. Une fois quevotre script est en sret dans votre SCM, vous pouvez le dmarrer en slectionnant loption Fichier descript Groovy et fournir le chemin de votre script (relatif au rpertoire de travail de la tche de build).

    Figure 5.30. Lancer des commandes Groovy dans le cadre dune tche de build

  • 117

    Dans la Figure 5.31, Lancer des scripts Groovy dans le cadre dune tche de build, vous pouvezvoir un exemple lgrement plus compliqu. Ici nous lanons un script Groovy appel run-fitness-tests.groovy, qui peut tre trouv dans le rpertoire scripts. Ce script prend des suites de test pourtre excuts comme ses paramtres nous pouvons les mettre dans le champ Paramtres Groovy.Sinon vous pouvez aussi fournir des proprits en ligne de commande dans le champ Proprits cestsimplement un moyen plus pratique dutiliser loption -D en ligne de commande pour passer des valeursde proprits au script Groovy.

    Figure 5.31. Lancer des scripts Groovy dans le cadre dune tche de build

    5.6.6. Construire des projets dans dautres langages

    Jenkins est un outil flexible, il peut tre utilis avec beaucoup plus de de langage que Java et Groovy.Par exemple, Jenkins fonctionne aussi trs bien avec Grails, .Net, Ruby, Python et PHP, juste pouren nommer quelques uns. En utilisant dautres langages, vous aurez gnralement besoin dinstallerun plugin supportant votre langage favori, qui ajoutera un nouveau type dtape de build pour celangage.Nous regarderons dautres exemples dans la section Section 5.10, Utiliser Jenkins avecdautres langages.

    5.7. Les actions la suite du buildUne fois quun build est termin, il y a toujours des petites choses voir aprs. Vous pourriez avoirbesoin darchiver certains artefacts gnrs, faire des rapports sur les rsultats des tests, et notifierdes personnes sur les rsultats. Dans cette section, nous allons regarder certaines des tches les pluscourantes que vous aurez besoin de configurer aprs que le build est effectu.

    5.7.1. Rapport sur les rsultats de tests

    L'une des exigences les plus videntes sur une tche de build est de faire des rapports sur les rsultats destests. Non seulement sil y a des checs aux tests, mais aussi combien de tests sont excuts, en combien

  • 118

    de temps, et ainsi de suite. Dans le monde Java, JUnit est la librairie de test la plus couramment utilise,et le format XML JUnit pour les rsultats de test est trs utilis et aussi bien compris par les autres outils.

    Jenkins fournit un grand support pour les rapports de test. Dans une tche de build freestyle, vous devezcocher loption Publier le rapport des rsultats de tests JUnit , et fournir un chemin vers vos fichiers derapport JUnit (voir Figure 5.32, Rapport sur les rsultats de tests). Vous pouvez utiliser une expressiongnrique (comme **/target/surefire-reports/*.xml dans un projet Maven) pour inclure lesrapports JUnit depuis un grand nombre de rpertoires diffrents Jenkins agrgera les rsultats dansun seul rapport.

    Figure 5.32. Rapport sur les rsultats de tests

    Nous regarderons les tests automatiss plus en dtail dans le chapitre Chapter 6, Tests automatiss.

    5.7.2. Archiver les rsultats de build

    A quelques exceptions prs, le but principal dune tche de build est gnralement de construire quelquechose. Dans Jenkins, nous appelons cette chose un artefact. Un artefact pourrait tre un excutablebinaire (un fichier JAR ou WAR pour un projet Java, par exemple), ou certains autres livrables lis,comme de la documentation ou du code source. Une tche de build peut stocker un ou plusieurs diffrentsartefacts, gardant uniquement la dernire copie ou chaque artefact tous les builds.

    Configurer Jenkins pour stocker vos artefacts est simple cochez la case cocher Archiver lesartefacts dans les Actions la suite de build, et spcifier quels artefacts vous voulez stocker (voir lafigure Figure 5.33, Configurer les artefacts de builds).

    Figure 5.33. Configurer les artefacts de builds

  • 119

    Dans le champ Fichiers archiver , vous pouvez spcifier les chemins complets des fichiers quevous souhaitez archiver (relatif au rpertoire de travail de la tche de build), ou, utiliser un caractregnrique (ex. : **/*.jar, pour tous les fichiers JAR, nimporte o dans le rpertoire de travail). Lundes avantages dutiliser des caractres gnriques est quil permet de rendre votre build moins dpendantde votre configuration de gestion de version. Par exemple, si vous utilisez Subversion (voir la sectionSection 5.4, Configurer la Gestion du Code Source), Jenkins va parcourir votre projet directementdepuis le rpertoire de travail, ou depuis un sous-rpertoire, en fonction de votre configuration. Si vousutilisez un caractre gnrique comme **/target/*.war, Jenkins trouvera le fichier indpendammentdu rpertoire o est positionn le projet.

    Comme dhabitude, le bouton Avanc donne accs quelques options supplmentaires. Si vousutilisez un caractre gnrique pour trouver vos artefacts, vous pourriez avoir besoin dexclure certainsrpertoires dans la recherche. Vous pouvez faire ceci en remplissant le champ Exclusions. Vous entrezun modle de nom de fichier que vous ne souhaitez pas archiver, mme sils seraient normalement incluspar le champ "Fichiers archiver".

    Les artefacts archivs peuvent prendre beaucoup de place sur le disque, en particulier si les builds sontfrquents. Pour cette raison, vous pouvez vouloir garder uniquement le dernier en succs. Pour fairececi, il suffit de cocher loption Supprime tous les artefacts, l'exception du dernier artefact stableou construit avec succs, afin de gagner de l'espace disque . Jenkins gardera les artefacts des derniersbuilds stables (sil y en a). Il gardera aussi les artefacts du dernier build instable construit juste aprs unbuild stable (sil y a), et galement du dernier build en chec qui est arriv.

    Les artefacts de build archivs apparaissent sur la page des rsultats de build (voir la figure Figure 5.34,Les artefacts de build sont affichs sur la page de rsultat dun build et la page daccueil dun job).Les artefacts de build les plus rcents sont aussi affichs dans la page daccueil dun job.

    Figure 5.34. Les artefacts de build sont affichs sur la page de rsultat dun build et la page daccueildun job

    Vous pouvez aussi utiliser les URLs permanentes pour accder aux artefacts de build les plus rcents. Ils'agit d'une excellente faon de rutiliser les derniers artefacts de vos builds, que ce soit depuis des tches

  • 120

    de build Jenkins ou depuis des scripts externes, par exemple. Trois URLs sont disponibles : dernier buildstable, dernier build en succs et dernier build construit.

    Avant que nous regardions les URLs, nous devrions discuter du concept de builds stables et en succs.

    Un build est en succs lorsque la compilation nest pas signale en erreur.

    Un build est considr stable sil a t construit avec succs, et quaucun diteur ne la signal commeinstable. Par exemple, dpendamment de votre configuration de projet, des checs de tests unitaires,une couverture de code insuffisante, ou dautres problmes de qualit de code, peuvent provoquer lamise ltat instable dun build. Donc un build stable est toujours en succs, mais linverse nest pasncessairement vrai un build peut tre en succs sans tre ncessairement stable.

    Un build complet est simplement un build qui a fini, peu importe son rsultat. A noter que ltapedarchivage aura lieu quel que soit le rsultat de la construction.

    Le format des URLs dartefact est intuitif, et prend la forme suivante :

    Dernier build stable/job//lastStableBuild/artifact/

    Dernier build en succs/job//lastSuccessfulBuild/artifact/

    Dernier build complet/job//lastCompletedBuild/artifact/

    Cest mieux illustr par quelques exemples. Supposez que votre serveur Jenkins est dmarr sur http://myserver:8080, votre job de construction se nomme game-of-life, et vous stockez un fichier appelgameoflife.war, qui est dans le rpertoire target de votre rpertoire de travail. Les URLs pour cetartefact seraient les suivantes :

    Dernier build stablehttp://myserver:8080/job/gameoflife/lastStableBuild/artifact/target/

    gameoflife.war

    Dernier build en succshttp://myserver:8080/job/gameoflife/lastSuccessfulBuild/artifact/

    target/gameoflife.war

    Dernier build complethttp://myserver:8080/job/gameoflife/lastCompletedBuild/artifact/

    target/gameoflife.war

  • 121

    Les artefacts peuvent ne pas juste tre des excutables binaires. Imaginez, par exemple, que votreprocessus de build implique de dployer automatiquement tous les builds sur un server de test. Pourplus de commodits, vous voulez garder une copie du code source exact associ chaque fichier WARdploy. Une manire de faire cela serait de gnrer le code source associ un build, et darchiver la fois ce fichier le fichier WAR. Nous pouvons faire ceci en gnrant le fichier JAR contenant le codesource de lapplication (par exemple, en utilisant le Maven Source Plugin pour un projet Maven), etensuite inclure celui-ci dans la liste des artefacts stocker (voir la figure Figure 5.35, Archiver le codesource et un paquet binaire).

    Figure 5.35. Archiver le code source et un paquet binaire

    Bien sr, cet exemple est un peu acadmique : il serait probablement plus simple de juste utiliser lenumro de rvision pour ce build (qui est affich sur la page de rsultat du build) pour retrouver le codesource depuis votre systme de gestion de version. Mais vous voyez lide.

    Notez que si vous utiliser un gestionnaire de dpt dentreprise comme Nexus ou Artifcatory pourstocker vos artefacts binaires, vous nauriez pas besoin de les garder sur le serveur Jenkins. Vouspourriez simplement prfrer dployer automatiquement vos artefacts dans votre gestionnaire de dptdentreprise dans le cadre de la construction de votre job, et de les y retrouver lorsque cest ncessaire.

  • 122

    5.7.3. Notifications

    Le but dun serveur IC est de permettre dinformer les gens lorsquun build est rompu. Dans Jenkins,cela se passe dans la rubrique Notification.

    Jenkins fournit le support des notifications par email. Vous pouvez lactiver en cochant la case cocher Notifier par email dans les actions la suite du build (voir Figure 5.36, Notification par email).Ensuite, entrez les adresses emails des membres de lquipe qui doivent savoir lorsquun build estrompu. Lorsquun build est rompu, Jenkins enverra un message amical aux utilisateurs dans la listecontenant un lien vers les builds rompus.

    Figure 5.36. Notification par email

    Vous pouvez aussi opter pour envoyer un email spar lutilisateur dont le commit (probablement)rompu le build. Pour que cela fonctionne, vous devez avoir activ la scurit dans votre serveur Jenkins(voir la figure Chapter 7, Scuriser Jenkins).

    Normalement, Jenkins enverra une notification par email chaque fois quun build chouera (parexemple, cause dune erreur de compilation). Il enverra aussi une notification lorsque le build devientinstable pour la premire fois (par exemple, sil y a des tests en checs). A moins que vous le configurerpour faire a, Jenkins nenverra pas demails pour chaque build instable, mais uniquement pour lepremier.

    Finalement, Jenkins enverra un message lorsque un build prcdemment en chec ou instable russi,pour permettre dinformer tout le monde que le problme a t rsolu.

    5.7.4. Construire dautres projets

    Vous pouvez aussi dmarrer dautres constructions de job dans les actions la suite du build, en utilisantloption Construire dautres projets (projets en aval) . Ceci est utile si vous souhaitez organiser votreprocessus de build en plusieurs, plus petites tapes, la place dune seul longue construction de job. Ilsuffit de lister les projets que vous souhaitez dmarrer aprs celui-ci. Normalement, ces projets serontdclenchs uniquement si le build est stable, mais vous pouvez optionnellement dclencher dautreconstruction de job mme si le build courant est instable. Cela peut tre utile, par exemple, si vous voulezdmarrer une construction de job effectuant des rapports sur des mesures de qualit de code aprs uneconstruction de job principal du projet, mme sil y a des tests en checs dans le build principal.

  • 123

    5.8. Dmarrer votre nouvelle tche de buildMaintenant, tout ce que vous devez faire est sauver votre nouveau job de construction. Vous pouvezalors dclencher le premier build manuellement, ou juste en attendant que celui-ci se dclenche de lui-mme. Une fois que le build est termin, vous pouvez cliquer sur le numro du build pour voir lesrsultats de votre travail.

    5.9. Travailler avec des tches de build MavenDans cette section, nous allons avoir un aperu de lautre type de tche de build communment utilis :les tches de build Maven 2/3.

    Les tches de build Maven sont spcifiquement adaptes pour les builds Maven 2 et Maven 3. Crer unetche de build Maven ncessite considrablement moins de travail que son quivalent en tche de buildFreestyle. Les tches de build Maven supportent les fonctionnalits avances lies Maven comme lesbuilds incrmentaux sur les projets multi-modules et les builds dclenchs par des changements sur desdpendances en snapshot, et permettent une configuration et des rapports plus simples.

    Cependant, il y a un hic : les tches de build Maven 2/3 sont moins flexibles que les tches de buildFreestyle, et ne supportent pas des tapes de build multiples dans la mme tche de build. Certainsutilisateurs ont aussi signals que les gros projets Maven tendent tre plus lents et utilisent plusde mmoire lorsquils sont configurs avec des tches de build Maven au lieu de leur quivalent enFreestyle.

    Dans cette section, nous allons tudier pour savoir comment configurer des builds Maven 2/3, quandles utiliser, ainsi que leurs avantages et inconvnients.

    Pour crer une nouvelle tche de build, il suffit de choisir loption Construire un projet Maven 2/3 dans la page Nouveau Job (voir Figure 5.37, Crer une nouvelle tche de build Maven).

    Figure 5.37. Crer une nouvelle tche de build Maven

  • 124

    5.9.1. Construire ds lors quune dpendance SNAPSHOT estconstruite

    A premire vue, lcran de configuration dune tche de build Maven 2/3 est trs similaire celle quenous avions vu pour les tches de build dans la section prcdente. La premire diffrence que vouspouvez noter est dans la section Dclencheurs de build. Dans cette section, une option supplmentaireest disponible Lance un build chaque fois qu'une dpendance SNAPSHOT est construite . Sivous slectionnez cette option, Jenkins examinera votre fichier pom.xml (ou les fichiers)pour regardersi aucunes dpendances SNAPSHOT sont en train dtre construire par dautres tches de build. Sinimporte laquelle des tches de build met jour une dpendance SNAPSHOT que votre projet utilise,Jenkins construira aussi votre projet.

    Typiquement dans Maven, les dpendances SNAPSHOT sont utilises pour partager la toute dernireversion dune librairie avec dautres projets de la mme quipe. Comme elles sont par dfinitioninstables, ce nest pas une pratique recommande de lier des dpendances SNAPSHOT avec dautresquipes ou depuis des sources externes.

    Par exemple, imaginiez que vous tes en train de travailler sur une nouvelle application web game-of-life. Vous utilisez Maven pour votre projet, donc vous pouvez utiliser une tche de build Mavendans Jenkins. Votre quipe travaille aussi sur une librairie rutilisable appele cooltools. Comme cesdeux projets sont dvelopps par la mme quipe, vous utilisez certaines des dernires fonctionnalitsde cooltools dans lapplication game-of-life. vous avez une dpendance SNAPSHOT dans la section du fichier pom.xml de game-of-life :

    com.acme.common cooltools 0.0.1-SNAPSHOT test ...

    Dans votre serveur Jenkins, vous avez configur des tches de build Maven la fois pour lapplicationcooltools et game-of-life. Comme votre projet game-of-life a besoin de la dernire version SNAPSHOTde cooltools, vous cochez loption Lance un build chaque fois qu'une dpendance SNAPSHOT estconstruite . Comme cela, ds lors que le projet cooltools est reconstruit, le projet game-of-life seraaussi automatiquement reconstruit.

    5.9.2. Configurer un build Maven

    La prochaine section o vous noterez un changement est la section Build. Dans une tche de buildMaven, la section Build est entirement dvou au lancement dun seul goal Maven (voir la figureFigure 5.38, Spcifier les goals Maven). Dans cette section, vous spcifiez la version de Maven quevous voulez excuter (rappelez-vous, en tant que job Maven, cela ne fonctionnera quavec Maven), la

  • 125

    position du fichier pom.xml, et le goal Maven (ou les goals) invoquer. Vous pouvez aussi ajouternimporte quelles options de ligne de commande que vous voulez ici.

    Figure 5.38. Spcifier les goals Maven

    Dans beaucoup de cas, cest tout ce que vous aurez besoin de faire pour configurer une tche debuild Maven. Cependant, si vous cliques sur le bouton Avanc , vous pouvez cocher certainesfonctionnalits avances (Figure 5.39, Les tches de build Maven les options avances).

    Figure 5.39. Les tches de build Maven les options avances

    Loption de build incrmental est trs pratique pour les grands builds multi modules Maven. Sivous cochez cette option, lorsquun changement est effectu sur lun des modules du projet, Jenkinsreconstruira uniquement ce module et les modules qui utilisent le module modifi. Il fait cette magieen utilisant certaines nouvelles fonctionnalits introduites par Maven 2.1 (donc cela ne fonctionnerapas si vous utilisez Maven 2.0.x). Jenkins dtecte quels modules a t modifis, et utilise loption -pl(--project-list) pour construire uniquement les modules mis jour, et loption -amd (--also-make-dependents) pour construire aussi les modules qui utilises les modules mis jour. Si rien nat modifi dans le code source, tous les modules sont construits.

    Par dfault, Jenkins archivera tous les artefacts gnrs par une tche de build Maven. Cela peut treutile certains moments, mais cela peut aussi tre trs coteux en place sur le disque. Si vous souhaitezdsactiver cette option, il suffit de cocher loption Dsactive larchivage automatique des artefacts .

  • 126

    Alternativement, vous pouvez toujours limiter les artefacts stocks en utilisant loption Supprimer lesanciens builds tout en haut de la page de configuration.

    Loption Construire les modules en parallle informe Jenkins quil peut dmarrer chaque moduleindividuellement en parallle comme un build spar. En thorie, cela pourrait rendre un peu plus rapideles constructions. En pratique, cela fonctionnera rellement si vos modules sont totalement indpendants(si vous nutilisez pas dagrgation), ce qui est rarement le cas. Si vous pensez que construire vosmodules en parallle peut rellement acclrer votre projet multi module, vous pouvez avoir enviedutiliser un build freestyle avec Maven 3 et sa nouvelle fonctionnalit de construction parallle.

    Une autre option utile est Utiliser une repository Maven priv . Normalement, lorsque Jenkinsdmarre Maven, il se comportera exactement de la mme manire que Maven en ligne de commande : ilstockera les artefacts et retrouvera les artefacts depuis le dpt Maven local (dans ~/.m2/repositorysi vous ne lavez pas configur dans le fichier settings.xml). Ceci est efficient en terme despacedisque, mais pas souvent idal pour des constructions en IC. En effet, si plusieurs tches de build sonten construction avec les mmes artefacts en SNAPSHOT, les constructions peuvent finir par se gnerles unes avec les autres.

    Lorsque cette option est slectionne, Jenkins demande Maven dutiliser$WORKSPACE/.repositorycomme dpt local Maven. Cela signifie que chaque job aura sonpropre dpt Maven isol pour lui tout seul. Cela rgle les problmes ci-dessus, au dtriment de laconsommation d'espace disque supplmentaire.

    Avec cette option, Maven utilisera un dpt Maven ddi pour cette tche de build, situ dans lerpertoire $WORKSPACE/.repository . Ceci prend plous despace disque, mais garantie une meilleurisolation pour nos tches de build.

    Une autre approche pour ce problme est de redfinir lemplacement par dfaut du dpt en utilisant laproprit maven.repo.local, comme montr ici :

    $ mvn install -Dmaven.repo.local=~/.m2/staging-repository

    Cette approche lavantage dtre capable de partager un dpt entre certaines tches de builds, ce quiest utile si vous souhaitez faire une srie de builds lis. Cela fonctionnera aussi avec des tches Freestyle.

    5.9.3. Les actions la suite du build

    Les actions la suite du build dans une tche de build Maven est considrablement simple configurercompar une tche Freestyle. Cest simplement parce que, puisque cest un build Maven, Jenkins saito chercher un certain nombre de sortie du build. Les artefacts, rapports de test, Javadoc, en ainsi desuite, sont tous gnrs dans les rpertoires standards, ce qui signifie que vous navez pas besoin deprciser Jenkins o trouver ces lments. Donc Jenkins trouvera, et effectuera automatiquement desrapports sur des rsultats de test JUnit, par exemple. Plus loin dans ce livre, nous verrons comment lesprojets Maven simplifient aussi la configuration de beaucoup doutils de mesure de qualit de code etde rapports.

  • 127

    Beaucoup des autres actions la suite du build sont similaires ceux que nous avons vus dans une tchede build Freestyle.

    5.9.4. Dployer vers un gestionnaire de dpt dentreprise

    Une option supplmentaire qui apparait dans les tches de build Maven est la capacit de dployervos artefacts vers un dpt Maven (voir la figure Figure 5.40, Dployer des artefacts vers un dptMaven). Un gestionnaire de dpt dentreprise est un serveur qui agit la fois comme un proxy/cachepour des artefacts publics de Maven, et comme un serveur de stockage centralis pour vos propresartefacts internes. Des gestionnaires de dpt dentreprise open source comme Nexus (de Sonatype) etArtifactory (de JFrog) fournissent des fonctionnalits de maintenance et dadministration puissantes quipermettent de configurer et maintenir vos dpts Maven trs simplement. Ces deux produits ont desversions commerciales, avec des fonctionnalits additionnelles visant construire des infrastructuresplus sophistiques ou haut de gamme.

    Lavantage davoir Jenkins qui dploie vos artefacts ( loppos de simplement faire mvn deploy) estque, si vous avez un build Maven multi module, les artefacts seront dploys uniquement lorsque lebuild entier a fini avec succs. Par exemple, supposons que vous ayez un projet Maven multi moduleavec cinq modules. Si vous lancez mvn deploy, et que le build choue aprs trois modules, les deuxpremiers modules vont avoir t dploys vers votre dpt, mais pas les trois premiers, qui laissent votredpt dans un tat instable. Faire en sorte que Jenkins faire le dploiement assure que les artefacts sontdploys comme un groupe une fois que le build a termin avec succs.

    Figure 5.40. Dployer des artefacts vers un dpt Maven

    Pour faire cela, il suffit de cocher loption Dployer les artefacts dans le repository Maven dansles actions la suite du build. Vous aurez besoin de spcifier lURL du dpt sur lequel vous voulezdployer. Il faut que cela soit lURL complte vers le dpt (ex : http://nexus.acme.com/nexus/content/repositories/snapshots, et pas juste http://nexus.acme.com/nexus)

    La plupart des dpts ont besoin de vous authentifier avant de vous laisser dployer des artefacts. Lamanire standard de Maven pour faire cela est de placer dans votre fichier settings.xmllocal, comme montr ici :

  • 128

    nexus-snapshots scott tiger nexus-releases scott tiger

    Pour les personnes qui souhaitent plus de scurit, vous pouvez aussi encrypter ces mots de passe sibesoin est.

    Ensuite, entrez lidentifiant correspondant dans le champ Identifiant du repository de Jenkins. Jenkinssera alors capable de retrouver le bon nom dutilisateur et mot de passe, et de dployer vos artefacts. Unefois que le build sera termin, vos artefacts devraient tre disponibles sur votre dpt dentreprise Maven(voir la figure Figure 5.41, Aprs dploiement, lartefact devrait tre disponible sur votre gestionnairede dpt dentreprise).

    Figure 5.41. Aprs dploiement, lartefact devrait tre disponible sur votre gestionnaire de dptdentreprise

    En utilisant cette option, vous navez pas toujours besoin de dployer tout de suite vous pouveztoujours revenir en arrire et redployer des artefacts dune version prcdente. Il suffit de cliquer surle menu Redployer les artefacts gauche et spcifier lURL du dpt sur lequel vous voulezredployer votre artefact (voir la figure Figure 5.42, Redployer un artefact). Comme dans lexempleprcdent, le bouton Avanc vous permet de spcifier lidentifiant pour le tag dans votrefichier settings.xml local. Comme vous pourrez voir plus loin dans ce livre, vous pour aussi utiliser

  • 129

    ce dploiement dans le cadre dun processus de promotion de buid en configurant un dploiementautomatique vers un dpt diffrent lorsque certaines mtriques de qualit sont satisfaites, par exemple.

    Figure 5.42. Redployer un artefact

    Cette approche fonctionnera bien pour nimporte quel gestionnaire de dpt dentreprise. Cependant, sivous utilisez Artifactory, vous pourriez prfrer installer le plugin Artifactory11 de Jenkins, qui fournitune intgration bidirectionnelle vers le gestionnaire de dpt dentreprise Artifactory. Il fonctionne enenvoyant des informations supplmentaires au serveur Artifactory durant le dploiement, permettant auserveur davoir un lien vers le build qui a gnr un artefact donn. Une fois que vous avez install leplugin, vous pouvez lactiver dans votre tche de build Maven en cochant loption Deploy artifactsto Artifactory dans les actions la suite du build. Ensuite vous choisissez sur quel dpt votre projetdoit dployer dans une liste de dpt sur le serveur, avec le nom dutilisateur et le mot de passe requispour faire le dploiement (voir la figure Figure 5.43, Dployer vers Artifactory depuis Jenkins).

    Figure 5.43. Dployer vers Artifactory depuis Jenkins

    Votre tche de build dploiera automatiquement vers Artifactory. En supplment, un lien vers lartefactsur le serveur sera maintenant affich sur la page daccueil de la tche de build et la page de rsultat desbuilds (voir la figure Figure 5.44, Jenkins affiche un lien vers le dpt Artifactory correspondant).

    11 http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

    http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Pluginhttp://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

  • 130

    Figure 5.44. Jenkins affiche un lien vers le dpt Artifactory correspondant

    Ce lien vous emmne sur une page sur le serveur Artifactory contenant les artefacts dploys (voir lafigure Figure 5.45, Voir lartefact dploy sur Artifactory). Depuis cette page, il y a aussi un lien pourvous ramener vers la page du build qui a construit cet artefact.

    Figure 5.45. Voir lartefact dploy sur Artifactory

    5.9.5. Dployer vers des gestionnaires de dpt dentreprisecommerciales

    Un gestionnaire de dpt dentreprise est une partie essentielle de nimporte quelle infrastructure dedveloppement de logiciel bas sur Maven. Ils jouent aussi un rle cl pour les projets non bass surMaven utilisant des outils tels que Ivy ou Gradle, chacun deux tant lis aux dpts standards de Maven.

    Chacun des principaux gestionnaires de dpt dentreprise, Nexus and Artifactory, propose des versionsprofessionnelles qui fournissent des fonctionnalits supplmentaires avec Jenkins. Plus loin dans celivre, nous discuterons comment vous pouvez utiliser des fonctionnalits avances comme la gestionde release et de staging de Nexus Pro pour implmenter des stratgies sophistiques de promotionde build. Sur laspect dploiement, ldition commerciale dArtifactory (Artifactory Pro Power Pack)tend lintgration bidirectionnelle que nous avons vu plus tt. Lorsque vous voyez un artefact surle navigateur du dpt, un onglet Builds affiche les dtails sur le build Jenkins Jenkins qui a cr

  • 131

    lartefact, et un lien vers la page du build sur Jenkins (voir la figure Figure 5.46, Voir les artefactsdploys et le build Jenkins correspondant dans Artifactory). Artifactory assure galement le suivi desdpendances qui ont t utilises dans le build Jenkins, et vous alertera si vous essayez de les supprimerdepuis le dpt.

    Figure 5.46. Voir les artefacts dploys et le build Jenkins correspondant dans Artifactory

    5.9.6. Grer les modules

    Lorsque vous utilisez Maven, il est habituel de dcouper le projet en plusieurs modules. Les tches debuild Maven ont un connaissance intrinsque des projets multi modules, et ajoute un lment Modulesau menu qui vous permet dafficher la structure du projet dun coup dil (voir la figure Figure 5.47,Grer les modules dans une tche de build Maven).

    Figure 5.47. Grer les modules dans une tche de build Maven

  • 132

    Cliquer sur lun des modules vous permettra dafficher la page de build pour ce module. A partir dela, vous pouvez voir les rsultats dtaills des builds pour chaque module, dclencher un build pour unmodule isol, et si ncessaire, affiner la configuration dun module, surchargeant ainsi la configurationglobal du projet.

    5.9.7. Les tapes de build supplmentaires dans votre tche de buildMaven

    Par Par dfaut, une tche de build Maven ne permet quun seul goal Maven. Il y a des fois ou cest assezlimitatif, et vous voudriez ajouter des tapes supplmentaires avant ou aprs la build principal. Vouspouvez faire ceci avec le plugin M2 Extra Steps de Jenkins. Ce plugin vous permet dajouter des tapesde builds normales avant et aprs le goal Maven principal, vous donnant la flexibilit dune tche debuild Freestyle tout en gardant lavantage de la configuration dune tche de build Maven.

    Installez le plugin et allez dans la section Environnements de Build de votre tche de build. Cochezloption Configure M2 Extra Build Steps . Vous devriez pouvoir maintenant ajouter des tapes debuild qui seront ajoutes avant et/ou aprs que votre goal Maven principal soit excut (voir la figureFigure 5.48, Configurer des tapes de build Maven supplmentaires).

    Figure 5.48. Configurer des tapes de build Maven supplmentaires

    5.10. Utiliser Jenkins avec dautres langagesComme mentionn plus tt, Jenkins fournit un excellent support pour dautres langages. Dans cettesection, nous allons voir comment utiliser Jenkins avec certains des plus communment utiliss.

  • 133

    5.10.1. Construire des projets avec Grails

    Grails est un framework dapplication web dynamique open-source construit avec Groovy et beaucoupdautres frameworks Java open-source bien tablis tel que Spring ou Hibernate.

    Jenkins fournit un excellent support pour les builds Grails. Premirement, vous devez installer le pluginGrails12.Une fois que vous lavez install et redmarr Jenkins, vous devrez fournir au moins une versionde Grails pour Jenkins dans la section Grails de lcran de configuration du systme (voir la figureFigure 5.49, Ajouter une installation Grails Jenkins).

    Figure 5.49. Ajouter une installation Grails Jenkins

    Maintenant vous pouvez configurer une tche de build Freestyle pour construire un projet Grails. Leplugin Grails ajoute ltape de build Build with Grails , que vous pouvez utiliser pour construireun application Grails (voir la figure Figure 5.50, Configurer une tape de build Grails). Ici, vousfournissez la target Grails, ou les targets, que vous voulez excuter. A la diffrence de la ligne decommande, vous pouvez excuter plusieurs targets dans la mme ligne de commande. Cependant,si vous souhaitez passer des arguments sur une target particulier, vous devez placer la target et sesarguments entre guillement. Dans la Figure 5.50, Configurer une tape de build Grails, par exemple,nous lanons grails clean, suivi de grails test-app -unit -non-interactive. ur que celafonctionne correctement, il faut mettre les options de la seconde commande entre guillemet, ce qui nousdonne grails clean "test-app -unit -non-interactive".

    12 http://wiki.jenkins-ci.org/display/HUDSON/Grails+Plugin

    http://wiki.jenkins-ci.org/display/HUDSON/Grails+Pluginhttp://wiki.jenkins-ci.org/display/HUDSON/Grails+Pluginhttp://wiki.jenkins-ci.org/display/HUDSON/Grails+Plugin

  • 134

    Figure 5.50. Configurer une tape de build Grails

    Ltape de build Grails peut prendre beaucoup de paramtres optionnels. Par exemple, Grails estminutieux avec les versions si vous projet a t cr avec une version plus ancienne, Grails vousdemandera de la mettre jour. Pour jouer la scurit, par exemple, vous pourriez cocher la case cocherForge Upgrade, qui assure de lancer un grails upgrade --non-interactive avant de dmarrerles targets principales.

    Vous pouvez aussi configurer le port du serveur (utile si vous excutez des tests web), et nimporte quelautre proprit que vous voulez passer au build.

    5.10.2. Construire des projets avec Gradle

    Rdig par Ren Groeschke

    En comparaison des outils de build anciens Ant et Maven, Gradle13est un nouvel outil de build opensource pour la machine virtuel Java. Les scripts de build pour Gradle sont construits dans un DomainSpecific Langage (DSL) bas sur Groovy. Gradle implmente la convention avant la configuration,permet un accs direct aux tasks Ant, et utilise une gestion des dpendances dclarative comme MavenLa nature concise du scripting Groovy vous permet dcrire des scripts de build plus expressif avec trspeu de code, au prix de la perte du support dun IDE qui existe pour les outils tablis tel que Ant etMaven.

    13 http://gradle.org

    http://gradle.orghttp://gradle.org

  • 135

    Il y a deux manires diffrentes de lancer des builds Gradle avec Jenkins. Vous pouvez utiliser soit leplugin Gradle pour Jenkins soit la fonctionnalit denveloppement (wrapper) de Gradle.

    5.10.2.1. Le plugin Gradle de Jenkins

    Vous pouvez installer le plugin Gradle avec la faon habituel il suffit daller sur lcran dugestionnaire de plugin et de slectionner le plugin Gradle. Cliquez sur installer et redmarrez l'instancede Jenkins.

    Une fois que Jenkins a redmarr, il vous faut configurer vous nouveau plugin Gradle. Vous trouverezmaintenant une nouvelle section Gradle dans la page de configuration du systme. Ici, il vous faudraajouter une installation de Gradle que vous souhaitez utiliser. Le processus est similaire que pour lesautres installations doutil utilis. Premirement, cliquez sur le bouton Ajouter Gradle pour ajouter unenouvelle installation Gradle, et entrez un nom appropri (voir la figure Figure 5.51, Configurer leplugin Gradle). Si Gradle a dj t install sur votre serveur de build, vous pouvez pointer vers lerpertoire local de Gradle. Sinon, vous pouvez utiliser la fonctionnalit Installer automatiquement pour tlcharger une installation de Gradle, sous le forme dun fichier ZIP ou GZipped TAR, directement partir dune URL. Vous pouvez utiliser une URL publique (voir http://gradle.org/downloads.html), ouvous pourriez prfrer de mettre ces installations disponibles sur le serveur local uniquement.

    Figure 5.51. Configurer le plugin Gradle

    Vous utilisez typiquement des tches de build Freestyle pour configurer vos builds Gradle. Lorsquevous ajouter une tape de build a une tche de build Freestyle, vous aurez maintenant une nouvelleoption appele Invoque Gradle script , qui vous permet dajouter des options spcifiques de Gradle votre tche de build.

    Par exemple, voici un script Gradle trs simple. Cest un projet simple Java qui utilise une structurede rpertoire Maven et un gestionnaire de dpt Maven. Il y a une tche paramtrable, appeleuploadArchives, pour dployer larchive gnre vers un gestionnaire local de dpt dentreprise :

    apply plugin:'java'apply plugin:'maven'

    http://gradle.org/downloads.html

  • 136

    version='1.0-SNAPSHOT'group = "org.acme"

    repositories{ mavenCentral() mavenRepo urls: 'http://build.server/nexus/content/repositories/public'}

    dependencies{ testCompile "junit:junit:4.8.2"}

    uploadArchives { repositories.mavenDeployer { configuration = configurations.archives repository(url: "http://build.server/nexus/content/repositories/snapshots") { authentication(userName: "admin", password: "password") } }}

    Dans la Figure 5.52, Configurer une tche de build Gradle, nous utilisons linstance Gradle-0.9RC2 qui vient dtre configure pour dmarrer un build Gradle. Dans ce cas, nous souhaitons dmarrer destests JUnit et tlcharger les artefacts de build vers notre dpt local Maven. De plus, nous configuronsnotre tche pour collecter les rsultats de test depuis **/build/test-results, le rpertoire par dfautstockant les rsultats de test avec Gradle.

    5.10.2.2. Les builds incrmentaux

    Lorsquon lance une tche de build Gradle avec des sources non modifies, Gradle lance ses buildsincrmentaux. Si la sortie dune tche Gradle est toujours disponible et que les sources nont pas changdepuis le dernier build, Gradle est capable de sauter lexcution de la tche et de la marquer comme jour. Cette fonctionnalit de build incrmental peut considrable diminuer le temps dune tche de build.

    Si Gradle value quune tche de test est jour, mme lexcution de vos tests unitaires et saute. Celapeut poser des problmes lorsque vous lancer votre build Gradle avec Jenkins. Dans notre tche de buildsimple ci-dessus, nous avons configur une action la suite du build pour publier les rapports JUnitde votre build. Si la tche de test est saute par Gradle, Jenkins marquera la tche en erreur avec lemessage suivant :

    Test reports were found but none of them are new. Did tests run?

    Vous pouvez simplement rsoudre ceci en invalidant la sortie et forcer une rexcution de vos tests enajoutant le bout de code suivant dans votre fichier Gradle :

    test { outputs.upToDateWhen { false }}

  • 137

    Figure 5.52. Configurer une tche de build Gradle

    Aprs avoir ajout le bout de code ci-dessus dans votre fichier de build, la sortie console de la tchedevrait ressembler celle de la figure Figure 5.53, Tche incrmentale de Gradle.

    Figure 5.53. Tche incrmentale de Gradle

    Comme vous pouvez le voir, toutes les tches exceptes test et uploadArchives ont t marques comme jour et nont pas t excutes.

    5.10.3. Construire des projets avec Visual Studio MSBuild

    Jenkins est une application Java, mais il fournit aussi un excellent support pour les applications .NET.

    Pour construire des projets .NET dans Jenkins, vous devez installer le MSBuild plugin14.

    14 http://wiki.jenkins-ci.org/display/HUDSON/MSBuild+Plugin

    http://wiki.jenkins-ci.org/display/HUDSON/MSBuild+Pluginhttp://wiki.jenkins-ci.org/display/HUDSON/MSBuild+Plugin

  • 138

    Vous pourriez aussi vouloir installer le plugin MSTest15 et le plugin NUnit16, pour afficher vos rsultatsde test.

    Une fois que vous avez install les plugins .NET et redmarr Jenkins, vous devez configurer vos outilsde build .NET. Allez dans la page de configuration du systme et spcifiez le chemin vers lexcutableMSBuild (voir la figure Figure 5.54, Configurer les outils de build .NET avec Jenkins).

    Figure 5.54. Configurer les outils de build .NET avec Jenkins

    Une fois que vous lavez configur, vous pouvez retourner dans votre projet Freestyle et ajouter unetape de build .NET la configuration.

    Allez dans la section Build et choisissez loption Build a Visual project or solution using MSBuild dans le menu Ajouter une tape de build. Ensuite, entrez le chemin vers votre script de build MSBuild(un fichier .proj ou .sln), avec nimporte quelle option de ligne de commande que votre script debuild a besoin (voir la figure Figure 5.55, Une tape de build utilisant MSBuild).

    Figure 5.55. Une tape de build utilisant MSBuild

    5.10.4. Construire des projets avec NAnt

    Un autre moyen de construire vos applications .NET est dutiliser NAnt. NAnt est la version .NET deloutil de scripting de build largement utilis dans le monde Java. Les scripts de build NAnt sont des

    15 http://wiki.jenkins-ci.org//display/HUDSON/MSTest+Plugin16 http://wiki.jenkins-ci.org//display/HUDSON/NUnit+Plugin

    http://wiki.jenkins-ci.org//display/HUDSON/MSTest+Pluginhttp://wiki.jenkins-ci.org//display/HUDSON/NUnit+Pluginhttp://wiki.jenkins-ci.org//display/HUDSON/MSTest+Pluginhttp://wiki.jenkins-ci.org//display/HUDSON/NUnit+Plugin

  • 139

    fichiers XML (typiquement avec une extension .build), avec un format trs similaire au script de buildAnt.

    Pour construire avec NAnt dans Jenkins, il vous faut installer le plugin NAnt17 de Jenkins. Une fois quevous lavez install et redmarr Jenkins, allez dans la page de configuration du systme et spcifiezun rpertoire dinstallation NAnt dans la section NAnt Builder (voir la figure Figure 5.54, Configurerles outils de build .NET avec Jenkins).

    Maintenant, allez dans la section Build de votre projet Freestyle et choisissez Execute NAnt build (voir la figure Figure 5.56, Une tape de build utilisant NAnt). Ici, vous spcifiez le script de buildet la target que vous voulez invoquer. Si vous cliquez sur loption Avance , vous pouvez aussispcifier des valeurs de proprit pour les passer dans le script NAnt.

    Figure 5.56. Une tape de build utilisant NAnt

    5.10.5. Construire des projets avec Ruby et Ruby on Rails

    Jenkins est un excellent choix lorsquil sagit de faire de lIC sur vos projets Ruby et Ruby on Rails.Le plugin Rake vous permet dajouter des tapes de build Rake dans vos tches de build. Vous pouvezaussi utiliser le plugin Ruby qui vous permet de lancer des scripts Ruby directement dans votre tchede build. Finallement, le plugin Ruby Metrics fournit un support pour les outils de mtriques de qualitde code comme RCov, Rails stats, et Flog.

    Un autre outil prcieux dans ce domaine est CI:Reporter.Cette librairie est un add-on deTest::Unit, RSpec, et Cucumber qui gnre des rapports compatible avec JUnit de vos tests. Commevous allez le voir, les rsultats de test compatibles avec JUnit peuvent tre utiliss directement parJenkins pour faire des rapports de vos rsultats de test. Vous devez installer CI:Reporter en utilisantGem comme illustr ici :

    $ sudo gem install ci_reporterSuccessfully installed ci_reporter-1.6.41 gem installed

    Ensuite, il vous faudra le configurer dans votre Rakefile, en ajoutant ce qui suit :

    17 http://wiki.jenkins-ci.org/display/HUDSON/NAnt+Plugin

    http://wiki.jenkins-ci.org/display/HUDSON/NAnt+Pluginhttp://wiki.jenkins-ci.org/display/HUDSON/NAnt+Plugin

  • 140

    require 'rubygems'gem 'ci_reporter'require 'ci/reporter/rake/test_unit' # use this if you're using Test::Unit

    Dans le chapitre Chapter 9, Qualit du Code, nous discutons de lintgration des mtriques de qualit decode dans vos builds Jenkins. Jenkins fournit aussi un support sur les mtriques de couverture de codeen Ruby. Le plugin Ruby Metrics supporte les mtriques de qualit de code en utilisant rcov aussi bienque des statistiques de code gnrales avec Rails stats. Pour installer le plugin rcov, vous deveztout d'abord excuter quelque chose comme les lignes suivantes :

    $ ./script/plugin install http://svn.codahale.com/rails_rcov

    Une fois que cest configur, vous serez en mesure dafficher vos rsultats de test et la tendance dersultat de test dans Jenkins.

    Finalement, vous pouvez configurer un build Rake simplement en utilisant une tape de build Rake,comme illustr dans la Figure 5.57, Une tape de build utilisant Rake.

    Figure 5.57. Une tape de build utilisant Rake

    Vous devez aussi configurer Jenkins pour faire des rapports sur les rsultats des tests et les mtriques dequalit. Vous pouvez faire ceci en activant les options Publish JUnit test result report , Publish Railsstats report , et Public Rcov report (voir la figure Figure 5.58, Publier des mtriques de qualit decode pour Ruby et Rails).Les rapports XML JUnit seront trouvs dans le rpertoire results (entrezresults/*.xml dans le champ Test report XMLs), et le rapport dans le rpertoire coverage/units.

  • 141

    Figure 5.58. Publier des mtriques de qualit de code pour Ruby et Rails

    5.11. ConclusionDans ce chapitre, nous avons couvert les bases sur la cration de tches de build pour les cas les pluscommuns que vous pouvez rencontrer. Plus tard dans ce livre, nous allons utiliser ces fondamentauxpour discuter sur des options plus avances comme les builds paramtrs, les builds matriciels, et lesstratgies de promotion de build.

  • Chapter 6. Tests automatiss6.1. Introduction

    Si vous n'utilisez pas les tests automatiss avec votre environnement d'intgration continue, vous passez ct d'un aspect important. Croyez-moi l'IC sans les tests automatiss reprsente juste une petiteamlioration pour les tches de build lances automatiquement. Maintenant, ne vous mprenez pas, sivous partez de zro, c'est quand mme un grand pas en avant, mais vous pouvez faire mieux. En rsum,si vous utilisez Jenkins sans tests automatiss, vous n'obtenez pas autant de valeur de votre infrastructured'intgration continue que vous le devriez.

    Un des principes de base de l'intgration continue est qu'un build doit tre vrifiable. Vous deveztre capable de dterminer objectivement si un build donn est prt passer la prochaine tape duprocessus de construction, et le meilleur moyen de le faire est d'utiliser les tests automatiss. Sans unebonne automatisation des tests, vous allez devoir conserver de nombreux artefacts construits et les testermanuellement, ce qui est contraire l'esprit de l'intgration continue.

    Il y a plusieurs faons d'intgrer les tests automatiss dans votre application. Une des faons lesplus efficaces pour crire des tests de haute qualit est de les crire en premier, en utilisant destechniques comme Test-Driven Development (TDD) ou Behavior-Driven Development (BDD). Danscette approche, utilise couramment dans de nombreux projets agiles, le but de vos tests unitaires est lafois de clarifier votre comprhension du comportement du code et d'crire un test automatis prouvantque le code implmente le comportement. En se concentrant sur le test du comportement attendu de votrecode, plutt que sur son implmentation, cela rend les tests plus comprhensibles et plus pertinents, etpar consquent aide Jenkins fournir une information plus pertinente.

    Bien entendu, l'approche plus classique mettant en oeuvre des tests unitaires, quand le code a timplment, est aussi couramment utilise, et est certainement mieux que pas de tests du tout.

    Jenkins n'est pas limit aux tests unitaires, cependant. Il y a plusieurs autres types de tests automatissque vous devriez envisager, selon la nature de votre application, parmi les tests d'intgration, les testsweb, les tests fonctionnels, les tests de performance, les tests de charge et autres. Tous ceux-ci ont leurplace dans un environnement de build automatis.

    Jenkins peut aussi tre utilis, en conjonction avec des techniques telles que Behavior-DrivenDevelopment et Acceptance Test Driven Development, comme un outil de communication destin la fois aux dveloppeurs et aux autres intervenants d'un projet. Des frameworks BDD tels que easyb,fitnesse, jbehave, rspec, Cucumber, et beaucoup d'autres, essaient de prsenter les tests d'acceptation desorte que les testeurs, les Product Owners, et les utilisateurs puissent les comprendre. Avec de tels outils,Jenkins peut fournir des informations sur l'avancement d'un projet en termes mtiers, et ainsi faciliter lacommunication entre dveloppeurs et les non-dveloppeurs l'intrieur d'une quipe.

  • 144

    Pour des applications existantes avec peu ou pas de tests automatiss existants, cela peut tre difficileet consommateur en temps de mettre en place des tests unitaires complets dans le code. De plus, lestests peuvent ne pas tre trs efficaces, parce qu'ils auront tendance valider l'implmentation existanteplutt que vrifier le fonctionnel attendu. Une approche intressante dans ces situations est d'crire destests fonctionnels automatiss (rgression) qui simulent les manires les plus courantes d'utilisation del'application. Par exemple, les outils de tests web automatiss tels que Selenium et WebDriver peuventtre utiliss efficacement pour tester les applications web un haut niveau. Alors que cette approche n'estpas aussi complte que la combinaison de tests unitaires, d'intgration et d'acceptation de bonne qualit,c'est quand mme une faon efficace et conomique d'intgrer des tests de rgression automatiss dansune application existante.

    Dans ce chapitre, nous allons voir comment Jenkins vous aide conserver les traces des rsultats destests automatiss, et comment vous pouvez utiliser cette information pour surveiller et dissquer votreprocessus de build.

    6.2. Automatisez vos tests unitaires et d'intgration

    Le premier sujet que nous allons regarder est comment intgrer vos tests unitaires dans Jenkins. Quevous matrisiez l'approche Test-Driven Development, ou que vous criviez des tests unitaires avec uneapproche plus conventionnelle, ce seront probablement les premiers tests que vous voudrez automatiseravec Jenkins.

    Jenkins est excellent dans l'analyse des rsultats de vos tests. Cependant, c'est vous d'crire les testsappropris et de configurer votre script de build pour qu'il les excute automatiquement. Heureusement,intgrer des tests unitaires dans vos builds automatiss est gnralement ais.

    Il y a de nombreux outils de tests unitaires, avec la famille xUnit occupant une place prpondrante. Dansle monde Java, JUnit est le standard de facto, bien que TestNG soit aussi un framework de test unitairepopulaire avec un certain nombre de fonctionnalits innovantes. Pour les applications C#, le frameworkNUnit propose des fonctionnalits similaires celles fournies par JUnit, comme le fait Test::Unitpour Ruby. Pour C/C++, il y a CppUnit, et les dveloppeurs PHP peuvent utiliser PHPUnit. Et cetteliste n'est pas exhaustive !

    Ces outils peuvent aussi tre utiliss pour les tests d'intgration, les tests fonctionnels, les tests webet ainsi de suite. De nombreux outils de tests web, comme Selenium, WebDriver, et Watir, gnrentdes rapports compatibles xUnit. Les outils Behaviour-Driven Development et de tests d'acceptationautomatiss comme easyb, Fitnesse, Concordion sont aussi orients xUnit. Dans les sections suivantes,nous ne faisons pas de distinction entre ces diffrents types de test, parce que, d'un point de vueconfiguration, ils sont traits de la mme faon par Jenkins. Cependant, vous aurez certainement fairela distinction dans vos tches de build. Afin d'obtenir un compte-rendu plus rapide, vos tests devronttre groups dans des catgories bien dfinies, en commenant par les rapides tests unitaires, ensuiteviendront les tests d'intgration, pour finir par excuter les tests fonctionnels et web, plus longs.

  • 145

    Une discussion dtaille sur la faon d'automatiser vos tests est en dehors du sujet de ce livre, maisnous couvrons quelques techniques utiles pour Apache Maven et Ant dans Appendix A, Automatiservos tests unitaires et dintgration.

    6.3. Configuration des rapports de test dans Jenkins

    Une fois que votre build gnre des rsultats de test, vous devez configurer votre tche de build Jenkinsafin de les afficher. Comme mentionn prcdemment, Jenkins sait traiter n'importe quel rapport detests compatible xUnit, quel que soit le langage avec lequel ils ont t crits.

    Pour les tches de build Maven, aucune configuration spcifique n'est requise assurez-vous seulementque vous lancez bien un goal qui va excuter vos tests, tel que mvn test (pour vos tests unitaires) oumvn verify (pour les test unitaires et d'intgration). Un exemple de configuration de tche de buildMaven est donn dans Figure 6.1, Vous configurez votre installation Jenkins dans l'cran AdministrerJenkins.

    Figure 6.1. Vous configurez votre installation Jenkins dans l'cran Administrer Jenkins

    Pour les tches de build free-style, vous devez effectuer un petit travail de configuration. En plus devous assurer que votre build excute les tests, vous devez indiquer Jenkins de publier les rapports detest JUnit. Vous le configurez dans la section Actions la suite du build (voir Figure 6.2, Configurerles rapports de test Maven dans un projet free-style). Ici, vous fournissez un chemin vers les rapportsXML JUnit ou TestNG. Leur chemin exact dpend du projet pour un projet Maven, un chemin tel que**/target/surefire-reports/*.xml les trouvera pour la plupart des projets. Pour un projet Ant,cela dpendra de la faon dont vous avez configur la tache Ant JUnit, comme discut prcdement.

  • 146

    Figure 6.2. Configurer les rapports de test Maven dans un projet free-style

    Pour les projets Java, qu'ils utilisent JUnit ou TestNG, Jenkins fournit une excellente intgration debase. Si vous utilisez Jenkins pour des projets non Java, vous aurez besoin du plugin xUnit. Ce pluginpermet Jenkins de traiter les rapports de test de projets non Java d'une faon uniforme. Il fournit unsupport de MSUnit et NUnit (pour C# et d'autres langages .NET), UnitTest++ et Boost Test (pour C++),PHPUnit (pour PHP), ainsi que quelques autres bibliothques xUnit via d'autres plugins (voir Figure 6.3,Installer le plugin xUnit).

    Figure 6.3. Installer le plugin xUnit

    Une fois que vous avez install le plugin xUnit, vous devez configurer le traitement pour vos rapportsxUnit dans la section Actions la suite du build. Slectionnez la case Publish testing tools resultreport, et saisissez le chemin vers les rapports XML gnrs par votre bibliothque de test (voirFigure 6.4, Publier les rsultat de test xUnit). Quand la tche de build s'excute, Jenkins convertiraces rapports en rapports JUnit de telle manire ce qu'ils soient affichs dans Jenkins.

  • 147

    Figure 6.4. Publier les rsultat de test xUnit

    6.4. Afficher les rsultats de test

    Une fois que Jenkins sait o se trouvent les rapports de test, il fournit un excellent travail de rapport surces derniers. En effet, une des tches principales de Jenkins est de dtecter et de fournir des rapports surdes checs de build. Et un test unitaire chou est un des symptmes les plus vidents.

    Comme nous le mentionnions plus tt, Jenkins fait la distinction entre les builds chous et les buildsinstables. Un build chou (indiqu par une balle rouge) signale des tests chous, ou une tche de buildqui est casse d'une faon brutale, telle qu'une erreur de compilation. Un build instable, en revanche,est un build qui n'est pas considr de qualit suffisante. C'est intentionnellement vague : ce qui dfinitla qualit est gnralement donn par vous, mais c'est typiquement li aux mtriques de code commela couverture de code ou les standards de codage, ce que nous discuterons plus tard dans le livre. Pourl'instant, concentrons-nous sur les builds chous.

    Dans Figure 6.5, Jenkins affiche la tendance des rsultats de test sur la page d'accueil du projet nouspouvons voir comment Jenkins affiche une tche de build Maven contenant des checs de tests. Ceciest la page d'accueil de la tche de build, qui devrait tre votre premier point d'entre quand un buildchoue. Quand un build contient des tests en chec, le lien Dernier rsultats des tests indique le nombrecourant d'checs de test dans cette tche de build (5 checs dans l'illustration), et aussi la diffrencedans le nombre d'checs de test depuis le dernier build (+5 dans l'illustration cinq nouveaux checsde test). Vous pouvez aussi voir comment les tests ont russi dans le temps les checs de test desbuilds prcdents apparatront en rouge dans le graphique Tendance des rsultats des tests.

  • 148

    Figure 6.5. Jenkins affiche la tendance des rsultats de test sur la page d'accueil du projet

    Si vous cliquez sur le lien Derniers rsultats des tests, Jenkins vous donnera un aperu des rsultatsdes derniers tests (voir Figure 6.6, Jenkins affiche une vue synthtique des rsultats de test). Jenkinssupporte les structures de projets multi-modules Maven, et pour une tche de build Maven, Jenkins vaafficher une vue synthtique des rsultats de test par module. Pour voir plus de dtails sur les tests enchec dans un module particulier, cliquez simplement sur le module qui vous intresse.

    Figure 6.6. Jenkins affiche une vue synthtique des rsultats de test

    Pour les tches de build free-style, Jenkins vous donnera directement un aperu de vos rsultats de test,mais organis par packages de haut niveau plutt que par modules.

    Dans les deux cas, Jenkins commence par prsenter un aperu des rsultats de test pour chaque package.A partir d'ici, vous pouvez affiner, voir les rsultats de test pour chaque classe de test pour finir par lestests dans les classes de test. Et s'il y a des tests en chec, ils seront surligns en haut de la page.

  • 149

    Cette vue complte vous donne la fois un bon aperu de l'tat courant de vos tests, et une indication surleur historique. La colonne Age indique depuis combien de temps un test a t cass, avec un hyperlienqui vous ramne vers le premier build dans lequel le test a chou.

    Vous pouvez aussi rajouter une description aux rsultats de test, en utilisant le lien ajouter unedescription dans le coin en haut droite de l'cran. C'est une bonne manire d'annoter un chec de buildavec des dtails additionnels, afin de rajouter une information supplmentaire sur l'origine du problmedes checs de test ou des notes sur la faon de les corriger.

    Lorsqu'un test choue, vous voulez gnralement savoir pourquoi. Pour voir les dtails d'un chec d'untest donn, cliquez sur le lien correspondant sur cet cran. Cela va afficher l'ensemble des dtails, ycompris le message d'erreur et la pile, ainsi qu'un rappel du temps depuis lequel le test est en chec (voirFigure 6.7, Les dtails d'un chec de test). Vous devriez vous mfier des tests qui sont en chec depuisplus de deux builds cela signale soit un problme technique pointu qui doit tre investigu, soit uneattitude complaisante envers les tests en chec (les dveloppeurs ignorent peut-tre les checs de build),ce qui est plus srieux et doit srement tre tudi.

    Figure 6.7. Les dtails d'un chec de test

    Assurez-vous que vous gardez un oeil sur le temps que prennent vos tests pour s'excuter, et pasuniquement s'ils passent ou chouent. Les tests unitaires doivent tre conus pour s'excuter rapidement,et des tests trop longs peuvent tre le signe d'un problme de performance. Des tests unitaires lentsretardent aussi le retour, et en IC, un retour rapide est la cl. Par exemple, excuter un millier de testsunitaires en cinq minutes est bon prendre une heure ne l'est pas. Donc c'est une bonne ide de vrifierrgulirement combien de temps vos tests unitaires prennent pour s'excuter, et si ncessaire investiguerpourquoi ils prennent autant de temps.

    Heureusement, Jenkins peut facilement vous dire la dure que prennent vos tests pour s'excuter dans letemps. Sur la page d'accueil de la tche de build, cliquez sur le lien tendance dans la boite Historiquedes builds sur la gauche de l'cran. Cela vous donnera un graphique l'instar de celui dans Figure 6.8,

  • 150

    Les tendances de temps de build peuvent vous donner un bon indicateur de la rapidit de vos tests,vous montrant combien de temps chacun de vos builds a pris pour s'excuter. Cependant, les tests nesont pas la seule chose qui apparat dans une tche de build, mais si vous avez suffisamment de tests regarder de prs, ils vont probablement prendre une grande partie du temps. Ainsi, ce graphique estaussi un excellent moyen de voir comment vos tests se comportent.

    Figure 6.8. Les tendances de temps de build peuvent vous donner un bon indicateur de la rapidit devos tests

    Quand vous tes sur la page Rsultats des tests (voir Figure 6.6, Jenkins affiche une vue synthtiquedes rsultats de test), vous pouvez aussi affiner et voir le temps que prennent les tests dans un module,package ou classe donne. Cliquez sur la dure du test dans la page Rsultats des tests (A dur 31 msdans Figure 6.6, Jenkins affiche une vue synthtique des rsultats de test) pour voir l'historique dutest pour un package, une classe, ou un test individuel (voir Figure 6.9, Jenkins vous permet de voircombien de temps les tests ont mis pour s'excuter). Cela rend facile l'isolation d'un test qui prend plusde temps qu'il ne le devrait, ou mme dcider quand une optimisation gnrale de vos tests unitairesest requise.

    6.5. Ignorer des testsJenkins fait la distinction entre les tests chous et les tests ignors. Les tests ignors sont ceux qui ontt dsactivs, par exemple en utilisant l'annotation @Ignore dans JUnit 4:

    @Ignore("Pending more details from the BA")@Test public void cashWithdrawalShouldDeductSumFromBalance() throws Exception { Account account = new Account(); account.makeDeposit(100);

  • 151

    account.makeCashWithdraw(60); assertThat(account.getBalance(), is(40));}

    Figure 6.9. Jenkins vous permet de voir combien de temps les tests ont mis pour s'excuter

    Ignorer des tests est parfaitement lgitime dans certaines circonstances, comme lors de la mise en placed'un test d'acceptation automatis, ou un test technique de plus haut niveau, en attente pendant quevous implmentez les couches infrieures. Dans de tels cas, vous ne voulez pas tre distrait par le testd'acceptation chou, mais vous ne voulez pas non plus oublier que le test existe. Utiliser des techniquestelles que l'annotation @Ignore est certainement meilleur que de commenter simplement le test ou dele renommer (dans JUnit 3), car cela permet Jenkins de garder un oeil sur les tests ignors pour vous.

    Avec TestNG, vous pouvez aussi ignorer des tests, en utilisant la proprit enabled:

    @Test(enabled=false)public void cashWithdrawalShouldDeductSumFromBalance() throws Exception { Account account = new Account(); account.makeDeposit(100); account.makeCashWithdraw(60); assertThat(account.getBalance(), is(40));}

    Avec TestNG, vous pouvez aussi dfinir des dpendances entre les tests, de faon ce que certains testss'excuteront aprs qu'un autre test ou un groupe de tests se soit excut, comme illustr ici:

  • 152

    @Testpublic void serverStartedOk() {...} @Test(dependsOnMethods = { "serverStartedOk" })public void whenAUserLogsOnWithACorrectUsernameAndPasswordTheHomePageIsDisplayed(){..}

    Ici, si le premier test (serverStartedOk()) choue, le test suivant sera ignor.

    Dans tous ces cas, Jenkins marquera les tests qui n'ont pas t excuts en jaune, la fois dans la tendancede rsultats de test globale, et dans les dtails du test (voir Figure 6.10, Jenkins affiche les tests ignorsen jaune). Les tests ignors ne sont pas aussi mauvais que des tests chous, mais il est important dene pas avoir l'habitude de les ngliger. Les tests ignors sont comme des branches dans un systme degestion de version: un test doit tre ignor pour une raison particulire, avec une ide claire de la date laquelle il sera ractiv. Un test ignor qui reste ignor pendant une priode trop longue ne sent pas bon.

    Figure 6.10. Jenkins affiche les tests ignors en jaune

    6.6. Couverture de codeUne autre mtrique trs utile lie aux tests est la couverture de code. La couverture de code donne uneindication sur les parties de votre application qui ont t excutes pendant les tests. Alors que ce n'estpas en soit une indication suffisante sur la qualit du test (il est facile d'excuter une application entiresans rellement tester quoique ce soit, et les mtriques de couverture de code ne fournissent pas uneindication de la qualit ou de l'exactitude de vos tests), c'est une bonne indication du code qui n'a pas ttest. Et, si votre quipe est en train d'adopter des pratiques de test rigoureuses telles que Test-Driven-Development, la couverture de code peut tre un bon indicateur sur la faon dont ces pratiques ont tmises en place.

    L'analyse de la couverture de code est un traitement consommateur en CPU et mmoire, et va ralentirvotre tche de build de faon significative. Pour cette raison, vous allez gnralement excuter les

  • 153

    mtriques de couverture de code dans une tche de build Jenkins spare, excute aprs que vos testsunitaires et d'intgration aient russi.

    Il y a de nombreux outils de couverture de code disponibles, et plusieurs sont supports dans Jenkins,tous via des plugins ddis. Les dveloppeurs Java peuvent choisir entre Cobertura et Emma, deux outilspopulaires de couverture de code open source, ou Clover, un puissant outil commercial de couverturede code d'Atlassian. Pour les projets .NET, vous pouvez utiliser NCover.

    Le fonctionnement et la configuration de tous ces outils sont semblables. Dans cette section, nous allonsexaminer Cobertura.

    6.6.1. Mesurer la couverture de code avec Cobertura

    Cobertura1 est un outil de couverture de code open source pour Java et Groovy qui est simple d'utilisationet s'intgre parfaitement la fois dans Maven et Jenkins.

    Comme tous les plugins Jenkins de mtriques de qualit de code, 2 le plugin Cobertura pour Jenkinsne va pas lancer les tests de couverture de code pour vous. C'est vous de gnrer les informations decouverture de code dans le cadre de votre processus de build automatis. Jenkins, d'autre part, fournit unexcellent travail de rapport sur les mtriques de couverture de code, notamment le suivi de la couverturede code dans le temps, et fournissant une couverture de code agrge sur plusieurs modules applicatifs.

    La couverture de code peut tre une affaire complexe, et il est utile de comprendre le traitement queCobertura effectue, surtout quand vous devez le mettre en place dans des outils de scripting de plus basniveau comme Ant. L'analyse de la couverture de code fonctionne en trois tapes. D'abord, il modifie(ou instrumente) les classes de votre application, afin qu'elles conservent le nombre de fois que chaqueligne de code a t excute.3Il stocke ces informations dans un fichier spcial (Cobertura utilise unfichier nomm cobertura.ser).

    Quand le code de l'application a t instrument, vous excutez vos tests avec le code instrument. Ala fin des tests, Cobertura aura gnr un fichier de donnes indiquant pour chaque ligne le nombre defois qu'elle a t excute au cours des tests.

    Une fois que ce fichier a t gnr, Cobertura peut utiliser cette donne pour gnrer un rapport dansun format plus lisible, comme XML ou HTML.

    6.6.1.1. Intgrer Cobertura avec Maven

    Produire des mtriques de couverture de code avec Cobertura dans Maven est relativement simple. Sivous tes intresss par la gnration des donnes de couverture de code, il vous suffit de rajouter lecobertura-maven-plugin la section build de votre fichier pom.xml:

    1 http://cobertura.sourceforge.net2 l'exception notable de Sonar, que nous allons examiner plus tard dans le livre.3C'est en fait une lgre simplification ; en fait, Cobertura stocke aussi d'autres informations, telles que le nombre de fois quechaque rsultat possible d'un test boolen a t excut. Cependant, cela ne modifie pas l'approche gnrale.

    http://cobertura.sourceforge.nethttp://cobertura.sourceforge.net

  • 154

    ... org.codehaus.mojo cobertura-maven-plugin 2.5.1 html xml ... ...

    Cela va gnrer les mtriques de couverture de code quand vous lancerez le plugin Coberturadirectement :

    $ mvn cobertura:cobertura

    Les donnes de couverture de code seront gnres dans le rpertoire target/site/cobertura, dansun fichier nomm coverage.xml.

    Cependant, cette approche va instrumenter vos classes et produire les donnes de couverture de codepour chaque build, ce qui est inefficace. Une meilleure approche est de placer cette configuration dansun profil spcifique, comme montr ici :

    ... metrics org.codehaus.mojo cobertura-maven-plugin 2.5.1 html xml

  • 155

    ...

    Dans ce cas, vous lancerez le plugin Cobertura en utilisant le profil metrics pour gnrer les donnesde couverture de code :

    $ mvn cobertura:cobertura -Pmetrics

    Une autre approche consiste inclure les rapports de couverture de code dans vos rapports Maven. Cetteapproche est beaucoup plus lente et plus consommatrice en mmoire que de gnrer simplement lesdonnes de couverture de code, mais cela peut avoir du sens si vous gnrez aussi d'autres mtriquesde qualit de code et leurs rapports en mme temps. Si vous voulez le faire avec Maven 2, vous devezaussi inclure le plugin Maven Cobertura plugin dans la section reporting, comme montr ici :

    ... org.codehaus.mojo cobertura-maven-plugin 2.5.1 html xml

    A prsent, les donnes de couverture de code seront gnres quand vous gnrerez le site Maven pource projet :

    $ mvn site

    Si votre projet Maven contient des modules (comme il est de pratique courante pour des gros projetsMaven), vous devez mettre en place la configuration Cobertura dans le fichier pom.xml parent. Lesmtriques de couverture de code et le rapport seront gnrs sparment pour chaque module. Si vousutilisez l'option de configuration aggregate, le plugin Maven Cobertura gnrera aussi un rapport deplus haut niveau combinant les donnes de couverture de code de tous les modules. Cependant, quevous utilisiez cette option ou non, le plugin Jenkins Cobertura va lire les donnes de couverture de codede plusieurs fichiers et les combiner dans un seul rapport aggrg.

    Au moment de la rdaction, il y a une limitation avec le plugin Maven Cobertura la couverture decode sera uniquement enregistre pour les tests excuts pendant la phase test, et pas les tests excuts

  • 156

    pendant la phase integration-test. Cela peut tre un problme si vous utilisez cette phase pourlancer des tests d'intgration ou des tests web qui ncessitent une application compltement package etdploye dans ce cas, la couverture de code des tests qui sont uniquement excuts pendant la phaseintegration-test ne sera pas compte dans les mtriques de couverture de code Cobertura.

    6.6.1.2. Intgrer Cobertura avec Ant

    Intgrer Cobertura dans votre build Ant est un peu plus compliqu que de le faire avec Maven.Cependant, cela vous permet d'avoir un contrle plus fin sur les classes qui sont instrumentes, et quandla couverture de code est mesure.

    Cobertura est livr avec une tche Ant que vous pouvez utiliser pour intgrer Cobertura dans vos buildsAnt. You devez tlcharger la dernire distribution Cobertura, et la dcompresser quelque part sur votredisque dur. Afin que votre build soit plus portable, et donc plus facile dployer dans Jenkins, c'estune bonne ide de placer la distribution Cobertura que vous utilisez dans votre rpertoire projet, et de lasauvegarder dans votre systme de gestion de version. Ainsi, c'est le moyen le plus facile pour garantirque le build utilisera la mme version de Cobertura quelle que soit la faon dont il est excut.

    En supposant que vous avez tlcharg la dernire installation de Cobertura et que vous l'avez place l'intrieur de votre projet dans un rpertoire nomm tools, vous pourriez faire quelque chose commececi :

    Indique Ant o se trouve l'installation de Cobertura. Nous devons mettre en place un classpath que Cobertura utilisera pour s'excuter. Le chemin contient l'application Cobertura elle-mme. Et toutes ses dpendances.

    Ensuite, vous devez instrumenter les classes de l'application. Vous devez faire attention de placer cesclasses instrumentes dans un rpertoire diffrent, de telle manire qu'elles ne seront pas dployes enproduction par accident :

  • 157

    Nous ne pouvons instrumenter les classes de l'application qu'une fois qu'elles ont t compiles. Dtruit toutes les donnes de couverture de code gnres par les builds prcdents. Dtruit toutes les classes prcdemment instrumentes. Instrumente les classes de l'application (mais pas les classes des tests) et les place dans le rpertoire

    ${instrumented.dir} .

    A ce stade, le rpertoire ${instrumented.dir} contient une version instrumente de nos classesapplicatives. Maintenant, tout ce que nous devons faire pour gnrer des donnes utiles de couverturede code est d'excuter nos tests unitaires avec les classes de ce rpertoire :

    Excute les tests JUnit avec les classes instrumentes. Les classes instrumentes utilisent les classes de Cobertura, donc les bibliothques Cobertura

    doivent aussi se trouver dans le classpath.

    Cela va produire les donnes brutes de couverture de code dont nous avons besoin pour produire lesrapports XML de couverture que Jenkins peut utiliser. Pour produire ces rapports, nous devons lancerune autre tche, comme montr ici :

    Enfin, n'oubliez pas de faire le mnage une fois que tout est fini : la cible clean ne doit pasdtruire uniquement les classes gnres, mais aussi les classes gnres instrumentes, les donnes decouverture de code Cobertura, et les rapports Cobertura :

  • 158

    Une fois cela fait, vous tes prt intgrer vos rapports de couverture de code dans Jenkins.

    6.6.1.3. Installer le plugin de couverture de code Cobertura

    Une fois que les donnes de couverture de code sont gnres dans le cadre de votre processusde build, vous pouvez configurer Jenkins pour les afficher. Ceci implique l'installation du pluginJenkins Cobertura. Nous avons dcrit ce processus dans Section 2.8, Adding Code Coverage andOther Metrics, mais nous allons le dcrire nouveau pour rafrachir votre mmoire. Allez surl'cran Administrer Jenkins, et cliquez sur Gestion des plugins. Cela va vous amener l'cran dugestionnaire des plugins. Si Cobertura n'a pas t install, vous trouverez le plugin Cobertura dansl'onglet Disponibles, dans la section Build Reports (voir Figure 6.11, Installer le plugin Cobertura).Pour l'installer, cochez simplement la case et appuyez sur Entre (ou faites dfiler jusqu'au bas de l'cranet cliquez sur le bouton Installer). Jenkins va tlcharger et installer le plugin pour vous. Une fois quele tlchargement est fini, vous devez redmarrer votre serveur Jenkins.

    Figure 6.11. Installer le plugin Cobertura

    6.6.1.4. Les rapports de couverture de code dans votre build

    Une fois que vous avez install le plugin, vous pouvez mettre en place les rapports de couverture de codedans vos tches de build. Puisque la couverture de code peut tre lente et consommatrice en mmoire,vous devrez gnralement crer une tche de build spare pour cela et les autres mtriques de qualit decode, qui sera excute aprs les tests unitaires et d'intgration. Pour de gros projets, vous pouvez mmele mettre en place via un build qui s'excute sur une base quotidienne. En effet, le retour sur les mtriquesde couverture de code et autres n'est gnralement pas aussi critique que le retour sur les rsultats de test,et cela va librer des excuteurs de build pour des tches de build qui peuvent bnficier de retour rapide.

  • 159

    Comme nous le mentionnions prcdemment, Jenkins ne fait pas d'analyse de couverture par lui-mme vous devez configurer votre build pour produire le fichier Cobertura coverage.xml (oufichiers) avant que vous puissiez gnrer de jolis graphes ou rapports, gnralement en utilisant unedes techniques dont nous avons discut prcdemment (voir Figure 6.12, Votre build de couverture decode doit produire les donnes de couverture de code).

    Figure 6.12. Votre build de couverture de code doit produire les donnes de couverture de code

    Une fois que vous avez configur votre build pour produire des donnes de couverture de code, vouspouvez configurer Cobertura dans la section Actions la suite du build de votre tche de build. Sivous cochez la case Publish Cobertura Coverage Report, vous devriez voir quelque chose commeFigure 6.13, Configurer les mtriques de couverture de code dans Jenkins.

    Figure 6.13. Configurer les mtriques de couverture de code dans Jenkins

    Le premier et plus important champ ici est le chemin des donnes XML Cobertura que nous avonsgnres. Votre projet peut contenir un seul fichier coverage.xml, ou plusieurs. Si vous avez un projetMaven multi-modules, par exemple, le plugin Maven Cobertura va gnrer un fichier coverage.xmldistinct pour chaque module.

    Le chemin accepte des caractres gnriques du style Ant, et il est donc facile d'inclure les donnesde couverture de code partir de plusieurs fichiers. Pour tout projet Maven, un chemin tel que **/

  • 160

    target/site/cobertura/coverage.xml inclura toutes les mtriques de couverture de code de tousles modules dans le projet.

    Il y a en fait plusieurs types de couverture de code, et il est parfois utile de les distinguer. La plus intuitiveest la couverture de lignes, qui compte le nombre de fois qu'une ligne donne est excute pendant lestests automatiss. Conditional Coverage (aussi appel Branch Coverage) prend en compte si lesexpressions boolennes dans les instructions if et semblables sont testes d'une manire qui vrifietous les rsultats possibles d'une expression conditionnelle. Par exemple, tant donn le fragment decode suivant:

    if (price > 10000) { managerApprovalRequired = true;}

    Pour obtenir une couverture de code complte pour ce code, vous devez l'excuter deux fois : une foisavec une valeur suprieure 10,000, une autre avec une valeur infrieure ou gale 10,000.

    D'autres mtriques de couverture de code plus basiques incluent les mthodes (combien de mthodesdans l'application ont t excutes par les tests), classes et packages.

    Jenkins vous permet de dfinir lesquelles de ces mtriques vous voulez suivre. Par dfaut, le pluginCobertura enregistre les couvertures conditionnelles, lignes, et mthodes, ce qui est gnralementsuffisant. Cependant, il est facile de rajouter d'autres mtriques de couverture de code si vous pensezque ce peut tre utile pour votre quipe.

    Le traitement par Jenkins des mtriques de couverture de code n'est pas uniquement un affichage passif Jenkins vous permet de dfinir comment ces mtriques affectent le rsultat du build. Vous pouvezdfinir des valeurs de palier pour les mtriques de couverture de code qui affectent la fois le rsultatdu build et le rapport mto sur le tableau de bord Jenkins (voir Figure 6.14, Les rsultats des tests decouverture de code contribuent l'tat du projet sur le tableau de bord). Chaque mtrique de couverturede code que vous suivez possde trois valeurs de palier.

    Figure 6.14. Les rsultats des tests de couverture de code contribuent l'tat du projet sur le tableaude bord

    Le premier (celui avec une icne ensoleille) est la valeur minimale que le build doit atteindre pouravoir une icne ensoleille. La seconde indique la valeur en dessous de laquelle le build aura une icne

  • 161

    orageuse. Jenkins va extrapoler les valeurs intermdiaires entre ces deux-ci pour d'autres icnes mtoplus nuances.

    Le dernier palier est simplement la valeur en dessous de laquelle un build sera marqu comme instable avec une balle jaune. Bien que n'tant pas aussi mauvais qu'une balle rouge (pour un build cass), uneballe jaune entrainera un message de notification et apparatra comme mauvais sur le tableau de bord.

    Cette fonctionnalit n'est pas un simple dtail esthtique elle fournit un moyen prcieux de fixerdes objectifs de qualit de code pour vos projets. Bien qu'elle ne puisse pas tre interprte seule, unemauvaise couverture de code n'est gnralement pas un bon signe pour un projet. Donc si vous prenezla couverture de code au srieux, utilisez ces valeurs de palier pour fournir un retour direct quand leschoses ne sont pas la hauteur.

    6.6.1.5. Interprter les mtriques de couverture de code

    Jenkins affiche vos rapports de couverture de code sur la page d'accueil de la tche de build. La premirefois qu'il est excut, il produit un simple graphique barres (voir Figure 2.30, Jenkins displays codecoverage metrics on the build home page). A partir du second build, un graphique est affich, indiquantles diffrents types de couverture que vous suivez dans le temps (voir Figure 6.15, Configurer lesmtriques de couverture de code dans Jenkins). Dans les deux cas, le graphique affichera aussi lesmtriques de couverture de code pour le dernier build.

    Figure 6.15. Configurer les mtriques de couverture de code dans Jenkins

    Jenkins offre une grande valeur ajoute en vous permettant de descendre dans les mtriques decouverture de code, affichant les erreurs de couverture de code pour les packages, classes l'intrieurd'un package, et les lignes de code l'intrieur d'une classe (voir Figure 6.16, Afficher les mtriquesde couverture de code). Quel que soit le niveau de dtail que vous regardiez, Jenkins affichera ungraphe en haut de la page montrant la tendance de couverture dans le temps. Plus bas, vous trouverezla rpartition par package ou classe.

  • 162

    Figure 6.16. Afficher les mtriques de couverture de code

    Lorsque vous arrivez au niveau de dtail de la classe, Jenkins affiche aussi le code source de la classe,avec les lignes colores en fonction de leur niveau de couverture. Les lignes qui ont t compltementexcutes pendant les tests sont en vert, et les lignes qui n'ont jamais t excutes sont marques enrouge. Un nombre dans la marge indique le nombre de fois que la ligne en question a t excute. Enfin,un ombrage jaune dans la marge est utilise pour indique une couverture conditionnelle insuffisante(par exemple, une instruction if qui a seulement t test avec un rsultat).

    6.6.2. Mesurer la couverture de code avec Clover

    Clover est un excellent outil de couverture de code commercial d'Atlassian4. Clover fonctionneparfaitement pour des projets Ant, Maven, ou mme Grails. La configuration et l'utilisation de Cloverest bien documente sur le site web d'Atlassian, donc nous ne regarderons pas ces aspects en dtail.Cependant, en guise d'exemple, voici une configuration Maven typique de Clover pour une utilisationavec Jenkins :

    ... ... com.atlassian.maven.plugins maven-clover2-plugin 3.0.4

    4 http://www.atlassian.com/software/clover

    http://www.atlassian.com/software/cloverhttp://www.atlassian.com/software/clover

  • 163

    false true ...

    Cela va gnrer la fois des rapports de couverture de code HTML et XML, y compris les donnesagrges si le projet Maven contient plusieurs modules.

    Pour intgrer Clover dans Jenkins, vous devez installer le plugin Jenkins Clover selon la manirehabituelle en utilisant l'cran du gestionnaire de plugins. Une fois que vous avez redmarr Jenkins,vous pourrez intgrer les donnes de couverture de code Clover dans vos builds.

    Excuter Clover sur votre projet est un projet en plusieurs tapes : vous instrumentez votre codeapplicatif, excutez les tests, agrgez les donnes de test (pour les projets Maven plusieurs modules)et gnrez les rapports HTML et XML. Puisque cela peut tre une operation assez lente, vous allezgnralement l'excuter dans une tche de build spare, et pas avec vos test classiques. Vous pouvezle faire comme suit :

    $ clover2:setup test clover2:aggregate clover2:clover

    Ensuite, vous devez mettre en place les rapports Clover dans Jenkins. Cochez la case Publish CloverCoverage Report pour l'activer. La configuration est similaire celle de Cobertura vous devez fournirle chemin du rpertoire du rapport HTML Clover, et du fichier rapport XML, et vous pouvez aussidfinir des valeurs de palier pour les icnes mteo ensoleilles et orageuses, et pour les builds instables(voir Figure 6.17, Configurer les rapports Clover dans Jenkins).

    Figure 6.17. Configurer les rapports Clover dans Jenkins

    Une fois que vous l'aurez fait, Jenkins affichera le niveau actuel de couverture de code, ainsi qu'ungraphe de la couverture de code dans le temps, sur la page d'accueil de votre tche de build de votreprojet (voir Figure 6.18, Tendance de couverture de code Clover).

  • 164

    Figure 6.18. Tendance de couverture de code Clover

    6.7. Tests d'acceptation automatissLes tests d'acceptation automatiss jouent un rle important dans de nombreux projets agiles, la foispour la vrification et pour la communication. Comme outil de vrification, les tests d'acceptation jouentun rle similaire aux tests d'intgration, et visent dmontrer que l'application fait effectivement ce quiest attendu d'elle. Mais ce n'est qu'un aspect secondaire des tests d'acceptation automatiss. L'objectifprincipal est en fait la communication montrer aux non dveloppeurs (experts mtier, analystesmtiers, testeurs, et ainsi de suite) prcisement o en est le projet.

    Les tests d'acceptation ne doivent pas tre mlangs avec des tests orients dveloppeurs, parce qu' lafois leur finalit et leur audience sont trs diffrentes. Les tests d'acceptation doivent tre des exemplesmontrant comment le systme fonctionne, avec un accent sur la dmonstration plutt que sur une preuveexhaustive. Les tests exhaustifs doivent tre faits au niveau des tests unitaires.

    Les tests d'acceptation peuvent tre automatiss en utilisant des outils conventionnels tels que JUnit,mais il y a une tendance croissante utiliser des frameworks Behavior-Driven Development (BDD) cet effet, parce qu'ils correspondent mieux l'audience non technique des tests d'acceptation. Les outilsBehavior-driven development utiliss pour les tests d'acceptation automatiss gnrent gnralementdes rapports HTML avec une mise en page bien adapte aux non dveloppeurs. Ils produisent aussisouvent des rapports compatibles JUnit qui peuvent tre traits directement par Jenkins.

    Les frameworks Behavior-Driven Development ont aussi la notion de tests en attente, tests qui sontautomatiss, mais qui n'ont pas encore t implments par l'quipe de dveloppement. Cette distinctionjoue un rle important dans la communication avec les autres acteurs non dveloppeurs : si vous pouvezautomatiser ces tests tt dans le processus, ils vous donneront un excellent indicateur des fonctionnalitsqui ont t implmentes, qui fonctionnent, ou qui n'ont pas encore t dmarres.

    En rgle gnrale, vos tests d'acceptation doivent tre affichs sparment des autres tests automatissplus conventionnels. S'ils utilisent le mme framework de test que vos tests classiques (e.g., JUnit),

  • 165

    assurez-vous qu'ils sont excuts dans une tche de build spare, de telle faon que les non-dveloppeurs peuvent les visualiser et se concentrer sur les tests orients mtier sans tre distraits parceux de plus bas niveau ou techniques. Il peut tre aussi utile d'adopter des conventions de nommageorientes mtier et fonctionnelles pour vos tests et classes de test, afin de les rendre plus accessible auxnon-dveloppeurs (voir Figure 6.19, Utilisation de conventions de nommage orientes mtier pour destests JUnit). La faon dont vous nommez vos tests et classes de test peut faire une relle diffrencequant la lecture des rapports de test et la comprhension des fonctionnalits et comportements mtierqui sont tests.

    Figure 6.19. Utilisation de conventions de nommage orientes mtier pour des tests JUnit

    Si vous utilisez un outil qui gnre des rapports HTML, vous pouvez les afficher dans le mme buildque vos tests classiques, tant qu'ils apparaissent dans un rapport spar. Jenkins fournit un plugin trspratique pour ce genre de rapport HTML, appel le plugin HTML Publisher (voir Figure 6.20, Installerle plugin HTML Publisher). Bien que ce soit vous de vous assurer que votre build produise les bonsrapports, Jenkins peut les afficher sur la page de votre tche de build, les rendant facilement accessible tous les membres de l'quipe.

    Figure 6.20. Installer le plugin HTML Publisher

    Ce plugin est facile configurer. Allez jusqu' la section Actions la suite du build et cochez la casePublish HTML reports (voir Figure 6.21, Publier les rapports HTML). Ensuite, indiquez Jenkinsle rpertoire o ont t gnrs vos rapports HTML, une page d'index, et un titre pour votre rapport.

  • 166

    Vous pouvez aussi demander Jenkins de stocker les rapports gnrs pour chaque build, ou de neconserver que le dernier.

    Figure 6.21. Publier les rapports HTML

    Une fois que cela est fait, Jenkins affichera une icne spciale sur votre page d'accueil de votre tchede build, avec un lien vers votre rapport HTML. Sur Figure 6.22, Jenkins affiche un lien spcial sur lapage d'accueil de la tche de build pour votre rapport, vous pouvez voir les rapports easyb que nousavions configur prcdemment en action.

    Figure 6.22. Jenkins affiche un lien spcial sur la page d'accueil de la tche de build pour votre rapport

    Le plugin HTML Publisher fonctionne parfaitement pour les rapports HTML. Si, d'autre part, vousvoulez (aussi) publier des documents non-HTML, tels que des fichiers texte, PDFs, et ainsi de suite,alors le plugin DocLinks est fait pour vous. Ce plugin est semblable au plugin HTML Publisher, mais ilvous permet d'archiver la fois des rapports HTML aussi bien que des documents dans d'autres formats.Par exemple, dans Figure 6.23, Le plugin DocLinks vous permet d'archiver des documents HTML etnon-HTML, nous avons configur une tche de build qui archive la fois un document PDF et unrapport HTML. Ces deux documents seront maintenant lists sur la page d'accueil de la tache de build.

  • 167

    Figure 6.23. Le plugin DocLinks vous permet d'archiver des documents HTML et non-HTML

    6.8. Tests de performance automatiss avec JMeterLa performance applicative est un autre domaine de test important. Les tests de performance peuvent treutiliss pour vrifier beaucoup de choses, telles que la rapidit avec laquelle une application rpond auxrequtes d'un nombre donn d'utilisateurs simultans, ou comment une application ragit un nombrecroissant d'utilisateurs. De nombreuses applications ont des contrats de niveau de service (SLAs), quidfinissent contractuellement comment elles doivent ragir.

    Les tests de performance sont souvent une activit unique, prise en compte uniquement juste la findu projet ou quand les choses commencent aller mal. Nanmoins, les problmes de performance sontcomme n'importe quelle autre sorte de bug : plus tard ils sont dtects dans le processus, plus coteuxils sont corriger. Il est donc logique d'automatiser ces tests de performance et de charge, de faon pouvoir reprer les zones de dgradation des performances avant qu'elles ne sortent dans la nature.

    JMeter5 est un outil open source de test de performance et de charge. Il fonctionne en simulant la chargesur votre application, et en mesurant le temps de rponse alors que le nombre d'utilisateurs simulset les requtes augmentent. Il simule les actions d'un navigateur ou une application cliente, envoyantdes requtes de toutes sortes (HTTP, SOAP, JDBC, JMS, etc) vers votre serveur. Vous configurez unensemble de requtes envoyer votre application, ainsi que des pauses alatoires, conditions et boucles,et d'autres variantes destines mieux imiter les actions utilisateurs relles.

    JMeter s'excute comme une application Swing, dans laquelle vous pouvez configurer vos scripts detest (voir Figure 6.24, Prparer un script de test de performance dans JMeter). Vous pouvez mmeexcuter JMeter comme proxy, et utiliser votre application dans un navigateur traditionnel pour prparerune version initiale de votre script de test.

    5 http://jakarta.apache.org/jmeter/

    http://jakarta.apache.org/jmeter/http://jakarta.apache.org/jmeter/

  • 168

    Un tutoriel complet sur l'utilisation de JMeter sort du cadre de ce livre. Cependant, il est assez facile apprendre, et vous pouvez trouver de nombreux dtails sur son utilisation sur le site de JMeter. Avec unpeu de travail, vous pouvez avoir un script de test respectable et l'excuter en quelques heures.

    Ce qui nous intresse ici est le processus d'automatisation de ces tests de performance. Il y a plusieursfaons pour intgrer des tests JMeter dans votre processus de build Jenkins. Bien qu' l'criture de ceslignes, il n'y ait pas de plugin officiel JMeter pour Maven disponible dans les dpts Maven, il y aun plugin Ant. Donc, la mthode la plus simple est d'crire un script Ant pour excuter vos tests deperformance, et ensuite soit d'appeler ce script Ant directement, soit (si vous utilisez un projet Maven,et voulez excuter JMeter via Maven) d'utiliser l'intgration Ant Maven pour lancer le script Ant partirde Maven. Un simple script Ant excutant quelques tests JMeter est illustr ici :

    Cela suppose que l'installation de JMeter est disponible dans le rpertoire tools de votre projet. Placerdes outils tels que JMeter au sein de votre structure de projet est une bonne habitude, car il rendvos scripts de build plus portables et plus faciles excuter sur n'importe quelle machine, ce qui estprcisment ce dont nous avons besoin pour les excuter sur Jenkins.

  • 169

    Figure 6.24. Prparer un script de test de performance dans JMeter

    Notons que nous utilisons aussi le tag optionnel pour fournir JMeter une quantit demmoire suffisante les tests de performance sont une activit consommatrice de mmoire.

    Le script affich ici excutera les tests de performance JMeter sur une application lance. Donc vousdevez vous assurer que l'application que vous voulez tester est active et lance avant que vous lanciezvos tests. Il y a plusieurs faons de le faire. Pour des tests de performance plus lourds, vous voudrezgnralement dployer votre application sur un serveur de test avant de lancer les tests. Pour la plupartdes applications ce n'est gnralement pas trop difficile le plugin Maven Cargo, par exemple, vouspermet d'automatiser le processus de dploiement sur une varit de serveurs locaux et distants. Nousverrons aussi comment le faire dans Jenkins plus loin dans le livre.

    Sinon, si vous utilisez Maven pour une application Web, vous pouvez utiliser le plugin Jetty ou Cargopour vous assurer que l'application est dploye avant le dmarrage des tests d'intgration, et ensuiteappeler le script Ant JMeter partir de Maven pendant la phase de test d'intgration. Avec Jetty, parexemple, vous pouvez faire quelque chose comme cela :

    org.mortbay.jetty jetty-maven-plugin 7.1.0.v20100505

  • 170

    10 ${jetty.port} 60000 foo 9999 start-jetty pre-integration-test run 0 true stop-jetty post-integration-test stop ...

    Cela va dmarrer une instance de Jetty et y dployer votre application web avant les tests d'intgration,et l'arrter aprs.

    Enfin, vous devez excuter vos tests de performance JMeter pendant cette phase. Vous pouvez le faire enutilisant le maven-antrun-plugin pour lancer le script Ant que nous avons crit prcdemment pendantla phase integration-test :

    ... performance maven-antrun-plugin 1.4

  • 171

    run-jmeter integration-test run ...

    Maintenant, tout ce que vous devez faire est de lancer les tests d'intgration avec le profil performancepour que Maven excute la suite de test JMeter. Vous pouvez le faire en invoquant les phases de cyclede vie Maven integration-test ou verify:

    $ mvn verify -Pperformance

    Une fois que vous avez configur votre script de build pour grer JMeter, vous pouvez mettre en place unbuild de tests de performance dans Jenkins. Pour cela, nous allons utiliser le plugin Jenkins PerformanceTest, qui interprte les logs JMeter et peut gnrer des statistiques et des jolis graphes en utilisant cesdonnes. Donc, allez sur l'cran du gestionnaire des plugins sur votre serveur Jenkins et installez ceplugin (voir Figure 6.25, Prparer un script de tests de performance dans JMeter). Quand vous aurezinstall ce plugin, vous devrez redmarrer Jenkins.

    Figure 6.25. Prparer un script de tests de performance dans JMeter

    Une fois que le plugin est install, vous pouvez mettre en place une tche de build de performance dansJenkins. Cette tche de build sera gnralement spare des autres builds. Dans Figure 6.26, Mise en

  • 172

    place du build de performance pour s'excuter chaque nuit minuit, nous avons mis en place un buildde performance fonctionnant sur une base quotidienne, ce qui est probablement assez pour des tests derobustesse ou de performance.

    Figure 6.26. Mise en place du build de performance pour s'excuter chaque nuit minuit

    Il ne reste alors plus qu' configurer votre tche de build pour qu'elle excute vos tests de performance.Dans Figure 6.27, Les tests de performance peuvent demander de grandes quantits de mmoire, nousexcutons le build Maven que nous avons configur prcdemment. Notez que nous utilisons le champMAVEN_OPTS (accessible en cliquant sur le bouton Avanc) pour fournir suffisamment de mmoire la tche de build.

    Figure 6.27. Les tests de performance peuvent demander de grandes quantits de mmoire

    Pour mettre en place des rapports de performance, slectionnez simplement l'option PublishPerformance test result report dans la section Actions la suite du build (voir Figure 6.28, Configurerle plugin Performance dans votre tche de build). Vous devez indiquer Jenkins o se trouvent lesrsultats de test JMeter (les fichiers de sortie, pas les scripts de test). Le plugin Performance peut traiterplusieurs rsultats JMeter, donc vous pouvez mettre des caractres gnriques dans le chemin pour vousassurer que tous vos rapports JMeter seront affichs.

    Si vous prenez vos mesures de performance au srieux, alors le build doit chouer si les niveaux deservice attendus ne sont pas atteints. Dans un environnement d'intgration continue, toute mesure quin'choue pas si un critre de qualit minimum n'est pas atteint a tendance tre ignore.

    Vous pouvez configurer le plugin Performance afin de marquer un build instable ou chou si uncertain pourcentage des requtes finissent en erreur. Par dfaut, ces valeurs ne seront atteintes quedans les cas d'erreurs applicatives (i.e., bugs) ou plantages de serveur. Toutefois, vous devriez vraimentconfigurer vos scripts de test JMeter pour placer une limite sur le maximum acceptable pour le temps

  • 173

    de rponse pour vos requtes. Ceci est particulirement important si votre application a des obligationscontractuelles cet gard. Une faon de le faire avec JMeter est d'ajouter un lment Duration Assertion votre script. Cela va provoquer une erreur si une requte prend plus d'un certain temps pour s'excuter.

    Figure 6.28. Configurer le plugin Performance dans votre tche de build

    A prsent, lorsque la tche de build s'excute, le plugin Performance va produire des graphes permettantde suivre les temps de rponse globaux et le nombre d'erreurs (voir Figure 6.29, Le plugin JenkinsPerformance garde une trace des temps de rponse et des erreurs). Il y aura un graphe spar pourchaque rapport JMeter que vous avez gnr. S'il n'y a qu'un seul graphe, il sera aussi affich sur lapage d'accueil du build ; sinon vous pouvez les visualiser sur une page ddie laquelle vous pouvezaccder via le menu Performance Trend.

    Figure 6.29. Le plugin Jenkins Performance garde une trace des temps de rponse et des erreurs

  • 174

    Ce graphe vous donne un aperu de la performance dans le temps. Vous utilisez gnralement ce graphepour vous assurer que les temps de rponse moyens sont dans la limite prvue, et aussi reprer desvariations anormales des temps de rponse moyens ou maximums. Cependant, si vous avez besoin desuivre et d'isoler des problmes de performance, l'cran Performance Breakdown peut tre plus utile.A partir du rapport Performance Trend, cliquez sur le lien Last Report en haut de l'cran. Cela feraapparatre une rpartition des temps de rponse et des erreurs par demande (voir Figure 6.30, Vouspouvez aussi visualiser les rsultats de performance par requte). Vous pouvez faire la mme chosepour les builds prcdents, en cliquant sur le lien Performance Report sur la page de dtails du build.

    Avec quelques variations mineures, un script de test JMeter travaille essentiellement en simulant unnombre donn d'utilisateurs simultans. Gnralement, cependant, vous voudrez voir comment votreapplication gre des nombres diffrents d'utilisateurs. Le plugin Jenkins Performance le prend en compteassez bien, et peut traiter des graphes de plusieurs rapports JMeter. Assurez-vous juste que vous utilisezune expression gnrique quand vous dites Jenkins o se trouvent les rapports.

    Bien sr, il serait agrable de pouvoir rutiliser le mme script de test JMeter pour chaque testexcut. JMeter supporte les paramtres, donc vous pouvez facilement rutiliser le mme script JMeteravec un nombre diffrent d'utilisateurs simuls. Utilisez simplement une expression de propritdans votre script JMeter, et passez cette proprit JMeter quand vous lancez le script. Si votreproprit est nomme request.threads, alors l'expression de proprit dans votre script JMeter sera${__property(request.threads)}. Ensuite, vous pouvez utiliser l'lment dans latache Ant pour passer la proprit quand vous excutez le script. La cible Ant suivante, parexemple, excute JMeter trois fois, pour 200, 500 et 1000 utilisateurs simultans:

  • 175

    Figure 6.30. Vous pouvez aussi visualiser les rsultats de performance par requte

    6.9. A l'aide ! Mes tests sont trop lents !Un des principes fondamentaux de la conception de vos builds d'intgration continue est que la valeurde l'information d'un chec de build diminue rapidement avec le temps. En d'autres termes, plus le retourd'un chec de build met de temps vous atteindre, moins il vaut la peine, et plus dur il est corriger.

    En effet, si vos tests fonctionnels ou d'intgration prennent plusieurs heures pour s'excuter, il y a deschances qu'ils ne seront pas excuts chaque changement. Ils sont plus susceptibles d'tre programmscomme un build quotidien. Le problme est alors que beaucoup de choses peuvent intervenir en vingt-quatre heures, et, si le build quotidien choue, il sera difficile de dterminer lequel des nombreuxchangements committs sur le contrle de version pendant la journe tait responsable. C'est unproblme srieux, et pnalise la capacit de votre serveur d'intgration continue de fournir un retourrapide qui le rend utile.

    Bien sr, certains builds sont lents, par nature . Les tests de performance ou de charge rentrent dans cettecatgorie, comme d'autres builds lourds de mtriques de qualit de code pour de gros projets. Cependant,les tests d'intgration et fonctionnels ne rentrent pas dans cette catgorie. Vous devez faire tout ce quevous pouvez pour rendre ces tests aussi rapides que possible. Moins de dix minutes est probablementacceptable pour une suite complte d'intgration/fonctionnel. Deux heures ne l'est pas.

    Donc, si vous vous trouvez vous-mme devoir acclrer vos tests, voici quelques stratgies qui serontutiles, par ordre approximatif de difficult.

    6.9.1. Ajouter plus de matriel

    Quelquefois la faon la plus facile pour acclrer vos builds est de rajouter du matriel. Cela pourrait treaussi simple que de mettre jour votre serveur de build. Compar au temps et effort passs identifier etcorriger les bugs lis l'intgration, le cot d'achat d'un nouveau serveur flambant neuf est relativementfaible.

  • 176

    Une autre option est d'envisager l'utilisation d'approches virtuelles ou bases sur le cloud. Plus tarddans le livre, nous verrons comment vous pouvez utiliser des machines virtuelles VMWare ou uneinfrastructure cloud telles que Amazon Web Services (EC2) ou CloudBees pour augmenter votrecapacit de build sur une base la demande, sans avoir investir dans de nouvelles machinespermanentes.

    Cette approche peut galement impliquer la distribution de vos builds sur plusieurs serveurs. Bien quecela ne va pas en tant que tel acclrer vos tests, cela peut mener un retour plus rapide si votre serveurde build est sous forte demande, et si vos tches de build sont constamment en attente.

    6.9.2. Lancer moins de tests d'intgration/fonctionnels

    Dans de nombreuses applications, les tests d'intgration ou fonctionnels sont utiliss par dfaut commemoyen standard pour tester presque tous les aspects du systme. Cependant, les tests d'intgration etfonctionnels ne sont pas le meilleur moyen de dtecter et d'identifier les bugs. En raison du grand nombrede composants impliqus dans un test typique de bout en bout, il peut tre trs difficile de savoir os'est produit l'erreur. En outre, avec autant de pices changeant, il est extrmement difficile, si ce n'esttotalement irralisable, de couvrir l'ensemble des chemins possibles travers l'application.

    Pour cette raison, dans la mesure du possible, vous devriez prfrer les tests unitaires rapides auxtests d'intgration et fonctionnels beaucoup plus lents. Quand vous tes confiants dans le fait que lescomposants individuels fonctionnent correctement, vous pouvez complter le tableau par quelques testsde bout en bout qui passent par des cas d'utilisation communs du systme, ou des cas d'utilisation quiont caus des problmes par le pass. Cela va garantir que les composants s'embotent correctement, cequi est, aprs tout, ce que les tests d'intgration sont supposs faire. Mais prfrez, dans la mesure dupossible, les tests unitaires aux tests plus complets. Cette stratgie est probablement l'approche la plusviable pour maintenir votre retour rapide, mais elle ncessite une certaine discipline et des efforts.

    6.9.3. Excutez vos tests en parallle

    Si vos tests fonctionnels prennent deux heures pour s'excuter, il est peu probable qu'ils aient tous besoinde s'excuter la suite. Il est aussi peu probable qu'ils consomment toute la CPU disponible sur votremachine de build. Alors dcouper vos tests d'intgration en petits lots et les excuter en parallle abeaucoup de sens.

    Il y a plusieurs stratgies que vous pouvez essayer, et votre choix va probablement dpendre de lanature de votre application. Une approche, par exemple, est de mettre en place plusieurs tches debuild pour excuter des sous ensembles diffrents de vos tests fonctionnels, et de lancer ces tches enparallle. Jenkins vous permet d'agrger les rsultats de test. C'est une bonne faon de tirer avantagede l'architecture de build distribue pour acclrer vos builds encore plus. Le point essentiel de cettestratgie est la capacit d'excuter des sous-ensembles de vos tests en isolation, ce qui peut demanderune certaine restructuration.

    A un plus bas niveau, vous pouvez aussi excuter vos tests en parallle au niveau des scripts de build.Comme nous avons vu prcdemment, TestNG et les versions les plus rcentes de JUnit supportent tous

  • 177

    les deux l'excution de tests en parallle. Nanmoins, vous devrez vous assurer que vos tests peuvent treexcuts simultanment, ce qui peut ncessiter une restructuration. Par exemple, les fichiers communsou des variables d'instance partages vont dans ce cas causer des problmes.

    En gnral, vous devez tre prudent sur les interactions entre vos tests. Si vos tests web dmarrent unserveur Web intgr, comme Jetty, par exemple, vous devez vous assurer que le port utilis est diffrentpour chaque ensemble de tests simultans.

    Nanmoins, si vous pouvez le faire fonctionner pour votre application, excuter vos tests en parallleest un des moyens les plus efficaces pour acclrer vos tests.

    6.10. ConclusionL'automatisation des tests est un lment essentiel de tout environnement d'intgration continue, et doittre pris trs au srieux. Comme dans d'autres domaines dans l'intgration continue, et peut-tre plusencore ici, le retour d'information est roi, il est donc important de s'assurer que vos tests s'excutentrapidement, y compris les tests d'intgration et fonctionnels.

  • Chapter 7. Scuriser Jenkins7.1. Introduction

    Jenkins supporte plusieurs modles de scurit, et peut s'intgrer avec diffrents gestionnairesd'utilisateurs. Dans les petites organisations, o les dveloppeurs travaillent proches les uns des autres,la scurit de votre machine Jenkins n'est peut-tre pas un gros problme vous pourriez juste vouloirviter que des utilisateurs non identifis n'altrent vos configurations de tches de build. Pour de plusimportantes organisations, avec de multiples quipes, une approche plus stricte pourrait tre ncessaire,dans laquelle seuls les membres de l'quipe et les administrateurs systmes ont les droits pour modifierla configuration des tches de build. Et dans des situations o Jenkins serait expos une audienceplus large, comme un site web interne d'une entreprise, ou mme sur Internet, certaines tches debuild pourraient tre visibles tous les utilisateurs alors que d'autres ncessiteraient d'tre caches auxutilisateurs non autoriss.

    Dans ce chapitre, nous regarderons comment configurer diffrentes configurations de scurit dansJenkins, pour diffrents environnements et circonstances.

    7.2. Activer la scurit dans Jenkins

    Configurer une scurit basique dans Jenkins est assez simple. Allez sur la page de configurationprincipale et slectionnez la case cocher Activer la scurit (voir Figure 7.1, Activer la scuritdans Jenkins). Ceci affiche plusieurs options que nous allons expliquer en dtails dans ce chapitre. Lapremire section, Domaine de scurit, dfinit o Jenkins regardera pendant l'authentification, et inclutdes options telles que l'utilisation d'utilisateurs stocks dans un serveur LDAP, en utilisant le compteutilisateur Unix sous-jacent (en supposant, bien sr, que Jenkins est excut sur une machine Unix), ouutilisant une simple base de donnes embarque gre par Jenkins.

    La seconde section, Autorisations, dtermine ce que les utilisateurs peuvent faire une fois qu'ils sontconnects. Cela va de simples options comme "Tout le monde a accs toutes les fonctionnalits"ou "Les utilisateurs connects peuvent tout faire" des rles plus sophistiqus ou des politiquesd'autorisations par projet.

  • 180

    Figure 7.1. Activer la scurit dans Jenkins

    la fin de ce chapitre, nous regarderons comment configurer la scurit Jenkins pour un certain nombrede scnarii courants.

    7.3. Scurit simple dans JenkinsLe modle de scurit le plus simple disponible dans Jenkins permet aux utilisateurs authentifis defaire tout ce qu'ils veulent, alors que les utilisateurs non authentifis auront seulement une vue en lectureseule de leurs tches de build. C'est super pour les petites quipes - les dveloppeurs peuvent grer lestches de build, alors que les autres utilisateurs (testeur, analyste mtier, responsable de projet, etc.)peuvent accder aux tches de build pour voir l'tat du projet. En effet, certaines tches pourraient mmetre configures uniquement dans ce but, affichant les rsultats de tests d'acceptation automatiss ou desmtriques de qualit de code, par exemple.

    Vous pouvez mettre en place ce type de configuration en choisissant Les utilisateurs connects peuventtout faire dans la section Autorisations. Il y a plusieurs faons dans Jenkins pour authentifier lesutilisateurs (voir Section 7.4, Domaines de scurit Identifier les utilisateurs Jenkins), mais pourcet exemple, nous allons utiliser l'option la plus simple, qui est d'utiliser la base de donnes intgre Jenkins (voir Section 7.4.1, Utiliser la base de donnes intgre Jenkins). C'est la configurationillustre dans Figure 7.1, Activer la scurit dans Jenkins.

    Assurez-vous de cocher l'option "Autoriser les utilisateurs se connecter". Cette option affichera unlien Se connecter en haut de l'cran permettant aux utilisateurs de crer leurs propres comptes (voirFigure 7.2, La page de connexion Jenkins). C'est une bonne ide pour les dveloppeurs d'utiliser icileur nom d'utilisateur de gestionnaire de sources : dans ce cas, Jenkins sera capable de retrouver quelsutilisateurs ont contribu aux changements qui ont dclench un build particulier.

  • 181

    Figure 7.2. La page de connexion Jenkins

    Cette approche est videmment un peu trop simple pour beaucoup de situations il est utile pourles petites quipes de travailler en forte proximit, o le but est de connaitre le changement de qui adclench (ou cass) un build particulier, plutt que de grer l'accs de faon plus restrictive. Dans lessections suivantes, nous discuterons de deux aspects orthogonaux de la scurit Jenkins : identifier vosutilisateurs (domaines de scurit) et dterminer ce qu'ils sont autoriss faire (Autorisation).

    7.4. Domaines de scurit Identifier les utilisateursJenkinsJenkins vous permet d'identifier et de grer les utilisateurs de plusieurs faons, depuis une simple basede donnes intgre pour les petites quipes jusqu' l'intgration avec des annuaires d'entreprise, avecde nombreuses autres options entre les deux.

    7.4.1. Utiliser la base de donnes intgre Jenkins

    Le moyen le plus simple pour grer des comptes utilisateurs dans Jenkins est d'utiliser la base dedonnes interne de Jenkins. C'est une bonne option si vous voulez garder les choses simples, car peude configuration est ncessaire. Les utilisateurs qui ont besoin de se connecter au serveur Jenkinspeuvent s'enregistrer et crer un compte par eux-mmes, et, en fonction du modle de scurit choisi,un administrateur peut ensuite dcider ce que ces utilisateurs sont autoriss faire.

    Jenkins ajoute automatiquement tout utilisateur de gestionnaire de sources cette base de donnes dsqu'un changement est effectu dans le code source surveill par Jenkins. Ces noms d'utilisateurs sontutiliss principalement pour enregistrer le responsable de chaque tche de build. Vous pouvez voir laliste des utilisateurs actuellement connus en cliquant sur l'entre de menu Personnes (voir Figure 7.3,La liste des utilisateurs connus de Jenkins). Ici, vous pouvez visualiser les utilisateurs que Jenkinsconnat actuellement, et aussi voir le dernier projet dans lequel ils ont committ. Notez que cette liste

  • 182

    contient la liste de tous les utilisateurs avoir jamais committ dans les projets que Jenkins surveille ils pourraient ne pas tre (et en gnral ne sont pas) tous des utilisateurs actifs de Jenkins capablesde se connecter sur le serveur Jenkins.

    Figure 7.3. La liste des utilisateurs connus de Jenkins

    Si vous cliquez sur un utilisateur de cette liste, Jenkins vous emmne sur une page affichant diffrentesinformations propos de cet utilisateur, incluant son nom complet et les tches de build auxquelles il acontribu (voir Figure 7.4, Afficher les builds auxquels un utilisateur participe). De l, vous pouvezaussi modifier ou complter les dtails propos de cet utilisateur, comme son mot de passe ou sonadresse email.

    Figure 7.4. Afficher les builds auxquels un utilisateur participe

  • 183

    Un utilisateur apparaissant sur cette liste ne peut pas ncessairement se connecter Jenkins. Pour pouvoirse connecter, l'utilisateur doit avoir un mot de passe configur. Il y a essentiellement deux faons defaire cela. Si vous avez configur l'option "Autoriser les utilisateurs s'enregistrer", les utilisateurspeuvent simplement se connecter avec leur nom d'utilisateur SCM et fournir leur adresse email et leurmot de passe (voir Section 7.3, Scurit simple dans Jenkins). Autrement, vous pouvez activer unutilisateur en cliquant sur l'option de menu Configurer dans l'cran de dtails utilisateur, et fournir uneadresse email et un mot de passe vous-mme (voir Figure 7.5, Crer un nouveau compte utilisateuren s'enregistrant).

    Figure 7.5. Crer un nouveau compte utilisateur en s'enregistrant

    Il est utile de noter que, si vos adresses email sont synchronises avec vos noms d'utilisateurs de contrlede version (par exemple, si vous travaillez chez acme.com, et que l'utilisateur joe dans votre systme decontrle de version a une adresse email joe@acme.com), vous pouvez faire que Jenkins drive l'adresseemail de l'utilisateur en ajoutant un suffixe que vous configurez dans la section Notification Email (voirFigure 7.6, Synchroniser les adresses email). Si vous avez effectu ce type de configuration, vousn'avez pas besoin de spcifier l'adresse email pour les nouveaux utilisateurs moins qu'elle ne respectepas cette convention.

    Figure 7.6. Synchroniser les adresses email

  • 184

    Une autre faon de grer les utilisateurs courants actifs (ceux qui peuvent vraiment se connecter Jenkins) s'effectue via le lien Grer les utilisateurs sur la page de configuration principale de Jenkins(voir Figure 7.7, Vous pouvez aussi grer les utilisateurs Jenkins depuis la page de configurationJenkins).

    Figure 7.7. Vous pouvez aussi grer les utilisateurs Jenkins depuis la page de configuration Jenkins

    D'ici, vous pouvez voir et diter les utilisateurs qui peuvent se connecter Jenkins (voir Figure 7.8,La base de donnes des utilisateurs de Jenkins). Cela inclut la fois les utilisateurs qui se sontenregistrs manuellement (si cette option a t active) et les utilisateurs SCM que vous avez activs enleur configurant un mot de passe. Vous pouvez aussi diter des informations utilisateur (par exemple,modifier leur adresse email ou rinitialiser leur mot de passe), ou mme les supprimer de la liste desutilisateurs actifs. Procder ainsi ne les enlvera pas de la liste globale des utilisateurs (leurs nomsapparatront toujours dans l'historique de build, par exemple), mais ils ne seront plus capables de seconnecter au serveur Jenkins.

    Figure 7.8. La base de donnes des utilisateurs de Jenkins

    La base de donnes interne de Jenkins est suffisante pour de nombreuses quipes et organisations.Toutefois, pour des organisations plus importantes, cela peut devenir fastidieux et rptitif de grer ungrand nombre d'utilisateurs la main. Et plus particulirement encore si cette information existe djquelque part. Dans les sections suivantes, nous regarderons comment brancher Jenkins avec d'autressystmes de gestion utilisateurs, comme des annuaires LDAP ou des utilisateurs et groupes Unix.

  • 185

    7.4.2. Utiliser un annuaire LDAP

    Plusieurs organisations utilisent des annuaires LDAP pour stocker des comptes et mots de passe traversdiffrentes applications. Jenkins s'intgre bien avec LDAP, sans ncessiter de plugin spcial. Il peutauthentifier les utilisateurs en utilisant l'annuaire LDAP, vrifier l'appartenance un groupe, et rcuprerles adresses email des utilisateurs authentifis.

    Pour intgrer Jenkins votre annuaire LDAP, slectionnez simplement LDAP dans la sectionDomaine de scurit, et remplissez les dtails concernant votre serveur LDAP (voir Figure 7.9,Configurer LDAP dans Jenkins). Le champ le plus important est le serveur de l'annuaire. Si vousutilisez un port non standard, vous devrez aussi l'indiquer (par exemple, ldap.acme.org:1389). Sivous utilisez LDAPS, vous devrez aussi le spcifier (par exemple, ldaps://ldap.acme.org)

    Si votre serveur autorise la connexion anonyme, cela vous suffira probablement pour dmarrer. Sinon,vous pouvez utiliser les options avances pour paramtrer plus finement votre configuration.

    La plupart des champs Avancs peuvent sans problme tre laisss vides moins que vous n'ayez unebonne raison de les changer. Si votre annuaire est extrmement volumineux, vous devriez spcifiez unevaleur de DN racine (e.g., dc=acme, dc=com) et/ou une base de recherche utilisateur et groupe (e.g.,ou=people) pour rduire la porte des requtes utilisateur. Ceci n'est habituellement pas ncessaire moins que vous ne remarquiez des problmes de performance. Ou, si votre serveur n'autorise pas lesconnexions anonymes, vous devrez fournir un DN et un mot de passe de gestionnaire, afin que Jenkinspuisse se connecter au serveur pour excuter ses requtes.

    Figure 7.9. Configurer LDAP dans Jenkins

    Une fois que vous avez configur votre serveur LDAP comme domaine de scurit, vous pouvezconfigurer votre modle de scurit comme dcrit prcdemment. Quand les utilisateurs se connecteront Jenkins, ils seront authentifis sur l'annuaire LDAP.

  • 186

    Vous pouvez aussi utiliser des groupes LDAP, bien que la configuration ne soit pas immdiatementvidente. Supposons que vous ayez dfini un group appel JenkinsAdmin dans votre annuaire LDAP,avec un DN cn=JenkinsAdmin, ou-Groups, dc=acme, dc=com. Pour rfrencer ce groupe dansJenkins, vous devez prendre le nom commun (cn) en majuscules, et le prfixer avec ROLE_. Ainsicn=JenkinsAdmin devient ROLE_JENKINSADMIN. Vous pouvez voir un exemple de groupes LDAPutiliss de cette faon dans Figure 7.10, Utiliser des groupes LDAP dans Jenkins.

    Figure 7.10. Utiliser des groupes LDAP dans Jenkins

    7.4.3. Utiliser Microsoft Active Directory

    Microsoft Active Directory est un logiciel d'annuaire largement utilis dans les architectures Microsoft.Bien qu'Active Directory fournisse un service LDAP, il peut tre compliqu configurer, et il est plussimple de demander Jenkins de parler directement au serveur Active Directory. Heureusement, il ya un plugin pour a.

    Le plugin Active Directory de Jenkins vous permet de configurer Jenkins pour authentifier lesutilisateurs via un serveur Microsoft Active Directory. Vous pouvez la fois authentifier les utilisateurs,et rcuprer leurs groupes pour la matrice d'autorisations gnrale ou par projet. Notez que, l'inversed'une intgration LDAP conventionnelle (voir Section 7.4.2, Utiliser un annuaire LDAP), il n'est pasncessaire de prfixer les groupes avec ROLE_ vous pouvez utiliser l'annuaire des groupes ActiveDirectory (comme Administrateur de Domaine).

    Pour configurer le plugin, vous devez fournir le nom de domaine complet de votre serveur ActiveDirectory. Si vous avez plus d'un domaine, vous pouvez fournir une liste spare par des virgules. Sivous fournissez le nom de la fort (par exemple acme.com au lieu de europe.acme.com), alors larecherche sera faite partir du catalogue global. Notez que si vous faites cela sans spcifier le bind DN(voir ci-dessous), l'utilisateur devra se connecter en tant que europe\joe ou joe@europe.

    Les options avances vous permettent de spcifier un nom de site (pour amliorer les performances enrestreignant les contrleurs de domaine que Jenkins requte), et un DN de liaison et un mot de passe,ce qui peut tre pratique si vous vous connectez une fort multidomaines. Vous devez fournir desvaleurs de DN de liaison et de mot de passe valides, que Jenkins puisse utiliser pour se connecter votre

  • 187

    serveur afin qu'il tablisse l'identit complte de l'utilisateur en cours d'authentification. De cette faon,l'utilisateur peut taper simplement jack ou jill, et faire que le systme retrouve automatiquementqu'ils sont jack@europe.acme.com ou jack@asia.acme.com. Vous devez fournir le nom principalcomplet avec le nom de domaine, tel que admin@europe.acme.com, ou un nom distinctif de style LDAP,tel que CN=Administrator,OU=europe,DC=acme,DC=com.

    Une autre bonne chose propos de ce plugin est qu'il fonctionne la fois dans un environnementWindows et un environnement Unix. Donc si Jenkins fonctionne sur un serveur Unix, il pourra quandmme effectuer les authentifications via un service Microsoft Active Directory d'une autre machine.

    Plus prcisment, si Jenkins s'excute sur une machine Windows et que vous ne spcifiez pas dedomaine, cette machine doit tre un membre du domaine auprs duquel vous souhaitez vous authentifier.Jenkins utilisera ADSI pour retrouver tous les dtails, aucune configuration additionnelle n'est doncncessaire.

    Sur une machine non Windows (ou si vous spcifiez un ou plusieurs domaines), vous devez dire Jenkins le nom du domaine Active Directory auprs duquel s'authentifier. Jenkins utilise alors lesenregistrements DNS SRV et le service LDAP d'Active Directory pour authentifier les utilisateurs.

    Jenkins peut dterminer les groupes Active Directory auxquels l'utilisateur appartient. Vous pouvezdonc les utiliser dans votre stratgie d'autorisations. Par exemple, vous pouvez utiliser ces groupes dansla scurit base sur une matrice, ou autoriser les "Administrateurs de domaine" administrer Jenkins.

    7.4.4. Utiliser les utilisateurs et les groupes Unix

    Si vous excutez Jenkins sur une machine Unix, vous pouvez aussi demander Jenkins d'utiliser lescomptes utilisateur et groupes dfinis sur cette machine. Dans ce cas, les utilisateurs se connecteront Jenkins en utilisant leurs comptes et mots de passe Unix. On utilise alors le systme PluggableAuthentication Modules (PAM), et cela fonctionne aussi bien avec NIS.

    Dans sa forme la plus basique, c'est un peu rbarbatif, parce que cela ncessite de crer et de configurerdes comptes utilisateurs pour chaque nouvel utilisateur Jenkins. Ce n'est vritablement utile que si cescomptes ncessitent d'tre mis en place pour d'autres besoins.

    7.4.5. Dlguer au conteneur de Servlet

    Une autre faon d'identifier les utilisateurs Jenkins est de laisser le conteneur de Servlet le faire pourvous. Cette approche est utile si vous excutez Jenkins dans un conteneur de Servlet comme Tomcatou GlassFish, et que vous avez dj un moyen tabli pour intgrer le conteneur de Servlet avec votreannuaire utilisateur. Tomcat, par exemple, vous permet d'authentifier les utilisateurs par rapport une base de donnes relationnelle (en utilisant du JDBC direct ou une DataSource), JNDI, JAAS, oufichier de configuration XML. Vous pouvez aussi utiliser les rles dfinis dans l'annuaire utilisateurdu conteneur de Servlet afin de les utiliser pour les stratgies d'autorisation par matrice ou base surle projet.

  • 188

    Dans Jenkins, c'est facile configurer slectionnez simplement cette option dans la section Domainede scurit (voir Figure 7.11, Slectionner le domaine de scurit). Une fois que vous avez fait cela,Jenkins laissera le serveur s'occuper de tout.

    Figure 7.11. Slectionner le domaine de scurit

    7.4.6. Utiliser Atlassian Crowd

    Si votre organisation utilise les produits Atlassian comme JIRA et Confluence, vous pouvez aussiutiliser Crowd. Crowd est une application commerciale de gestion d'identit et de Single-Sign On (SSO)d'Atlassian qui vous permet de grer des comptes utilisateur unique travers diffrents produits. Vousgrez une base de donnes interne d'utilisateurs, de groupes et de rles, et vous vous intgrez avec desannuaires externes comme des annuaires LDAP ou des magasins utilisateur spcifiques.

    En utilisant le plugin Jenkins Crowd, vous pouvez utiliser Atlassian Crowd comme source de vosutilisateurs et groupes Jenkins. Avant de commencer, vous devez configurer une nouvelle applicationdans Crowd (voir Figure 7.12, Utiliser Atlassian Crowd comme domaine de scurit Jenkins).Configurez simplement une nouvelle Application Gnrique appele jenkins (ou quelque chose dumme genre), et avancez d'onglet en onglet. Dans l'onglet Connexions, vous devez fournir l'adresseIP de votre serveur Jenkins. Ensuite, vous devez indiquer l'annuaire Crowd que vous utiliserez pourrcuprer les comptes utilisateurs Jenkins et informations de groupes. Enfin, vous devrez dire Crowdquels utilisateurs de ces annuaires peuvent se connecter Jenkins. Une option est d'autoriser tous lesutilisateurs s'authentifier, et laisser Jenkins grer les dtails. Sinon, vous pouvez lister les groupesutilisateur Crowd autoriss se connecter Jenkins.

  • 189

    Figure 7.12. Utiliser Atlassian Crowd comme domaine de scurit Jenkins

    Une fois que vous avez configur cela, vous devez installer le plugin Jenkins Crowd, comme vous lefaites habituellement via le gestionnaire de plugin de Jenkins. Une fois install le plugin et Jenkinsredemarr, vous pouvez dfinir Crowd comme domaine de scurit dans l'cran de configurationprincipal de Jenkins (voir Figure 7.13, Utiliser Atlassian Crowd comme domaine de scurit Jenkins).

    Figure 7.13. Utiliser Atlassian Crowd comme domaine de scurit Jenkins

    Avec ce plugin install et configur, vous pouvez utiliser les utilisateurs et les groupes de Crowdpour toutes les stratgies d'autorisation que nous avons prsentes prcdemment dans ce chapitre. Parexemple, dans Figure 7.14, Utiliser les groupes Atlassian Crowd dans Jenkins, nous utilisons desgroupes utilisateurs dfinis dans Crowd pour configurer une scurit base sur la matrice dans l'cranprincipal de configuration.

  • 190

    Figure 7.14. Utiliser les groupes Atlassian Crowd dans Jenkins

    7.4.7. S'intgrer avec d'autres systmes

    En plus des stratgies d'authentification discutes ici, il y a un certain nombre d'autres plugins permettant Jenkins d'effectuer l'authentification via d'autres systmes. Au moment de l'criture de ces lignes, ceciinclut Central Authentication Service (CAS) un outil open source de single sign-on et le serveurCollabnet Source Forge Enterprise Edition (SFEE).

    Si aucun plugin n'est disponible, vous pouvez aussi crire votre propre script d'authentification. Pourfaire cela, vous devez installer le plugin Script Security Realm. Une fois que vous avez install le scriptet redmarr Jenkins, vous pouvez crire deux scripts dans votre langage de scripting favori. Un scriptauthentifie l'utilisateur, tandis que l'autre dtermine les groupes d'un utilisateur donn (voir Figure 7.15,Utiliser des scripts personnaliss pour grer l'authentification).

    Figure 7.15. Utiliser des scripts personnaliss pour grer l'authentification

    Avant d'invoquer le script d'authentification, Jenkins positionne deux variables d'environnement :U, contenant le nom d'utilisateur, et P, contenant le mot de passe. Ce script utilise ces variables

  • 191

    d'environnement pour authentifier le nom d'utilisateur et le mot de passe spcifi, en retournant 0 en casde russite, et une autre valeur sinon. Si l'authentification choue, la sortie du processus sera renvoyedans le message d'erreur affich l'utilisateur. Voici un simple script script d'authentification Groovy :

    def env = System.getenv()def username = env['U']def password = env['P']

    println "Authenticating user $username"

    if (authenticate(username, password)) { System.exit 0} else { System.exit 1}

    def authenticate(def username, def password) { def userIsAuthenticated = true // Authentication logic goes here return userIsAuthenticated}

    Ce script est suffisant si tout ce que vous avez faire est de grer une authentification basique sansgroupes. Si vous voulez utiliser des groupes de votre source d'authentification personnalise dans vosautorisations matricielles ou projet (voir Section 7.5, Autorisation Qui peut faire quoi), vous pouvezcrire un second script, qui dtermine les groupes pour un utilisateur donn. Ce script utilise la variabled'environnement U pour dterminer quel utilisateur essaie de se connecter, et affiche une liste de groupespare par des virgules pour cet utilisateur sur la sortie standard. Si vous n'aimez pas les virgules, vouspouvez redfinir le caractre de sparation dans la configuration. Voici un simple script Groovy pourfaire cela :

    def env = System.getenv()def username = env['U']

    println findGroupsFor(username)

    System.exit 0

    def findGroupsFor(def username) { return "admin,game-of-life-developer"}

    Ces deux scripts doivent renvoyer 0 lorsqu'ils sont appels pour qu'un utilisateur soit authentifi.

    7.5. Autorisation Qui peut faire quoiUne fois que vous avez dfini comment identifier vos utilisateurs, vous devez dcider ce qu'ils sontautoriss faire. Jenkins supporte diffrentes stratgies dans ce domaine, allant d'une simple approcheo un utilisateur connect peut faire n'importe quoi des stratgies impliquant des rles plus prcis etdes authentifications par projet.

  • 192

    7.5.1. Scurit base sur une matrice

    Laisser les utilisateurs connects faire n'importe quoi est certainement flexible, et pourrait suffire pourune petite quipe. Pour des quipes plus importantes ou multiples, ou des cas o Jenkins est utilis endehors d'un environnement de dveloppement, une approche plus sophistique est gnralement requise.

    La scurit base sur matrice est une approche plus labore, o diffrents utilisateurs se voient attribuerdiffrents droits, en utilisant une approche base sur les rles.

    7.5.1.1. Mettre en place la scurit base sur une matrice

    La premire tape dans la configuration de la scurit base sur une matrice dans Jenkins est de crerun administrateur. C'est une tape essentielle, et elle doit tre effectue avant toutes les autres. Votreadministrateur peut tre un utilisateur existant, ou un cr spcialement dans ce but. Si vous voulez crerun utilisateur administrateur ddi, crez le simplement en vous enregistrant de la faon habituelle (voirFigure 7.2, La page de connexion Jenkins). Il n'est pas ncessaire qu'il soit associ un utilisateurSCM.

    Une fois que votre utilisateur administrateur est prt, vous pouvez activer la scurit base sur unematrice en slectionnant Scurit base sur une matrice dans la section Autorisations de la page deconfiguration principale. Jenkins affichera un tableau contenant les utilisateurs autoriss, et des cases cocher correspondant aux diffrentes permissions que vous pouvez affecter ces utilisateurs (voirFigure 7.16, Scurit base sur une matrice).

    Figure 7.16. Scurit base sur une matrice

    L'utilisateur spcial anonyme est toujours prsent dans le tableau. Cet utilisateur reprsente lesutilisateurs non authentifis. Typiquement, vous ne donnez que des droits limits aux utilisateurs nonauthentifis, comme des accs en lecture seule, ou pas d'accs du tout (comme montr dans Figure 7.16,Scurit base sur une matrice).

    La premire chose que vous devez savoir faire maintenant est de donner les droits d'administration votre administrateur. Ajoutez cet utilisateur d'administration dans le champ Utilisateur/groupe ajouter et cliquez sur Ajouter. Votre administrateur apparatra alors dans la matrice de permissions.

  • 193

    Maintenant assurez-vous d'accorder toutes les permissions cet utilisateur (voir Figure 7.17,Configurer un administrateur), et sauvez votre configuration. Vous devriez prsent tre capable devous connecter avec votre compte utilisateur administrateur (si vous n'tes pas dj connect avec cecompte) et continuer configurer vos autres utilisateurs.

    Figure 7.17. Configurer un administrateur

    7.5.1.2. Configurer plus finement les permissions utilisateurs

    Une fois que vous avez configur votre compte administrateur, vous pouvez ajouter d'autres utilisateursayant besoin d'accder votre instance Jenkins. Ajoutez simplement les noms d'utilisateur et cochez lespermissions que vous voulez leur accorder (voir Figure 7.18, Configurer les autres utilisateurs). Sivous utilisez un serveur LDAP ou des utilisateurs ou groupes Unix comme schma d'authentificationsous-jacent (voir Section 7.4.2, Utiliser un annuaire LDAP), vous pouvez aussi configurer lespermissions pour des groupes d'utilisateurs.

    Figure 7.18. Configurer les autres utilisateurs

    Vous pouvez accorder diffrentes permissions, qui sont organises en plusieurs groupes : Global,Esclave, Job, Lancer, Voir et Gestion de version. La plupart des permissions sont assez videntes, maiscertaines ncessitent un peu plus d'explication. Les permissions individuelles sont comme suit :

    GlobalCe groupe couvre des permissions basiques sur l'ensemble du systme :

    AdministrerPermet un utilisateur de faire des modifications de configuration l'ensemble du systmeou autres oprations sensibles, par exemple dans les pages de configuration principales deJenkins. Ceci devrait tre rserv l'administrateur Jenkins.

  • 194

    LireCette permission fournit un accs en lecture seule pratiquement toutes les pages de Jenkins.Si vous voulez que les utilisateurs anonymes puissent voir les tches librement, mais qu'ilsne puissent pas les modifier ou les dmarrer, donnez le droit Lire l'utilisateur spcialanonyme. Sinon, enlevez simplement cette permission l'utilisateur Anonyme. Et si vousvoulez que tous les utilisateurs authentifis puissent voir les tches de build, ajoutez alorsun utilisateur spcial authenticated, et donnez lui la permission Global/Lire.

    EsclaveCe groupe couvre des permissions propos de noeuds de constructions, ou esclaves :

    ConfigurerCrer ou configurer de nouveaux noeuds de construction.

    SupprimerSupprimer des noeuds de construction.

    JobCe group couvre des permissions lies aux tches :

    CrerCrer une nouvelle tche de build.

    SupprimerSupprimer une tche de build existante.

    ConfigurerMettre jour la configuration de tches de build existantes.

    LireVoir des tches de build.

    BuildDmarrer une tche de build.

    Espace de travailVoir et tlcharger le contenu de l'espace de travail pour une tche de build. Rappelez-vous,l'espace de travail contient le code source et les artefacts, donc si vous voulez protger cesderniers d'un accs gnral, vous devriez enlever cette permission.

    ReleaseDmarrer une release Maven pour un projet configur avec le plugin M2Release.

    LancerCe groupe couvre les droits relatifs des builds spcifiques de l'historique des builds :

  • 195

    SupprimerSupprimer un build de l'historique de build.

    Mettre jourMettre jour la description et d'autres proprits d'un build dans l'historique de build. Cecipeut tre utile si un utilisateur veut laisser une note sur la cause des checs de build, parexemple.

    VoirCe groupe couvre des vues de gestion :

    CrerCrer une nouvelle vue.

    SupprimerSupprimer une vue existante.

    ConfigurerConfigurer une vue existante.

    Gestion de versionPermissions relatives votre systme de contrle de version :

    TagCrer un nouveau tag dans le dpt de code source pour un build donn.

    AutresIl peut y avoir d'autres permissions disponibles, en fonction des plugins installs. Une permissionutile est :

    PromouvoirSi le plugin Promoted Builds est install, cette permission permet aux utilisateurs depromouvoir manuellement un build.

    7.5.1.3. A l'aide ! Je me suis verrouill tout seul !

    Il pourrait arriver que, pendant ce processus, vous vous bloquiez tout seul l'accs Jenkins. Ceci peutarriver si, par exemple, vous sauvez la configuration matricielle sans avoir correctement configur votreadministrateur. Si cela arrive, ne paniquez pas il y a une correction simple, du moment que vousavez accs au rpertoire racine de Jenkins. Ouvrez simplement le fichier config.xml la racine durpertoire de Jenkins. Il contiendra quelque chose de ce genre :

    1.391 2

  • 196

    NORMAL true ...

    La chose rechercher est l'lement . Pour restaurer votre accs Jenkins, changezcette valeur false, et redmarrez votre serveur. Vous pourrez alors nouveau accder Jenkins, etmettre en place votre configuration de scurit correctement.

    7.5.2. Scurit base sur le projet

    La scurit base sur le projet vous permet d'utiliser le modle de scurit matricielle dont vous venonsde discuter, et l'appliquer des projets individuels. Non seulement vous pouvez assigner des rlesglobaux vos utilisateurs, mais vous pouvez aussi configurer des droits plus spcifiques certainsprojets en particulier.

    Pour activer la scurit de niveau projet, slectionnez Stratgie d'autorisation matricielle base sur lesprojets dans la section Autorisations de l'cran de configuration principal (voir Figure 7.19, Scuritbase sur le projet). Ici, vous pouvez configurer des droits par dfaut pour les utilisateurs et les groupes,comme nous l'avons vu dans la scurit base sur une matrice (voir Section 7.5.1, Scurit base surune matrice).

    Figure 7.19. Scurit base sur le projet

    Ce sont les permissions par dfaut appliquer tous les projets qui n'ont pas t spcifiquementconfigurs. Toutefois, quand vous utilisez la scurit base sur le projet, vous pouvez aussi positionnerdes permissions spcifiques au projet. Pour faire cela, slectionnez Activer la scurit base sur leprojet dans l'cran de configuration du projet (voir Figure 7.20, Configurer la scurit base sur leprojet). Jenkins affichera un tableau de permissions spcifiques au projet. Vous pouvez configurerces permissions pour diffrents utilisateurs et groupes comme dans la page de configuration globales.Ces permissions seront ajoutes aux permissions globales pour produire un ensemble de permissionsspcifiquement applicables ce projet.

  • 197

    Figure 7.20. Configurer la scurit base sur le projet

    Comprendre comment cela fonctionne est plus facile avec quelques exemples pratiques. DansFigure 7.19, Scurit base sur le projet, par exemple, aucune permission n'a t donne l'utilisateuranonyme. Donc, par dfaut, toutes les tches de build resteront invisibles jusqu' ce que l'utilisateur seconnecte. Toutefois, nous utilisons une scurit base sur le projet, nous pouvons donc redfinir celaprojet par projet. Dans Figure 7.20, Configurer la scurit base sur le projet, par exemple, nous avonsconfigur le projet game-of-life pour qu'il offre l'accs en lecture seule l'utilisateur spcial anonyme.

    Quand vous aurez sauv cette configuration, les utilisateurs non authentifis pourront voir le projetgame-of-life en mode lecture seule (voir Figure 7.21, Voir un projet). Le mme principe s'appliqueavec toutes les permissions spcifiques au projet.

    Figure 7.21. Voir un projet

    Notez que les permissions sont cumulatives l'criture de ces lignes, il n'y a pas de moyen d'enleverune permission globale pour un projet particulier. Par exemple, si l'utilisateur anonyme a l'accsen lecture seule au niveau global, vous ne pouvez pas lui enlever pour un projet individuel. Doncquand vous utilisez la scurit base sur le projet, utilisez la matrice globale au systme pour dfinir

  • 198

    des permissions par dfaut minimales travers tous vos projets, et configurez les projets avec desautorisations additionnelles spcifiques au projet.

    Il y a plusieurs approches pour grer les permissions de projet, et elles dpendent autant sur la cultureorganisationnelle que sur des considrations techniques. Une stratgie courante est d'autoriser lesmembres de l'quipe avoir l'accs complet leurs propres projets, et l'accs en lecture seule aux autresprojets. Le plugin Extended Read Permission est une extension utile avoir dans ce scnario. Ce pluginvous permet d'offrir aux utilisateurs d'autres quipes une vue en lecture seule de la configuration de votreprojet, sans avoir modifier quoi que ce soit (voir Figure 7.22, Configurer les permissions de droit delecture tendus). C'est un formidable moyen de partager des pratiques de configuration de build et desastuces avec d'autres quipes sans les laisser trafiquer vos builds.

    Figure 7.22. Configurer les permissions de droit de lecture tendus

    Il est intressant de noter que, aussi importantes ou multiples que soient les quipes impliques, labase de donnes interne de Jenkins atteint ses limites assez rapidement, et cela vaut le coup d'envisagerl'intgration avec un service d'annuaire plus spcialis comme un serveur LDAP, Active Directory ouAtlassian Crowd, ou alors un systme de permission plus sophistiqu comme une scurit base sur lesrles, discute dans la section suivante.

    7.5.3. Scurit base sur les rles

    Quelques fois, grer les permissions utilisateur individuellement peut s'avrer rbarbatif, et vouspourriez ne pas vouloir vous intgrer avec un serveur LDAP pour configurer vos groupes avec. Unealternative plus rcente est d'utiliser le plugin Role Strategy, qui permet de dfinir des rles globaux oude niveau projet, et les affecter aux utilisateurs.

    Vous installez le plugin de faon habituelle, via le gestionnaire de plugin. Une fois install, vouspouvez activer cette stratgie d'autorisation sur la page de configuration principale (voir Figure 7.23,Configurer la scurit base sur les rles).

    Figure 7.23. Configurer la scurit base sur les rles

  • 199

    Quand vous avez configur cela, vous pouvez dfinir des rles regroupant des ensembles de permissionslies les unes aux autres. Vous crez et configurez vos rles, puis les assignez vos utilisateurs, dansl'cran de gestion de rles, auquel vous accdez dans l'cran Administrer Jenkins (voir Figure 7.24, Lemenu de configuration Grer les rles).

    Figure 7.24. Le menu de configuration Grer les rles

    Dans l'cran Grer les rles, vous pouvez mettre en place des permissions globales ou de niveauprojet. Les permissions globales s'appliquent tous les projets, et sont typiquement des permissionsd'administration du systme ou d'accs gnral (voir Figure 7.25, Grer les rles globaux). La miseen oeuvre de ces rles est intuitive et similaire la configuration des permissions utilisateur dans lesautres modles de securit que nous avons vus.

    Figure 7.25. Grer les rles globaux

    Les rles de projet sont lgrement plus compliqus. Un rle de projet regroupe un ensemble depermissions applicables un ou plusieurs projets (a priori relis). Vous dfinissez les projets concernsen utilisant une expression rgulire, cela aide avoir un ensemble clair et cohrernt de conventions denommage dans vos noms de projets (voir Figure 7.26, Grer les rles de projets). Par exemple, vouspouvez vouloir crer des rles distinguant les dveloppeurs avec des droits complets sur leurs propresprojets d'utilisateur qui peuvent simplement dclencher un build et voir le rsultat. Ou vous pouvez crerdes rles o les dveloppeurs peuvent configurer certaines tches de build de dploiement automatis,mais que seules les quipes de production soient autorises excuter ces tches.

  • 200

    Figure 7.26. Grer les rles de projets

    Une fois ces rles dfinis, vous pouvez aller dans l'cran Assigner les rles pour configurer lesutilisateurs ou groupes avec ces rles (voir Figure 7.27, Assigner des rles des utilisateurs).

    Figure 7.27. Assigner des rles des utilisateurs

    La stratgie base sur les rles est relativement nouvelle dans Jenkins, mais c'est une excellente faon desimplifier les tches de gestion des permissions dans de grosses organisations, multi-quipes et multi-projets.

  • 201

    7.6. Audit Garder la trace des actions utilisateursEn plus de configurer les comptes utilisateurs et leurs droits d'accs, il peut tre utile de garder desactions de chaque utilisateur : en d'autres termes, qui a fait quoi votre configuration serveur. Ce typede traage est mme requis dans certaines organisations.

    Il y a deux plugins Jenkins qui peuvent vous aider accomplir cela. Le plugin Audit Trail conserve unenregistrement des changements utilisateur dans un fichier de log spcial. Et le plugin JobConfigHistoryvous permet de garder des copies de versions prcdentes des diverses configurations de tches et dusystme que Jenkins utilise.

    Le plugin Audit Trail garde une trace des principales actions utilisateur dans un ensemble de fichiersde logs tournants. Pour mettre cela en place, allez sur la page Grer les plugins et slectionnez le pluginAudit Trail dans la liste des plugins disponibles. Ensuite, comme d'habitude, cliquez sur Installer etredmarrez Jenkins une fois que le plugin a t tlcharg.

    La configuration de l'audit trail s'effectue dans la section Audit Trail de l'cran de configuration principalde Jenkins (voir Figure 7.28, Configurer le plugin Audit Trail). Le champ le plus important estl'emplacement des logs, qui indique o se trouve le rpertoire dans lequel les logs doivent tre crits.L'audit trail est conu pour produire des logs de style systme, qui sont souvent placs dans un rpertoiresystme comme /var/log. Vous pouvez aussi configurer le nombre de fichiers de logs maintenir, etla taille maximale (approximative) de chaque fichier. L'option la plus simple est de fournir un cheminabsolu (comme /var/log/hudson.log), auquel cas Jenkins crira dans des fichiers de logs avec desnoms comme /var/log/hudson.log.1, /var/log/hudson.log.2, et ainsi de suite. Bien sr, vousdevez vous assurer que l'utilisateur excutant votre instance Jenkins peut crire dans ce rpertoire.

    Figure 7.28. Configurer le plugin Audit Trail

    Vous pouvez aussi utiliser le format dfini dans la classe de l'API de logging Java FileHandler1 pourplus de contrle sur les fichiers de log gnrs. Dans ce format, vous pouvez insrer des variables tellesque %h, pour le rpertoire racine de l'utilisateur courant, et %t, pour le rpertoire temporaire du systme,afin de construire un chemin de fichier plus dynamique.

    Par dfaut, les dtails enregistrs dans les logs d'audit sont assez lgers ils enregistrementeffectivement les actions cls effectues, comme la cration, la modification ou la suppression de

    1 http://download.oracle.com/javase/1.5.0/docs/api/java/util/logging/FileHandler.html

    http://download.oracle.com/javase/1.5.0/docs/api/java/util/logging/FileHandler.htmlhttp://download.oracle.com/javase/1.5.0/docs/api/java/util/logging/FileHandler.html

  • 202

    configurations de tches ou de vues, ainsi que l'utilisateur qui a effectu ces actions. Le log montre aussicomment les tches individuelles ont t dmarres. Voici un extrait du log par dfaut :

    Dec 27, 2010 9:16:08 AM /job/game-of-life/configSubmit by johnsmartDec 27, 2010 9:16:42 AM /view/All/createItem by johnsmartDec 27, 2010 9:16:57 AM /job/game-of-life-prod-deployment/doDelete by johnsmartDec 27, 2010 9:24:38 AM job/game-of-life/ #177 Started by user johnsmartDec 27, 2010 9:25:57 AM job/game-of-life-acceptance-tests/ #107 Started by upstream project "game-of-life" build number 177Dec 27, 2010 9:25:58 AM job/game-of-life-functional-tests/ #7 Started by upstream project "game-of-life" build number 177Dec 27, 2010 9:28:15 AM /configSubmit by johnsmart

    L'audit trail est certainement utile, particulirement avec une perspective d'administration systme.Toutefois, cela ne produit pas d'information propos des changements exacts qui ont t faits laconfiguration Jenkins. Nanmoins, une des raisons les plus importantes pour garder des traces d'actionsutilisateurs dans Jenkins est de savoir quels changements ont t faits aux configurations de tches debuild. Quand quelque chose se passe mal, il peut tre utile de savoir quels changements ont t faits ettre donc capables de les dfaire. Le plugin JobConfigHistory vous permet justement de faire cela.

    Le plugin JobConfigHistory est un outil puissant vous permettant de conserver l'historique completdes changements faits la fois sur les tches et fichiers de configuration systme. Vous l'installezdepuis le gestionnaire de plugin de la faon habituelle. Une fois install, vous pouvez rgler finementla configuration de l'historique des tches dans l'cran Administrer Jenkins (voir Figure 7.29, Mettreen place l'historique des configurations de tches).

    Figure 7.29. Mettre en place l'historique des configurations de tches

    Ici, vous pouvez configurer un bon nombre d'options utiles non standard. En particulier, vousdevriez spcifier un rpertoire o Jenkins peut stocker l'historique de configuration, dans le champ"Rpertoire racine de l'historique. C'est le rpertoire dans lequel Jenkins stockera un enregistrementdes changements la fois lis au systme et aux configuration de tches. Cela peut tre la fois unrpertoire absolu (comme /var/hudson/history), ou un rpertoire relatif, calcul partir de la racinedu rpertoire de Jenkins (voir Section 3.4, Le rpertoire de travail de Jenkins). Si vous ne faites pascela, l'historique de configuration des tches sera stock dans les tches elles-mmes, et tout sera perdusi vous supprimez une tche.

    Il y a un certain nombre d'autres options utiles dans la section Avanc. La case cocher Sauver leschangements de configuration systme vous permet de garder la trace de mise jour de configurationde niveau systme, et non pas seulement de celles spcifiques aux tches. Et la case cocher Ne pas

  • 203

    sauver d'historique dupliqu vous permet d'viter d'avoir des enregistrements de configuration si aucunchangement rel n'a t effectu. Sinon, une nouvelle version du fichier de configuration sera enregistre,mme si vous avez seulement appuy sur le bouton Sauver sans faire aucun changement. Jenkins peutaussi provoquer cela en interne - par exemple, le paramtrage de la configuration systme est entirementsauv chaque fois que la page principale de configuration est sauve, mme si aucune modificationn'a t faite.

    Une fois que vous avez mis ce plugin en place, vous pouvez accder l'historique pour le serveurcomplet, incluant les mises jour de configuration systme, aussi bien qu'aux changements effectus la configuration de chaque projet. Dans les deux cas, vous pouvez voir ces changements en cliquant surl'icne Job Config History sur la droite de l'cran. Cliquer sur cette icne affichera une vue de tout votrehistorique de configuration, incluant les changements de tches et les changements de niveau systme(voir Figure 7.30, Prsentation de l'historique de configuration des tches).

    Figure 7.30. Prsentation de l'historique de configuration des tches

    Si vous cliquez sur un changement de niveau systme (indiqu par le suffixe (system) dans laliste), Jenkins vous emmne vers un cran listant toutes les versions de ce fichier, et vous permetde voir les diffrences entre les versions (voir Figure 7.31, Voir les diffrences dans l'historique deconfiguration des tches). Les diffrences sont affiches sous la forme de fichiers diff, ce qui n'est pasparticulirement lisible en soi. Toutefois, pour de petits changements, le format XML lisible de Jenkinsrend cela suffisant pour comprendre le changement qui a t effectu.

    Figure 7.31. Voir les diffrences dans l'historique de configuration des tches

  • 204

    Le plugin JobConfigHistory est un outil puissant. Toutefois, l'criture de ces lignes, il a ses limites.Comme mentionn, le plugin affiche uniquement les diffrences au format diff brut, et vous ne pouvezpas restaurer une version prcdente d'un fichier de configuration (faire cela hors contexte pourrait tredangereux dans certaines circonstances, particulirement pour les fichiers de configuration systme).Cependant, il donne un aperu trs clair des changements ayant t effectus, la fois sur vos tchesde build et sur votre configuration systme.

    7.7. ConclusionDans ce chapitre, nous avons regard une varit de faons de configurer la scurit dans Jenkins. Lemodle de scurit Jenkins, avec les deux concepts orthogonaux d'Authentification et d'Autorisation,est flexible et extensible. Pour une installation Jenkins de n'importe quelle taille, vous devriez essayerd'intgrer votre stratgie de scurit Jenkins dans l'organisation dans son ensemble. Ceci peut allerd'une simple intgration votre annuaire local LDAP la mise en place d'une solution complte deSSO comme Crowd ou CAS. Dans les deux cas, ceci rendra le systme considrablement plus facile administrer long terme.

  • Chapter 8. Notification8.1. Introduction Bien qu'il soit important que votre serveur de build construise votre logiciel, il est encore plus importantqu'il signale lorsqu'il ne peut pas le faire. Une part importante de la proposition de valeur de toutenvironnement d'intgration continue est d'amliorer le flux d'information sur la sant de votre projet ;que ce soit des tests d'intgration chous, des rgressions dans la suite des tests d'intgration ou d'autresproblmes de qualit comme une baisse dans la couverture de code ou de mtriques de qualit de code.Dans tous les cas, un serveur d'intgration continue doit permettre aux bonnes personnes de connatreles nouveaux problmes, et il doit pouvoir le faire rapidement. C'est ce que nous appelons : Notification.

    Il y a deux principales catgories de stratgies de notification, que j'appelle passive et active (ou pull/push). Les notifications passives (pull) demandent aux dveloppeurs de consulter consciemment le statutdu dernier build. Ces notifications comprennent les flux RSS, les radars de build, et (dans une certainemesure) les e-mails. Les notifications actives (push) vont alerter les dveloppeurs de manire pro-activelorsqu'un build choue. Ces notifications comprennent des mthodes telles que des notifieurs intgrsau bureau, le dialogue en direct et les SMS. Ces deux approches ont leurs points positifs et ngatifs.Les stratgies de notifications passives telles que les radars de build peuvent diffuser une connaissancegnrale sur les builds chous et aider installer une culture d'quipe o la correction des builds casssprend une haute priorit. Des formes plus directes de notification peuvent encourager activement lesdveloppeurs prendre les choses en main et corriger les builds casss plus rapidement.

    8.2. Notification par emailLa notification par email est la forme de notification la plus vidente et la plus commune. L'emailest bien connu, omniprsent et facile utiliser et configurer (voirSection 4.8, Configurer le serveurde messagerie lectronique). Ainsi, quand les quipes mettent en place leur premier environnementd'intgration continue, c'est gnralement la stratgie de notification qu'ils essaient en premier.

    Vous activez les notifications email dans Jenkins en cochant la case Notification par email et enfournissant la liste des adresses email des personnes qui doivent tre notifies (voirFigure 8.1,Configurer les notifications par email). Par dfaut, Jenkins enverra un courrier pour chaque buildchou ou instable. Rappelez-vous, Jenkins enverra aussi un nouvel email ds le premier build russiaprs une srie de builds chous ou instables, afin d'indiquer que le problme a t rsolu.

    Figure 8.1. Configurer les notifications par email

  • 206

    Normalement, un build ne devrait pas prendre trop d'essais pour fonctionner nouveau lesdveloppeurs doivent diagnostiquer et reproduire le problme localement, le corriger, et alors seulementcommitter leur correction dans le gestionnaire de versions. Des erreurs rptes de build indiquentgnralement une erreur de configuration chronique ou de mauvaises pratiques de dveloppement(par exemple, des dveloppeurs qui soumettent leurs modifications sans vrifier au pralable leurfonctionnement en local).

    Vous pouvez galement choisir d'envoyer un email distinct tous les dveloppeurs qui ont deschangements committs dans le build chou. C'est gnralement une bonne ide, car les dveloppeursqui ont committ des changements depuis le dernier build sont naturellement les personnes qui devraienttre les plus intresses par les rsultats du build. Jenkins va rcuprer l'adresse email de l'utilisateur partir du domaine de scurit couramment configur (voirSection 7.4, Domaines de scurit Identifier les utilisateurs Jenkins), ou en drivant l'adresse email partir de l'utilisateur de l'outilde gestion de versions s'il a t configur (voir Section 4.8, Configurer le serveur de messagerielectronique).

    Si vous utilisez cette option, il peut tre moins pertinent d'inclure l'quipe entire dans la liste de diffusionprincipale. Vous inclurez de prfrence les personnes qui seront intresses par le suivi du rsultatde chaque build (tels que les responsables techniques), et laisser Jenkins informer les dveloppeurscontributeurs directement.

    Cela implique que les changements ont provoqu l'chec du build, ce qui est gnralement (mais pastoujours) le cas. Cependant, si les builds sont peu frquents (par exemple les builds nocturnes, ou si unbuild est en attente pendant plusieurs heures avant d'tre abandonn), de nombreux changements peuventtre committs. Il est alors difficile de savoir quel est le dveloppeur responsable de l'chec du build.

    Tous les builds ne sont pas semblables par rapport aux notifications par email. Les dveloppeurs qui ontsoumis des changements sont particulirement intresss par les rsultats des builds des tests unitaireset des tests d'intgration (surtout ceux dclenchs par leurs propres modifications). Les testeurs seronteux plus intresss par jeter un il sur le statut des tests d'acceptation automatiss. La configuration desnotifications par email sera donc diffrente pour chaque tape de build. En fait, il est utile de dfinir desstratgies de notification par email. Par exemple,

    pour les builds rapides (les tests unitaires/d'intgration s'excutent en moins de 5 minutes) :les notifications sont envoyes aux chefs d'quipes et aux dveloppeurs qui ont committ deschangements,

    pour les builds lents (les builds de tests d'acceptation s'excutent aprs les builds rapides) : lesnotifications sont envoyes aux chefs d'quipes, aux testeurs, ainsi qu'aux dveloppeurs qui ontcommitt des changements.

    pour les builds nocturnes (les mtriques de qualit, tests de performance et autres s'excutentuniquement si les autres builds fonctionnent): les notifications sont envoyes tous les membresd'quipe Ceux-ci fournissent une photo instantane de la sant du projet avant la runionquotidienne.

  • 207

    En fait, vous devriez adopter au cas par cas la stratgie de notification approprie pour chaque tche debuild, plutt que d'appliquer une politique globale pour toutes les tches de build.

    8.3. Notification par email avancePar dfaut, la notification par email Jenkins est un outil plutt brut. Les messages de notification sonttoujours envoys au mme groupe de personnes. Vous ne pouvez pas envoyer des messages diffrentespersonnes en fonction de ce qui a mal tourn. De la mme faon, vous ne pouvez pas mettre en uvredes politiques d'escalade. Par exemple, il pourrait tre utile d'tre en mesure de notifier les dveloppeursqui ont committ les modifications la premire fois qu'un build choue, et envoyer un message diffrentau chef d'quipe ou l'quipe entire si le build choue une seconde fois

    Le plugin Email-ext vous permet de dfinir une stratgie de notification par email plus fine. Ce pluginajoute une case Editable Email Notification (voirFigure 8.2, Configurer les notifications par emailavances), qui remplace efficacement la notification par email standard de Jenkins. Ainsi, vous pouvezdfinir une liste de destinataires par dfaut et affiner le contenu du message lectronique. Vous pouvezaussi dfinir une stratgie de notification plus prcise avec des messages diffrents pour des listes dedestinataires diffrents suivant les vnements. Notez qu'une fois que vous avez install et configurce plugin pour votre tche de build, vous pouvez dsactiver la configuration normale de notificationpar email.

    Figure 8.2. Configurer les notifications par email avances

    Ce plugin a deux fonctionnalits lies mais distinctes. Tout d'abord, il vous permet de personnaliserle message de notification par email. Vous pouvez choisir parmi un grand nombre de mots clsprdfinis pour crer vos propres titres et corps de messages personnaliss. Vous incluez un mot cldans votre modle de message en utilisant la notation habutuelle dollar (e.g., ${BUILD_NUMBER} ou$BUILD_NUMBER). Certains mots cls acceptent des paramtres que vous pouvez spcifier en utilisantle format name=value (ex : ${BUILD_LOG, maxLines=100} ou${ENV, var="PATH"}). Les motscls les plus utiles sont:

    ${DEFAULT_SUBJECT}

    Le sujet par dfaut configur dans la page de configuration Jenkins

  • 208

    ${DEFAULT_CONTENT}

    Le corps du message par dfaut configur dans la page de configuration Jenkins

    ${PROJECT_NAME}

    Le nom du projet

    ${BUILD_NUMBER}

    Le numro de build courant

    ${BUILD_STATUS}

    Le statut du build courant (chec, succs, etc.)

    ${CAUSE}

    La cause du build

    ${BUILD_URL}

    Un lien vers la page correspondante du build sur Jenkins

    ${FAILED_TESTS}

    Information sur les tests unitaires chous, si certains ont chous

    ${CHANGES}

    Changements effectus depuis le dernier build

    ${CHANGES_SINCE_LAST_SUCCESS}

    Tous les changements effectus depuis le dernier build avec succs

    Pour obtenir la liste complte des mots cls disponibles ainsi que leurs options pour ceux qui acceptentdes paramtres, cliquez sur l'icne d'aide en face de Contexte Token Reference.

    Le bouton Avanc vous permet de dfinir une stratgie de notification plus sophistique base sur leconcept de dclencheurs (voirFigure 8.3, Configurer les dclencheurs de notification par email). Lesdclencheurs dterminent quand les notifications par email doivent tre envoyes. Les dclencheurssupports sont les suivants :

    FailureChaque fois qu'un build choue.

    Still FailingPour tous les builds qui restent en chec par la suite.

    UnstableChaque fois qu'un build est instable.

    Still UnstablePour tous les builds qui restent instables par la suite.

  • 209

    SuccessPour chaque build en succs.

    FixedQuand un build passe d'chec ou instable succs.

    Before BuildAvant chaque dbut de build.

    Figure 8.3. Configurer les dclencheurs de notification par email

    Vous pouvez configurer autant (ou aussi peu) de dclencheurs que vous le souhaitez. La liste desdestinataires et le modle de message peuvent tre personnaliss pour chaque dclencheur, par exempleen utilisant les dclencheurs Still Failing et Still Unstable, vous pouvez mettre en place une stratgiede notification qui n'avertit que le dveloppeur qui a committ des changements la premire fois qu'unetche de build choue, mais continue par informer le chef d'quipe si elle choue une seconde fois. Vouspouvez choisir d'envoyer le message uniquement des dveloppeurs qui ont committ lors du build( Send to committers ), ou d'inclure galement tous ceux qui ont committ depuis le dernier buildavec succs. Cela assure que tous ceux qui peuvent tre impliqus dans l'chec du build seront notifisde faonapproprie.

    Vous pouvez galement personnaliser le contenu du message en cliquant sur l'option MoreConfiguration (comme indiqu pour le dclencheur Still Failing dans Figure 8.3, Configurer lesdclencheurs de notification par email). De cette faon, vous pouvez personnaliser des messagesdiffrents qui seront envoys dans des cas distincts.

    Les dclencheurs interagissent intelligemment entre eux. Donc, si vous configurez la fois ledclencheur Failing et le dclencheur Still Failing, seul le dclencheur Still Failing sera activ lors dusecond chec de build.

    Un exemple d'un tel message personnalis est illustr dans Figure 8.4, Message de notificationpersonnalis.

  • 210

    Figure 8.4. Message de notification personnalis

    Toutefois, l'email n'est pas une stratgie de notification sans dfaut. Certains dveloppeurs ferment parmoment leurs clients de messagerie afin d'viter d'tre interrompu. Dans les grandes organisations, lenombre d'emails qui arrivent chaque jour peut tre considrable et les notifications d'chec de de buildpeuvent tre caches parmi une foule d'autres messages moins importants. Les checs de build peuventdonc ne pas toujours avoir l'attention prioritaire qu'ils ncessitent dans un environnement d'intgrationcontinue finement rgl. Dans les sections suivantes, nous nous pencherons sur certaines stratgies denotification autres qui peuvent tre utilises pour augmenter la sensibilisation des quipes sur les buildschous et encourager les dveloppeurs les corriger plus rapidement.

    8.4. Revendiquer des buildsQuand un build choue, il peut tre utile de savoir que quelqu'un a repr le problme et y travailledessus. Cela vite d'avoir plusieurs dveloppeurs qui gaspillent leur temps essayer de corriger le mmeproblme, chacun de leur ct.

    Le plugin Claim permet aux dveloppeurs d'indiquer qu'ils se sont appropris un build cass et qu'ilsessaient de le rparer. Vous pouvez installer ce plugin de la faon habituelle. Une fois install, lesdveloppeurs peuvent revendiquer un build chou comme le leur. Ils peuvent ventuellement ajouterun commentaire pour expliquer la cause suspecte de l'chec du build et ce qu'ils ont l'intention de faire ce sujet. Le build revendiqu sera alors marqu comme tel dans l'historique des builds afin d'viteraux autres dveloppeurs de gaspiller inutilement du temps investiguer.

    Pour activer la revendication pour une tche de build, vous devez cocher la case Allow broken buildclaiming dans la page de configuration de la tche de build. Alors, vous pourrez revendiquer unbuild cass dans la page de dtails du build (voirFigure 8.5, Revendiquer un build chou). Les

  • 211

    builds revendiqus seront affichs avec une icne dans l'historique des builds indiquant qu'ils ont trevendiqus. Vous pouvez aussi effectuer une revendication de build sticky afin que tous les checsultrieurs de build pour cette tche soient aussi automatiquement revendiqus par ce dveloppeur, et ce,jusqu' ce que le problme soit rsolu.

    Figure 8.5. Revendiquer un build chou

    8.5. Flux RSSJenkins fournit aussi des flux RSS pratiques pour les rsultats de build, tant pour les rsultats globauxsur l'ensemble de vos builds (ou juste les builds d'une vue particulire), que pour les rsultats d'unbuild spcifique. Les icnes de flux RSS sont disponibles au bas des tableaux de bord des builds (voirFigure 8.6, Flux RSS dans Jenkins) et au bas du panneau de l'historique des builds pour les tches debuild individuel. Ils vous donnent soit accs l'ensemble des rsultats des builds, soit accs simplementaux builds chous.

  • 212

    Figure 8.6. Flux RSS dans Jenkins

    Les URLs des flux RSS sont simples, et fonctionnent pour toute page Jenkins affichant un ensemblede rsultats de build. Vous devez juste rajouter /rssAll pour obtenir le flux RSS de tous les rsultatsde build d'une page, ou /rssFailed pour n'obtenir que les rsultats des builds chous. Enfin, /rssLatest vous fournira un flux RSS contenant uniquement les derniers rsultats de build. Mais lafaon la plus simple de rcuprer l'URL est de cliquer simplement sur l'icne RSS sur la page Jenkinscorrespondante.

    Il y a plthore de lecteurs RSS, la fois commerciaux et open source, disponibles pour pratiquementtoutes les plates-formes et priphriques. Ce peut tre un excellent moyen pour garder un il sur lesrsultats de build. La plupart des navigateurs (Firefox en particulier) et des clients email supportentles flux RSS. Certains lecteurs ont des problmes avec l'authentification. Si votre instance Jenkins estscurise, il vous faudra peut-tre faire un peu de configuration supplmentaire pour voir les rsultatsde votre build.

    Les flux RSS peuvent tre une source d'information sur l'ensemble des rsultats de build, et vouspermettent de voir l'tat de vos builds en un coup d'il sans avoir se connecter au serveur. Nanmoins,la plupart des lecteurs RSS sont par nature passifs - vous pouvez consulter l'tat de vos builds, mais lelecteur RSS ne sera gnralement pas en mesure de vous notifier si un nouveau build en chec apparait.

    8.6. Radars de buildLe concept de radar d'informations est couramment utilis dans les cercles agiles. Selon le gourouagile Alistair Cockburn:

    Un radar d'information est un cran affich dans un endroit que les gens peuvent voirquand ils travaillent ou passent proximit. Il prsente aux lecteurs les informationsdont ils se soucient, sans avoir poser de question quelqu'un. Cela signifie plus decommunication avec moins d'interruptions.

    Dans le contexte d'un serveur d'intgration continue, un radar d'informations est un dispositif ouaffichage important qui permet aux membres de l'quipe ou d'autres de facilement voir si l'un des buildsest actuellement cass. Il montre gnralement soit un rsum de tous les rsultats du build courant, soitseulement ceux en chec, et est affich sur un grand cran plat situ bien en vue sur un mur. Cette sortede radar d'informations spcialis est souvent connu comme un radar de build.

  • 213

    Utiliss correctement, les radars de build sont parmi les stratgies de notification passive les plusefficaces pour que tout le monde soit conscient des build chous. En outre, contrairement certainsdes priphriques de retours extrmes dont nous discuterons plus tard dans ce chapitre, un radar debuild peut contenir plusieurs tches de build, y compris plusieurs tches de build choues, et peut doncencore tre efficacement utilis dans un contexte d'quipes multiples.

    Il y a plusieurs solutions de radars de build pour Jenkins. Une des plus simples est d'utiliser le pluginJenkins Radiator View. Ce plugin ajoute un nouveau type de tche que vous pouvez crer: le (voirFigure 8.7, Crer une vue radar).

    Figure 8.7. Crer une vue radar

    Configurer la vue radar est similaire la configuration d'une vue liste plus conventionnelle - vous devezsimplement spcifier les tches de build que vous voulez inclure dans la vue, en les choisissant une une ou en utilisant une expression rgulire.

    Comme la vue radar occupe tout l'cran, modifier ou supprimer une vue radar est un peu dlicat. Enfait, la seule faon d'ouvrir l'cran de configuration de la vue est d'ajouter /configure l'URL de lavue : si votre radar est nomm build-radiator, vous pouvez diter la configuration de la vue en ouvranthttp://my.hudson.server/view/build-radiator/configure.

    La vue radar (voir Figure 8.8, Afficher une vue radar) affiche une grande boite rouge ou jaune pourchaque build chou ou instable. Ces boites contiennent le nom de la tche de build en lettres capitalesainsi que d'autres dtails. Vous pouvez configurer la vue radar pour afficher les builds en succs et lesbuilds en chec (ils seront affichs dans de petites boites vertes). Cependant, un bon radar ne devraitafficher que les builds chous, moins que tous les builds soient en succs.

  • 214

    Figure 8.8. Afficher une vue radar

    8.7. Messagerie instantaneLa messagerie instantane (ou IM) est aujourd'hui largement utilise comme un moyen rapide etlger de communication, aussi bien professionnelle que personnelle. La messagerie instantane est, pardfinition, instantane, ce qui lui donne un avantage sur l'email quand il s'agit de notification rapide. Elleest galement push plutt que pull. Lorsque vous recevez un message, il apparatra sur votre cranet attirera votre attention. Il est un peu plus difficile de l'ignorer ou de reporter qu'un simple messageemail.

    Jenkins offre un bon support pour les notifications via messagerie instantane. Le plugin InstantMessaging fournit un support gnrique pour communiquer avec Jenkins via la messagerie instantane.Des plugins spcifiques peuvent ensuite tre ajouts pour diffrents protocoles de messagerieinstantane tels que Jabber ou IRC.

    8.7.1. Notification par IM avec Jabber

    De nombreux serveurs de messagerie instantane sont bass sur Jabber, un protocole de messagerieinstantane open source et bas sur XML. Jenkins fournit un bon support pour la messagerie instantaneJabber, de telle sorte que les dveloppeurs peuvent recevoir des notifications en temps rel des checsde build. De plus, le plugin excute un robot de messagerie instantane qui coute les canaux decommunication et permet aux dveloppeurs d'excuter des commandes sur le serveur Jenkins via desmessages instantans.

    La mise en place du support de messagerie instantane dans Jenkins est simple. D'abord, vous devezinstaller la fois le plugin Jenkins instant-messaging et le plugin Jenkins Jabber Notifier en utilisantla page standard du gestionnaire de plugins et en redmarrant Jenkins (voir Figure 8.9, Installation desplugins Jenkins de messagerie instantane).

  • 215

    Figure 8.9. Installation des plugins Jenkins de messagerie instantane

    Une fois cela fait, vous devez configurer votre serveur de messagerie instantane. N'importe quel serveurJabber peut faire l'affaire. Vous pouvez utiliser un service public comme Google Chat, ou configurervotre propre serveur de messagerie instantane localement (le serveur de messagerie instantanne opensource Java OpenFire1 est un bon choix). Utiliser un service public pour les communications internespeut tre mal vu par les administrateurs systme, et vous pouvez avoir des difficults pour passer lesfirewalls de l'entreprise. D'autre part, configurer votre propre service de messagerie interne a du senspour une quipe de dveloppement ou toute autre organisation en gnral, car il fournit un autre canalde communication qui fonctionne bien pour partager des questions techniques ou commentaires entredveloppeurs. Les exemples suivants utiliseront un serveur OpenFire local, mais l'approche gnralefonctionne pour tout serveur Jabber- compatible .

    La premire tape consiste crer un compte ddi sur votre serveur Jabber pour Jenkins. Celui-ciest juste un compte de messagerie instantanne ordinaire, mais il doit tre distinct des comptes de vosdveloppeurs (voir Figure 8.10, Jenkins ncessite son propre compte de messagerie instantane).

    Figure 8.10. Jenkins ncessite son propre compte de messagerie instantane

    Une fois que vous avez configur un compte de messagerie instantane, vous devez configurer Jenkinspour envoyer des notifications par message instantan via ce compte. Allez la page de configuration

    1 http://www.igniterealtime.org/projects/openfire/index.jsp

    http://www.igniterealtime.org/projects/openfire/index.jsphttp://www.igniterealtime.org/projects/openfire/index.jsp

  • 216

    principale et cochez la case Enable Jabber Notification (voir Figure 8.11, Mise en place de notificationsde base Jabber dans Jenkins ). Ici, vous fournissez l'identifiant Jabber et le mot de passe pourvotre compte. Jenkins peut habituellement retrouver le serveur de messagerie partir de l'identifiantJabber (s'il est diffrent, vous pouvez le remplacer dans les options avances). Si vous utilisez lescanaux de communication en groupe (une autre stratgie de communication utile pour les quipes dedveloppement), vous pouvez aussi renseigner ici le nom de ces salons de discussion. De cette faon,Jenkins sera en mesure de traiter les instructions envoyes dans les salons de chat, ainsi que ceux reuscomme des messages directs.

    Figure 8.11. Mise en place de notifications de base Jabber dans Jenkins

    C'est tout ce dont vous avez besoin pour une configuration de base. Cependant, vous devrez peut-tre donner quelques informations supplmentaires dans la section avance pour des dtails qui sontspcifiques votre installation (voir Figure 8.12, Configuration avance Jabber). Ici, vous pouvezspcifier le nom et le port de votre serveur Jabber s'ils ne peuvent tre drivs de l'identifiant JenkinsJabber. Vous pouvez galement fournir un suffixe par dfaut qui peut tre appliqu l'utilisateurJenkins pour gnrer l'identifiant Jabber correspondant. Surtout, si vous avez scuris votre serveurJenkins, vous devrez fournir un nom d'utilisateur et un mot de passe Jenkins valides afin que le robotde messagerie instantane puisse ragir correctement aux instructions.

  • 217

    Figure 8.12. Configuration avance Jabber

    Une fois configur, vous devez dfinir une stratgie de notification Jabber pour chacune de vos tchesde build. Ouvrez la page de configuration de tche de build et cliquez sur l'option Jabber Notification.

    D'abord, vous devez dfinir une liste de destinataires pour les messages. Vous pouvezenvoyer des messages des individus (utilisez simplement l'identifiant Jabber correspondant,tel quejoe@jabber.acme.com) ou des salons de messagerie instantane que vous avez cr.Pour les salons, vous devez normalement ajouter une * au dbut de son identifiant (ex :*gameoflife@conference.jabber.acme.org). Cependant, si cet identifiant contient @conference.,Jenkins comprendra qu'il s'agit d'un salon de messagerie instantane et ajoutera automatiquement l'*.L'approche base sur un salon est la plus souple bien que pour que cette stratgie soit vraiment efficace,vous devez tre sr que les dveloppeurs y sont connects en permanence.

    Vous devez aussi dfinir une stratgie de notification. Celle-ci dtermine lesquels de vos rsultats debuild provoqueront un envoi de message. Les options sont:

    allEnvoie une notification pour chaque build.

    failureEnvoie une notification uniquement pour les builds chous et instables.

  • 218

    failure and fixedEnvoie une notification pour les builds chous et instables, et le premier build en succs aprsun build chou ou instable.

    changeEnvoie une notification quand le rsultat de build change.

    Si vous utilisez les salons de messagerie instantane, vous pouvez demander Jenkins d'envoyer unenotification au salon lorsqu'un build dmarre (en utilisant l'option Notify on build starts).

    En ce qui concerne les builds dmarrs par les systmes de gestion de version, Jenkins peut aussi notifierdes destinataires supplmentaires. Pour cela, il faut utiliser le suffixe par dfaut dcrit prcdemmentafin de gnrer l'identifiant Jabber partir de l'utilisateur du systme de gestion de version. Vous pouvezchoisir de notifier :

    SCM committersTous les utilisateurs qui ont committ des changements pour le build courant, et donc souponnsd'avoir cass le build.

    SCM culpritsTous les utilisateurs qui ont committ des changements depuis le dernier build avec succs.

    SCM fixersTous les utilisateurs qui ont committ des changements du premier build avec succs aprs unbuild chou ou instable.

    Upstream committersEnvoie une notification aux utilisateurs qui ont committ des changements pour les buildsen amont et courant. Cela fonctionne automatiquement pour les tches de build Maven, maisncessite d'activer l'empreinte numrique (fingerprint) des autres types de systmes de build.

    Au moment de la rdaction, vous ne pouvez dfinir qu'une stratgie de notification. Ainsi, certainesdes options avances que nous avons vu dans Section 8.3, Notification par email avance ne sont pasencore disponibles pour la messagerie instantane.

    Les dveloppeurs seront notifis via leur client de messagerie instantane favori (voir Figure 8.13,Messages Jenkins Jabber en action). Ils peuvent aussi interagir avec le serveur de build via une sessionde messagerie en utilisant un ensemble de commandes simples dont voici les plus utiles :

    !build game-of-lifeDmarre le build game-of-life immdiatement.

    !build game-of-life 15mDmarre le build game-of-life dans 15 minutes.

    !comment game-of-life 207 'oops'Ajouter une description au build dfini.

    !status game-of-lifeAffiche le status du dernier build de cette tche de build.

    !testresult game-of-lifeAffiche le rsultat complet du dernier build.

  • 219

    !health game-of-lifeAffiche un rsum plus complet de l'tat de sant du dernier build.

    Vous pouvez obtenir une liste complete des commandes en envoyant le message !help l'utilisateur Jenkins.

    Figure 8.13. Messages Jenkins Jabber en action

    8.7.2. Notification avec IRC

    Une autre forme de messagerie instantane Internet populaire est Internet Relay Chat, ou IRC. IRC esttraditionnellement centr sur les groupes de discussions (mme si la messagerie directe est galementsupporte). Elle est une forme de communication trs populaire parmi les dveloppeurs, en particulierdans le monde open source.

    Le plugin Jenkins IRC vous permet d'interagir avec votre serveur Jenkins via un canal IRC, la foispour recevoir des messages de notification, mais aussi pour envoyer des commandes au serveur. Commele plugin Jabber, vous devez installer le plugin Instant Messaging pour que le plugin Jenkins IRC fonctionne.

    8.8. Notification par IRCRdig par Juven Xu

    Internet Relay Chat (ou IRC) est une forme populaire de messagerie instantane, conue principalementpour la communication de groupes par canaux. Par exemple, Jenkins a un canal sur Freenode 2 de telle

    2 http://jenkins-ci.org/content/chat

    http://jenkins-ci.org/content/chathttp://jenkins-ci.org/content/chat

  • 220

    faon que les utilisateurs et les dveloppeurs peuvent changer sur des sujets lis Jenkins. Vous verrezde nombreux utilisateurs poser des questions et la plupart du temps des utilisateurs plus exprimentsfournir des rponses rapidement.

    Comme avec la messagerie instantane Jabber, vous pouvez configurer Jenkins pour pousser desnotifications via IRC. Quelques clients IRC tels que xchat3 supportent une configuration d'alerte detelle manire que lorsqu'un message arrive, il peut faire clignoter l'icne du panneau ou mettre un bipsonore. Pour mettre en place le support IRC dans Jenkins, vous devez d'abord installer le plugin IRC 4

    et leplugin Instant Messaging5. Allez simplement dans le gestionnaire de plugins par dfaut, cochez lescases correspondantes et redmarrez ensuite Jenkins (voir Figure 8.14, Installation des plugins JenkinsIRC).

    Figure 8.14. Installation des plugins Jenkins IRC

    Une fois cela fait, vous devez activer le plugin IRC, et le configurer pour intgrer votre propreenvironnement. Fondamentalement, cela consiste fournir le nom d'hte et le port du serveur IRC quevous utilisez, un canal IRC ddi, et un surnom pour le plugin IRC. Une bonne pratique consiste mettreen place un canal ddi pour les notifications provenant de l'IC. Ainsi, si les gens bavardent sur d'autrescanaux, ils ne seront pas perturbs. Vous pouvez galement configurer des dtails supplmentairesdans la section Avanc. Tous ces lments sont disponibles sur la page Configurer le systme(voirFigure 8.15, Configuration avance des notifications par IRC).

    3 http://xchat.org/4 http://wiki.jenkins-ci.org/display/JENKINS/IRC+Plugin5 http://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin

    http://xchat.org/http://wiki.jenkins-ci.org/display/JENKINS/IRC+Pluginhttp://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Pluginhttp://xchat.org/http://wiki.jenkins-ci.org/display/JENKINS/IRC+Pluginhttp://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin

  • 221

    Figure 8.15. Configuration avance des notifications par IRC

    En plus du nom d'hte, du port, du canal, et du surnom que nous avons mentionns prcdemment,vous pouvez galement configurer le mot de passe du serveur IRC ou celui du NickServ si votreenvironnement les ncessite. Les commandes doivent tre prfixes essentiellement de la mme faonque pour Jabber (voir Section 8.7, Messagerie instantane) si vous souhaitez interagir avec le serveurvia des messages IRC. Enfin, vous voudrez peut-tre configurer le plugin IRC pour utiliser la commande/notice en lieu et place de la commande par dfaut /msg. /notice est identique /msg except quele message sera encadr de tirets, ce qui vitera une rponse de la plupart des robots.

    Une fois que la configuration globale est prte, vous pouvez activer la notification par IRC pour chaquetche de build et mettre en place une stratgie de notification. Ouvrez la page de configuration de tchede build, allez la section Actions la suite du build et cliquez sur l'option IRC Notification. Si voussouhaitez configurer une stratgie de notification plutt que d'utiliser celle par dfaut, cliquez sur lebouton "Avanc..." (voirFigure 8.16, Configuration avance de notifications par IRC pour une tchede build).

  • 222

    Figure 8.16. Configuration avance de notifications par IRC pour une tche de build

    Les stratgies de notification (quand et qui envoyer des messages de notification) sont dcrites dansSection 8.7, Messagerie instantane. Le plugin Jabber ainsi que le plugin IRC dpendent du pluginInstant Messaging. Ils partagent donc un certain nombre de caractristiques fondamentales communes.Certaines options sont toutefois spcifiques l'extension IRC. Par exemple, vous pouvez dfinir un canalpersonnalis si vous n'aimez pas la valeur globale par dfaut. De plus, pour un message de notificationenvoy un canal, vous pouvez choisir les informations transmettre dans les messages de notification.Vos options ici sont le rsum du build, les changements effectus via le systme de gestion de version,et les tests chous.

    Une fois que vous enregistrez la configuration, tout est prt. Bas sur ce que vous avez configur, ceplugin va rejoindre les canaux IRC appropris et envoyer des messages de notification pour les tchesde build.

    Par exemple, dans Figure 8.17, Messages de notification par IRC en action, le plugin IRC rejoint lecanal #ci-book sur freenode. Tout d'abord, l'utilisateur juven a committ quelques changements avecle message "feature x added" et le plugin IRC notifie tous les connects au canal que le build a t unsuccs. Ensuite, juven committe un autre changement pour la fonctionnalit y, mais cette fois le build achou. John a remarqu et corrig l'erreur de build. Le plugin IRC dclare maintenant "Yippie, buildfixed!" Notez que certaines lignes de cet cran sont soulignes, c'est parce que je me suis connect entant qu'utilisateur "juven" et j'ai configur mon client IRC XChat pour mettre en vidence les messagescontenant mon surnom.

  • 223

    Figure 8.17. Messages de notification par IRC en action

    8.9. Notificateurs de bureau

    Les meilleures stratgies de notification push s'intgrent en douceur dans l'environnement de travailquotidien du dveloppeur. C'est pourquoi la messagerie instantane peut tre une stratgie efficace siles dveloppeurs ont dj l'habitude d'utiliser des messageries instantanes pour les autres activits liesau travail.

    Les outils de notification de bureau entrent aussi dans cette catgorie. Les outils de notification bureausont des outils qui s'excutent localement sur l'ordinateur du dveloppeur, soit comme une applicationindpendante ou un widget, soit dans le cadre de l'outil de dveloppement du dveloppeur (IDE).

    Si vous utilisez Eclipse, le plugin Eclipse Jenkins 6 affiche une icne de sant au bas de la fentreEclipse. Si vous cliquez sur cette icne, vous pouvez voir une vue dtaille des projets Jenkins (voirFigure 8.18, Notifications Jenkins dans Eclipse). Dans les prfrences d'Eclipse, vous indiquez l'URLde votre serveur Jenkins avec tous les dtails d'authentification requis. La configuration est assez simple,cependant, vous ne pouvez vous connecter une instance unique Jenkins pour un espace de travailEclipse donn.

    6 http://code.google.com/p/hudson-eclipse/

    http://code.google.com/p/hudson-eclipse/http://code.google.com/p/hudson-eclipse/

  • 224

    Figure 8.18. Notifications Jenkins dans Eclipse

    Si vous utilisez l'IDE NetBeans , vous avez dj l'intgration avec Hudson et Jenkins. Ouvrez la fentreServices et ajoutez des serveurs sousHudson Builders. (Si vous ouvrez un projet Maven dont la sectionciManagement indique hudson ou jenkins sous system, le serveur correspondant sera enregistrautomatiquement.) Cette intgration a des caractristiques diffrentes au-del des notifications de builddans la barre d'tat, telles que l'intgration dans la fentre Tests Results, l'affichage des journaux de buildet des journaux de changement, la navigation dans l'espace de travail, et un assistant de configurationde tche de build.

  • 225

    Figure 8.19. Connexion de Jenkins dans NetBeans

  • 226

    Le plugin Jenkins Tray Application (voir Figure 8.20, Lancement de Jenkins Tray Application) vouspermet de dmarrer une petite application cliente Java l'aide de Java Web Start partir de votre tableaude bord de Jenkins.

    Figure 8.20. Lancement de Jenkins Tray Application

    Cette application se trouve dans votre barre d'tat du systme et vous permet de visualiser l'tat courantde vos builds en un coup d'il. Elle apporte galement des fentres pop-up vous informant des nouveauxchecs de build (voirFigure 8.21, Excution de Jenkins Tray Application).

  • 227

    Figure 8.21. Excution de Jenkins Tray Application

    C'est certainement une application utile mais elle souffre de quelques limitations. Au moment de lardaction, Jenkins Tray Application ne supporte pas l'accs aux serveurs scuriss Jenkins. En outre, ledveloppeur doit se souvenir de le redmarrer chaque matin. Cela peut sembler un problme mineur,mais en gnral, quand il s'agit de stratgies de notification, moins vous en demandez vos dveloppeursmeilleure est la solution.

    Une des meilleures options pour les notifications Jenkins de bureau est d'utiliser un service commeNotifo (voir Section 8.10, Notifications via Notifo) qui fournit des clients pour bureaux et mobiles.Nous allons voir comment cela fonctionne en dtail dans la prochaine section.

    8.10. Notifications via NotifoNotifo7 est un service rapide et conomique pour envoyer en temps-rel des notifications versvotre smartphone ou votre bureau. Dans le contexte d'un serveur Jenkins, vous pouvez l'utiliser pourmettre en place gratuitement ou faible cot des notifications en temps rel pour vos rsultats debuilds Jenkins. Les comptes individuels (dont vous avez besoin pour tre capable de recevoir desnotifications) sont gratuits. Vous avez besoin de mettre en place un compte service pour envoyer desmessages de notification de votre serveur Jenkins. C'est ici que Notifo devient payant, mme si lors de lardaction un compte service peut envoyer jusqu' 10 000 notifications par mois gratuitement, ce qui esthabituellement largement suffisant pour une instance moyenne Jenkins. Un des points forts d'un servicede notification en temps rel comme Notifo est que les messages de notification peuvent tre envoys ces mmes utilisateurs sur diffrents dispositifs ; en particulier les smartphones et les clients de bureau.

    La mise en place des notifications Jenkins avec Notifo est relativement simple. Tout d'abord, allez surle site Notifio et inscrivez vous pour crer un compte. Chaque membre de l'quipe qui veut tre notifiaura besoin de son propre compte Notifo. Ils auront galement besoin d'installer le client Notifo sur

    7 http://www.notifo.com

    http://www.notifo.comhttp://www.notifo.com

  • 228

    chaque appareil sur lequel ils ont besoin de recevoir des notifications. Au moment de l'criture de celivre, les clients Notifo taient disponibles pour Windows et Mac OS X, ainsi que pour les iPhones. Lesupport pour les smartphones Linux et autres est en cours.

    Ensuite, vous devez configurer un compte de service Notifo pour votre serveur Jenkins. Vous pouvezfaire cela avec un de vos comptes dveloppeur, ou crer un nouveau compte cet effet. Connectez-vousau site Notifo, et aller au menu My Services. Ici, cliquez sur Create Service (voir Figure 8.22, Crerun service Notifo pour votre instance Jenkins) et remplissez les champs. Le plus important est que lenom d'utilisateur du service doit tre unique. Vous pouvez galement spcifier l'URL du site et l'URL denotification par dfaut pour pointer vers votre instance Jenkins pour que les utilisateurs puissent ouvrirla console Jenkins en cliquant sur le message de notification.

    Figure 8.22. Crer un service Notifo pour votre instance Jenkins

    Pour recevoir des messages de notification partir du serveur Jenkins, les dveloppeurs ont maintenantbesoin de souscrire ce service. Vous pouvez ensuite ajouter les dveloppeurs la liste des abonns surla page Subscribers du service en leur envoyant des demandes de souscription. Une fois que le servicea t cr et que les utilisateurs sont tous abonns, vous pouvez configurer votre projet pour envoyerdes notifications Notifo (voir Figure 8.23, Configurer les notifications via Notifo dans votre tche debuild Jenkins). Vous avez besoin de fournir le nom d'utilisateur de l'API du service de Jenkins quevous avez mis en place, ainsi que l'API Secret. Vous pouvez les voir tous les deux dans le tableau debord du service Notifo.

  • 229

    Figure 8.23. Configurer les notifications via Notifo dans votre tche de build Jenkins

    Une fois que cela est mis en place, Jenkins enverra en quasi temps-rel les notifications d'checs debuild tous les clients Notifo que le dveloppeur a lanc, que ce soit sur un bureau ou sur un appareilmobile (voir Figure 8.24, Recevoir une notification via Notifo sur un iPhone).

    Figure 8.24. Recevoir une notification via Notifo sur un iPhone

    Au moment de l'criture de ce livre, les stratgies de notification sophistiques ne sont pas prises encharge - vous ne pouvez fournir qu'une liste de noms d'utilisateurs Notifo qui doivent tre notifis.Nanmoins, cela reste un outil de notification trs efficace pour les dveloppeurs en ligne de front.

    8.11. Notifications vers mobilesSi votre serveur Jenkins est visible sur Internet (mme si vous avez mis en place une authentificationsur votre serveur Jenkins), vous pouvez aussi surveiller vos builds via votre appareil mobile iPhone ouAndroid. L'application gratuite Hudson Helper (voir Figure 8.25, Utiliser l'application iPhone HudsonHelper) par exemple, vous permet de lister vos tches de builds actuelles (soit l'ensemble des tchesde builds sur le serveur, ou seulement les tches de build d'une certaine vue). Vous pouvez galement

  • 230

    afficher les dtails d'une tche de build particulire, y compris son statut actuel, les tests en chec et letemps de build, et mme dmarrer et arrter les builds.

    Figure 8.25. Utiliser l'application iPhone Hudson Helper

    Pour les tlphones Android, vous pouvez galement installer le widget Hudson Mood qui fournitgalement des mises jour et des alertes sur les checs de build.

    Notez que ces applications mobiles s'appuient sur une connexion de donnes, de sorte qu'ils travaillentgnralement bien localement, mais vous ne devriez pas compter sur eux si le dveloppeur est l'extrieur.

    8.12. Notifications via SMSCes temps-ci, le SMS est un autre canal de communication universel qui a l'avantage supplmentaired'atteindre les personnes mme quand elles ne sont pas au bureau. Pour un ingnieur de build, ce peuttre un excellent moyen de surveiller des builds critiques, mme si les dveloppeurs ou chefs d'quipesont loin de leur bureau.

    Les passerelles SMS 8 sont des services qui permettent d'envoyer des notifications SMS via des adressesemails formattes spcialement (par exemple, 123456789@mysmsgateway.com pourrait envoyer unmessage SMS 123456789). Beaucoup de vendeurs mobiles offrent ce service, tout comme beaucoup

    8 http://en.wikipedia.org/wiki/SMS_gateway

    http://en.wikipedia.org/wiki/SMS_gatewayhttp://en.wikipedia.org/wiki/SMS_gateway

  • 231

    de prestataires de services tiers. Il n'y a aucune prise en charge intgre pour les passerelles SMS dansJenkins, mais la fonctionnalit de base de ces passerelles rend l'intgration relativement simple : ilvous suffit d'ajouter les adresses emails spciales la liste de notification normale. Sinon, en utilisantla configuration email avance, vous pouvez configurer une rgle distincte contenant uniquement lesadresses email SMS (voir Figure 8.26, Envoyer des notifictions SMS via une passerelle SMS).Procder ainsi rend plus facile d'affiner le contenu du message pour adhrer au format des messagesSMS.

    Figure 8.26. Envoyer des notifictions SMS via une passerelle SMS

    Une fois que vous avez fait cela, vos utilisateurs recevront une notification rapide des rsultats de buildsous forme de messages SMS (voir Figure 8.27, Recevoir des notifications via SMS). Le principalinconvnient de cette approche est sans doute que ce n'est pas gratuit, et ncessite l'utilisation d'unservice commercial tiers. Cela dit, c'est vraiment la seule technique de notification capable d'atteindreles dveloppeurs quand ils sont hors de porte d'Internet ou qu'ils n'ont pas de smartphone activ. Eneffet, cette technique est populaire parmi les administrateurs systme, et peut tre trs utile pour certainestches de build.

  • 232

    Figure 8.27. Recevoir des notifications via SMS

    8.13. Faire du bruit

    Si votre instance Jenkins s'excute sur une machine qui est physiquement situe proximit del'quipe de dveloppement, vous pouvez aussi vouloir ajouter les sons dans l'ensemble des stratgies denotification. Cela peut tre une stratgie efficace pour les petites quipes co-localises, mais cela devientplus difficile si le serveur de build est mis en place sur une machine virtuelle ou ailleurs dans le btiment.

    Il y a deux faons d'intgrer des retours audio dans votre processus de build Jenkins : le plugin JenkinsSounds et le plugin Jenkins Speaks. Les deux peuvent tre installs via la page du gestionnaire de pluginsde la manire habituelle .

    Le plugin Jenkins Sounds est le plus flexible des deux. Il vous permet de construire une stratgiede communication dtaille base sur le dernier rsultat de build et aussi (facultatif) sur le rsultat duprcdent build (voir Figure 8.28, Configurer les rgles de Jenkins Sounds dans une tche de build).Par exemple, vous pouvez configurer Jenkins pour jouer un son la premire fois qu'un build choue, unson diffrent si le build choue une seconde fois, et encore un autre son lorsque le build est corrig.

  • 233

    Figure 8.28. Configurer les rgles de Jenkins Sounds dans une tche de build

    Pour le mettre en place, vous devez cocher Jenkins Sounds la section des actions post-build dansla page de configuration de la tche de build. Vous pouvez ajouter autant de rgles de configurationaudio que vous le souhaitez. L'ajout d'une rgle est assez simple. Vous devez tout d'abord choisir quelrsultat de build va dclencher le son. Vous devez galement spcifier les rsultats de build prcdentspour lequel la prsente rgle est applicable: Non Construit (NB), Avort (Ab), chec (Fa), Non-positif(ONU) ou Russi (Su).

    Le plugin Jenkins Sounds propose une grande liste de sons prdfinis qui offrent gnralement beaucoupde choix pour les administrateurs de build les plus exigeants. Vous pouvez cependant ajouter votrepropre son la liste si vous le voulez. Les fichiers sonores des sons sont stocks dans un fichier ZIP ouJAR sous une structure plate (pas de sous-rpertoire). La liste des sons proposs par le plugin est toutsimplement la liste des noms de fichiers auxquels on retire l'extension. Le plugin supporte les formatsAIFF, AU, et WAV.

    Dans la page de configuration systme, vous pouvez indiquer Jenkins un nouveau fichier d'archive desons en utilisant la notation http:// si votre archive de sons est disponible sur un serveur Web local,ou la notation file:// s'il est disponible en local (voir Figure 8.29, Configurer Jenkins Sounds). Unefois que vous avez sauv la configuration, vous pouvez tester les sons de votre archive via le boutonTest Sound dans la section Avanc.

    Figure 8.29. Configurer Jenkins Sounds

    Le plugin Jenkins Sounds est un excellent choix si vous voulez complter vos techniques de notificationplus classiques. Les sons courts et reconnaissables sont un excellent moyen pour attirer l'attention d'undveloppeur et permettre l'quipe de savoir que quelque chose doit tre rpar. Ils seront alors un peuplus attentifs lorsque les notifications plus dtailles suivront.

  • 234

    Une autre option est le plugin Jenkins Speaks. Avec ce plugin, vous pouvez demander Jenkinsde diffuser une annonce personnalise (avec une voix trs robotique) lorsque votre build choue (voirFigure 8.30, Configurer Jenkins Speaks). Vous pouvez configurer le message exact l'aide de Jelly.Jelly est un langage de script bas sur XML largement utilis dans les niveaux infrieurs de Jenkins.

    Figure 8.30. Configurer Jenkins Speaks

    L'avantage de cette approche rside dans sa prcision : puisque vous pouvez utiliser des variablesJenkins dans le script Jelly, vous pouvez demander Jenkins de dire ce que vous voulez sur l'tat dela construction. Voici un simple exemple :

    Votre attention, s'il vous plait. Le projet ${build.project.name} a chou encore

    Si vous laissez ce champ vide, le plugin va utiliser un modle par dfaut que vous pouvez configurersur la page de configuration du systme. En fait, c'est gnralement une bonne ide de faire cela, etseulement d'utiliser script spcifique un projet si c'est ncessaire.

    L'inconvnient est que la voix robotique est parfois peut tre un peu difficile comprendre. Pour cetteraison, c'est une bonne ide de commencer votre annonce par une phrase gnrique telle que "Votreattention s'il vous plat, ou combiner Jenkins Speak avec le plugin Jenkins Sounds, de faon attirerl'attention des dveloppeurs avant que le message rel ne soit diffus. L'utilisation de traits d'union dansles noms de projets (par exemple, jeu-de-vie plutt que jeudevie) aidera aussi le plugin savoir commentprononcer vos noms de projet.

    Ces deux approches sont utiles pour les petites quipes, mais peuvent tre limites pour les plus grosses,lorsque le serveur n'est pas physiquement situ proximit de l'quipe de dveloppement. Les futuresversions pourront supporter la lecture de sons sur une machine spare, mais au moment de la rdactionde ce livre ce n'est pas encore disponible.

    8.14. Appareils de retour extrmesDe nombreux outils de notification et stratgies plus imaginatives existent. Il y a de la place pourl'improvisation si vous tes prt improviser un peu avec l'lectronique. Cela inclut des appareils tels

  • 235

    que les orbes d'ambiance, les lampes de lave, les feux de circulation, ou d'autres appareils USB plusexotiques. Le radar de build (voir Section 8.6, Radars de build) tombe aussi dans cette catgorie sion le projette sur un cran assez grand.

    Un appareil qui s'intgre trs bien avec avec Jenkins est le Nabaztag. Le Nabaztag (voir Figure 8.31, UnNabaztag) est un lapin robot WiFi trs populaire qui peut faire clignoter des lumires colores, jouerde la musique, ou mme de parler. Un des avantages du Nabaztag, c'est qu'tant donn qu'il fonctionneen Wifi, il n'est pas contraint tre situ proximit du serveur de build et fonctionnera mme si votreinstance Jenkins est dans une salle de serveurs ou sur une machine virtuelle. En ce qui concerne lesappareils de retour extrmes, ces petits compagnons sont difficiles battre.

    Figure 8.31. Un Nabaztag

    Et encore mieux, il existe un plugin Jenkins pour le Nabaztag. Une fois que vous avez install leplugin Nabaztag et redmarr Jenkins, il est facile configurer. Sur la page de configuration principalede Jenkins, rendez-vous la section Paramtres globaux de Nabaztag et entrez le numro de srie etjeton secret pour votre lapin lectronique (voir Figure 8.32, Configurer votre Nabaztag). Vous pouvezgalement fournir des rglages par dfaut sur la faon dont votre lapin de build devrait ragir auxchangements dans l'tat de build (doit-il signaler sur les dparts ou succs de build, par exemple), quellevoix utiliser, et quel message dire quand un build choue, russit, est fix, ou choue nouveau. Puis,pour activer les notifications Nabaztag pour une tche de build particulire, vous devez cocher l'optionde publication Nabaztag dans la configuration de votre tche de build. Selon votre environnement parexemple, vous voulez ou non que tous vos builds envoient des notifications votre Nabaztag.

  • 236

    Figure 8.32. Configurer votre Nabaztag

    l'exception notable du radar de build, nombre de ces dispositifs ont des limitations semblables auxplugins Jenkins Speaks et Jenkins Sounds (voir Section 8.13, Faire du bruit) - ils sont mieux adaptspour les petites quipes, co-localises, qui travaillant sur un nombre limit de projets. Nanmoins, quandils fonctionnent, ils peuvent tre un complment utile votre stratgie de notification gnrale.

    8.15. ConclusionLa notification est une partie essentielle de votre stratgie globale d'intgration continue. Aprs tout, unbuild chou a peu d'utilit s'il n'y a personne l'coute. Ce n'est pas non plus un problme universel.Vous devez penser votre organisation et adapter votre stratgie pour rpondre la culture locale del'entreprise et de l'ensemble des outils utiliss.

    En effet, il est important de dfinir et de mettre en uvre une stratgie de notification bien pense quiconvient votre environnement. L'email, par exemple, est omniprsent et sera donc l'pine dorsale denombreuses stratgies de notification. Si vous travaillez dans une grande quipe ou avec un responsabletechnique occup, vous devrez peut-tre envisager de mettre en place une stratgie progressive base surles options de messagerie avances (voir Section 8.3, Notification par email avance). Vous devrezcomplter cette dernire avec une des stratgies les plus actives, telles que la messagerie instantane oula notification de bureau. Si votre quipe utilise dj un canal de discussion IRC pour communiquer,essayez de l'intgrer dans votre stratgie de notification aussi. Enfin, la notification par SMS est unegrande stratgie pour les tches de build vraiment critiques.

    Vous devez galement veiller ce que vous ayez la fois des stratgies de notification actives et passives.Par exemple, un radar de build visible ou un appareil de retour extrme, envoient le message important l'quipe que la correction des builds est une tche prioritaire et peut aider installer une culture plusagile l'quipe.

  • Chapter 9. Qualit du Code9.1. Introduction

    Rares sont ceux qui nient limportance de lcriture dun code de qualit. Un code de grande qualitcontient moins de bugs, est plus facile comprendre et plus facile maintenir. Toutefois, les dfinitionsprcises de la qualit dun code peuvent tre plus subjectives, variant entre organisations, quipes, etmme entre individus dune mme quipe.

    Cest ici que les normes de codage entrent en jeu. Les normes de codage sont des rgles, parfoisrelativement arbitraires, qui dfinissent les styles et les conventions de codage qui sont considrescomme acceptables au sein dune quipe ou dune organisation. Dans beaucoup de cas, se mettredaccord sur un ensemble de normes et les appliquer est plus important que les normes elles-mmes. Eneffet, un des aspects les plus importants d'un code de qualit est quil soit facile lire et comprendre.Si tous les dveloppeurs dune quipe appliquent les mmes normes et les mmes pratiques, le codesera ainsi plus lisible, au moins pour les membres de cette quipe. Et, si les normes sont communmentutilises dans lindustrie, le code sera dautant plus lisible pour les nouveaux dveloppeurs arrivant danslquipe.

    Les normes de codage incluent la fois des aspects esthtiques comme la disposition et la mise en formedu code, les conventions de nommage et ainsi de suite, ainsi que les potentielles mauvaises pratiquescomme les oublis daccolades aprs une condition en Java. Un style de codage cohrent rduit les cotsde maintenance, rend le code plus propre et plus lisible et permet de travailler plus facilement avec ducode crit par dautres membres de lquipe.

    Seul un dveloppeur expriment peut rellement juger de la qualit dun code dans tous ses aspects.Cest le rle des revues de code et, entre autres, des pratiques comme la programmation en binme.En particulier, seul un il humain peut dcider si un bout de code est rellement bien crit et sil faitrellement ce que les exigences lui demandent de faire. Nanmoins, les outils de mesure de qualit decode peuvent tre d'une grande aide. En effet, il nest pas raliste dessayer de forcer des normes decodage sans ce type doutil.

    Ces outils analysent le code source ou le byte code de votre application et vrifient si le code respectecertaines rgles. Les mesures de qualit de code peuvent englober beaucoup daspects de la qualit duncode, des normes de codage et des meilleurs pratiques jusqu la couverture du code, en passant par lesavertissements du compilateur jusquaux commentaires TODO. Certaines mesures se concentrent surles caractristiques mesurables de votre base de code, comme le nombre de lignes de code (NLOC),la moyenne de complexit du code ou le nombre de lignes par classe. Dautres se focalisent sur desanalyses statiques plus sophistiques, ou sur la recherche de bugs potentiels ou de mauvaises pratiquesdans votre code.

  • 238

    Il y a une large gamme de plugins tablissant des rapports sur la qualit du code disponibles pour Jenkins.Beaucoup sont des outils danalyse statique Java, comme Checkstyle, PMD, FindBugs, Cobertura etJDepends. Dautres, comme fxcop et NCover, se focalisent sur les applications .NET.

    Pour tous ces outils, vous devez configurer votre tche de build pour gnrer les donnes de mesure dequalit de code avant que Jenkins puisse produire le moindre rapport.

    Lexception notable de cette rgle est Sonar. Sonar peut extraire des mesures de qualit de code depuisnimporte quel projet Maven, sans aucune configuration supplmentaire dans votre projet. Ce qui estexcellent lorsque vous avez un nombre important de projets Maven qui doivent tre intgrs Jenkinset que vous voulez configurer des rapports de qualit de code cohrents sur tous les projets.

    Dans le reste de ce chapitre, vous verrez comment configurer des rapports de qualit de code dans vosbuilds Jenkins et galement comment les utiliser comme un lment efficace dans votre processus debuild.

    9.2. La qualit du code dans votre processus de buildAvant de voir comment rapporter les mesures de qualits dans Jenkins, cela peut tre utile de reveniren arrire pour avoir une vue plus large. Les mesures de la qualit du code sont dune valeur limite sielles sont isoles, elles doivent faire partie dune stratgie plus large damlioration des processus.

    Le premier niveau dintgration de la qualit du code devrait tre lEDI. Les EDI modernes ont unexcellent support de beaucoup doutils de qualit de code Checkstyle, PMD et FindBugs ont tousdes plugins pour Eclipse, NetBeans et IntelliJ, qui fournissent un retour dinformation rapide auxdveloppeurs sur les problmes de qualit du code. Cest le moyen le plus rapide et le plus efficacepour fournir un retour dinformation des dveloppeurs et pour leur apprendre les normes de codagede lorganisation ou du projet.

    Le second niveau est votre serveur de build. En plus de vos tches rgulires de tests unitaires etdintgration, mettez en place un build de qualit de code ddi, qui dmarrera aprs le build rgulier etles tests. Le but de ce processus est de fournir des mesures de qualit de code lchelle du projet, degarder un il sur la faon dont le projet est fait dans son ensemble et de traiter nimporte quels problmesdun niveau lev. Lefficacit des ces rapports peut tre augmente par une revue hebdomadaire dela qualit du code, dans laquelle les problmes et les tendances sur la qualit du code sont discuts ausein de lquipe.

    Il est important d'excuter cette tche sparment parce que les outils danalyse de couverture de codeet danalyse statique peuvent tre trs longs excuter. Il est galement important de garder loign desbuilds nimporte quels tests de couverture du code, puisque le processus de couverture du code produitdu code instrument qui ne devrait jamais tre dploy vers un dpt pour une utilisation en production.

    Ltablissement de rapports sur la de qualit de code est, par dfaut, un processus relativement passif.Personne ne connatra ltat du projet sil ne cherche pas linformation sur le serveur de build. Mme si

  • 239

    cest mieux que rien, vous tes peut-tre exigeant sur la qualit du code, il y a alors un meilleur moyen.Au lieu de simplement tablir des rapports sur la qualit du code, mettez en place un build ddi laqualit du code, qui dmarre aprs le build normal et les tests et configurez le build pour chouer si lesmesures de la qualit du code ne sont pas un niveau acceptable. Vous pouvez faire cela dans Jenkinsou dans votre script de build, bien quil soit avantageux de le configurer en dehors de votre script debuild car vous pourrez changer les critres de dfaillance du build de qualit du code sans changer lecode source du projet.

    Pour finir, souvenez-vous que les normes de codage sont des lignes directrices et des recommandations,pas des rgles absolues. Utilisez la dfaillance des builds et les rapports de qualit de code comme desindicateurs dune zone possible damlioration, non pas comme des mesures de valeur absolue.

    9.3. Les outils danalyse de qualit du code populairespour Java et Groovy

    Il y a beaucoup doutils open source qui peuvent aider identifier les mauvaises pratiques de codage.

    Dans le monde Java, trois outils danalyses statiques ont rsist lpreuve du temps, et sont largementutiliss de manire trs complmentaire. Checkstyle excelle dans la vrification des conventions etnormes de codage, les pratiques de codage, ainsi que dautres mesures telles que la complexit du code.PMD est un outil danalyse statique similaire Checkstyle, plus focalis sur les pratiques de codage etde conception. Et FindBugs est un outil innovant, issu des travaux de recherche de Bill Pugh et de sonquipe de luniversit du Maryland, qui se focalise sur lidentification du code dangereux et bogu. Etsi vous tre en train de travailler avec Groovy ou Grails, vous pouvez utiliser CodeNarc, qui vrifie lanorme et les pratiques de codage de Groovy.

    Tous ces outils peuvent tre facilement intgrs dans votre processus de build. Dans les sectionssuivantes, nous verrons comment configurer ces outils pour gnrer des rapports XML que Jenkins peutensuite utiliser dans ses propres rapports.

    9.3.1. Checkstyle

    Checkstyle1 est un outil danalyse statique pour Java. A lorigine conu pour faire respecter un ensemblede normes de codage hautement configurable, Checkstyle permet aussi maintenant de vrifier lesmauvaises pratiques de codage, ainsi que le code trop complexe ou dupliqu. Checkstyle est un outilpolyvalent et flexible qui devrait avoir sa place dans nimporte quelle stratgie danalyse de code bassur Java.

    Checkstyle supporte un trs grand nombre de rgles, incluant celles lies aux normes de nommage,annotations, commentaires javadoc, taille de mthode et de classe, mesures de complexit de code,mauvaises pratiques de codage, et beaucoup dautres.

    1 http://checkstyle.sourceforge.net

    http://checkstyle.sourceforge.nethttp://checkstyle.sourceforge.net

  • 240

    Le code dupliqu est un autre problme important de la qualit de code le code dupliqu ou quasi-dupliqu est plus difficile maintenir et dboguer. Checkstyle fournit un certain soutien pour ladtection de code dupliqu, mais des outils plus spcialiss comme CPD font un meilleur travail dansce domaine.

    Une des choses intressante au sujet de Checkstyle est la facilit avec laquelle on peut le configurer. Vouspouvez commencer avec les normes de codage de Sun et les adapter selon vos besoins, ou dmarrer dezro. En utilisant le plugin Eclipse (ou mme directement en XML), vous pouvez choisir parmi plusieurscentaines de rgles, et affiner les options des rgles que vous choisissez (voir Figure 9.1, Cest facilede configurer les rgles Checkstyle avec Eclipse). Cest important, car les organisations, les quipes oumme les projets ont des attentes et des prfrences diffrentes au regard des normes de codage, et cestmieux davoir un ensemble de rgles prcises qui peuvent tre adoptes, plutt qu'un large ventail dergles qui seront ignores. Cest encore plus important lorsque de grandes bases de code existant sontimpliques dans ces cas, il est souvent prfrable de commencer avec un ensemble plus limit dergles que dtre submerg par un grand nombre de problmes de formatage relativement mineurs.

    Figure 9.1. Cest facile de configurer les rgles Checkstyle avec Eclipse

    Configurer Checkstyle dans votre build est gnralement simple. Si vous utilisez Ant, vous avez besoinde tlcharger le fichier JAR de Checkstyle depuis le site web et de le rendre disponible Ant. Vouspourriez le placer dans votre rpertoire lib de Ant, mais cela signifierait de devoir personnaliserlinstallation de Ant sur votre serveur de build (et tout les nuds esclaves), ce nest donc pas une

  • 241

    solution trs portable. Une meilleure approche serait de placer le fichier JAR de Checkstyle dans lun desrpertoires de votre projet, ou dutiliser Ivy ou la librairie Maven Ant Task pour dclarer une dpendance Checkstyle. Si vous choisissez de garder le fichier JAR de Checkstyle dans les rpertoires du projet,vous pourrez dclarer la tche Checkstyle comme indiqu ici :

    Ensuite, pour gnrer les rapports Checkstyle dans le format XML exploitable par Jenkins, vous pourrezprocder comme suit :

    Maintenant, invoquez juste cette tche (cf., ant checkstyle) afin de gnrer les rapports Checkstyle.

    Dans Maven 2, vous pouvez ajouter quelque chose comme la section qui suit :

    org.apache.maven.plugins maven-checkstyle-plugin 2.4 src/main/config/company-checks.xml

    Pour un projet Maven 3, vous avez besoin dajouter un plugin sur llment de lasection du maven-site-plugin :

    http://buildserver.acme.org:9000 ... ... org.apache.maven.plugins

  • 242

    maven-site-plugin 3.0-beta-2 org.apache.maven.plugins maven-checkstyle-plugin 2.4 ${sonar.url}/rules_configuration/export/java/My_Rules/checkstyle.xml

    Maintenant, lexcution de mvn checkstyle:checkstyle ou mvn site analysera votre code sourceet gnrera des rapports XML que Jenkins peut utiliser.

    A noter que dans le dernier exemple, nous utilisons un ensemble de rgles de Checkstyle que nous avonstransfr sur un serveur Sonar (dfinie par la proprit ${sonar.url}). Cette stratgie rend facilelutilisation du mme ensemble des rgles Checkstyle pour Eclipse, Maven, Jenkins, et Sonar.

    Les versions rcentes de Gradle offrent aussi une certaine prise en charge intgre de Checkstyle. Vouspouvez le configurer pour vos builds comme il suit :

    apply plugin: 'code-quality'

    Cela utilisera par dfaut lensemble de rgles de Checkstyle dfinies dans config/checkstyle/checkstyle.xml. Vous pouvez redfinir cela avec la proprit checkstyleConfigFileName : aumoment de lcriture de ce livre, nanmoins, il n'est pas possible de tlcharger le plugin de qualit decode pour Gradle afin d'obtenir les rgles Checkstyle depuis une URL.

    Vous pouvez gnrer les rapports Checkstyle ici en excutant gradle checkstyleMain or gradlecheck.

    9.3.2. PMD/CPD

    PMD2 est un autre outil populaire danalyse statique. Il se focalise sur les problmes potentiels decodage comme le code non utilis ou sous-optimis, la taille et la complexit du code, et les bonnespratiques de codage. Certaines rgles typiques intgrent Empty If Statement , Broken Null Check, Avoid Deeply Nested If Statements, Switch Statements Should Have Default, et Logger Is

    2 http://pmd.sourceforge.net

    http://pmd.sourceforge.nethttp://pmd.sourceforge.net

  • 243

    Not Static Final . Il y a une bonne quantit de ressemblances avec certaines rgles de Checkstyle, bienque PMD ait quelques rgles plus techniques, et dautres plus spcialises tels que les rgles relatives JSF et Android.

    PMD est aussi livr avec CPD, un dtecteur open source robuste de code dupliqu ou quasi-dupliqu.

    PMD est un peu moins flexible que Checkstyle, bien que vous puissiez choisir les rgles que vous voulezutiliser dans Eclipse, et les exporter ensuite dans un fichier XML (voir Figure 9.2, Configurer les rglesPMD dans Eclipse). Vous pouvez alors importer ces rgles dans les autres projets Eclipse, dans Sonar,ou les utiliser dans vos builds Ant ou Maven.

    Figure 9.2. Configurer les rgles PMD dans Eclipse

    PMD est livr avec une tche Ant que vous pouvez utiliser pour gnrer les rapports PMD et CPD. Toutdabord, toutefois, vous devez dfinir ces tches, comme le montre lexemple suivant :

  • 244

    classpathref="pmd.classpath"/>

    Ensuite, vous pouvez gnrer le rapport PMD XML en invoquant la tche PMD comme illustr ici :

    Et, pour gnrer le rapport CPD XML, vous pouvez faire quelque chose comme a :

    Vous pouvez placer lensemble de ces rgles XML dans le classpath de votre projet (par exemple, danssrc/main/resources pour un projet Maven), ou dans un module spar (si vous voulez partagerla configuration entre les projets). Un exemple sur la faon de configurer Maven 2 pour gnrer desrapports PMD et CPD en utilisant un ensemble de rgles XML export est indiqu ici :

    org.apache.maven.plugins maven-pmd-plugin 2.5 1.6 true xml /pmd-rules.xml

    20 true

  • 245

    Si vous utilisez Maven 3, vous devez placer la dfinition du plugin dans la section de configuration. Cet exemple montre aussi comment utiliser un ensemble de rgles dans uneautre dpendance (dans ce cas, le fichier pmd-rules.jar):

    ... ... ... org.apache.maven.plugins maven-site-plugin 3.0-beta-2 org.apache.maven.plugins maven-pmd-plugin 2.5 1.6 true xml /pmd-rules.xml

    50 true com.wakaleo.code-quality pmd-rules 1.0.1

    Maintenant, vous pouvez excuter soit mvn site soit mvn pmd:pmd pmd:cpd pour gnrer les rapportsPMD et CPD.

    Malheureusement, il nexiste actuellement aucune prise en charge de Gradle pour PMD ou CPD, vousdevez donc vous contenter d'appeler directement le plugin PMD pour Ant, comme montr ici :

  • 246

    configurations { pmdConf}

    dependencies { pmdConf 'pmd:pmd:4.2.5'}

    task pmd

  • 247

    des exceptions de pointeurs nuls, des boucles infinies, et un accs non intentionnel de ltat interne dunobjet. Contrairement beaucoup dautres outils danalyse statique, FindBugs tend trouver un plus petitnombre de problmes, mais de ces problmes, une grande partie sera importante.

    FIndBugs est moins configurable que les autres outils que nous avons vu, mais en pratique vousnavez gnralement pas besoin daffiner autant les rgles qu'avec les autres outils dont nous avonsdiscut. Vous pouvez lister les rgles individuelles que vous voulez appliquer, mais vous ne pouvez pasconfigurer un fichier XML partag entre vos builds Maven et votre IDE, par exemple.

    FindBugs est livre empaquet avec une tche Ant. Vous pouvez dfinir la tche FindBugs dans Antcomme montr en dessous. FindBugs a besoin de rfrencer le rpertoire home de FindBugs, qui est ola distribution binaire a t dcompresse. Pour rendre le build plus portable, nous stockons linstallationde FIndBugs dans la structure de rpertoire de notre projet, dans le rpertoire tools/findbugs :

    Ensuite, pour excuter FindBugs, vous pourrez configurer une cible findbugs comme montr danslexemple suivant. A noter que FindBugs s'excute sur le byte code de votre application, et non sur lecode source, donc vous devez compiler votre code source en premier :

    Si vous utilisez Maven 2, vous navez pas besoin de garder une copie locale de linstallation deFindBugs. Vous avez juste besoin de configurer FindBugs dans la section reporting comme montr ici :

    org.codehaus.mojo findbugs-maven-plugin 2.3.1 Max true

  • 248

    Ou pour un projet Maven 3 :

    ... ... ... org.apache.maven.plugins maven-site-plugin 3.0-beta-2 org.codehaus.mojo findbugs-maven-plugin 2.3.1 Max true

    Dans les deux cas, vous pouvez gnrer vos rapports XML en lanant soit mvn site soit mvnfindbugs:findbugs. Les rapports XML seront placs dans le rpertoire target.

    Au moment de la rdaction, il ny a pas de prise en charge de FindBugs dans Gradle, donc vous devezinvoquer le plugin Ant de FindBugs.

    9.3.4. CodeNarc

    CodeNarc est un outil danalyse statique de code Groovy, similaire PMD pour Java. Il vrifie le codesource Groovy afin de trouver des dfauts potentiels, des mauvais styles et pratiques de codage, du codetrop complexe, et ainsi de suite. Des rgles typiques incluent Constant If Expression , Empty ElseBlock , GString As Map Key , et Grails Stateless Service .

    Pour des projets bass sur Maven ou Ant, le plus simple est d'utiliser le plugin Ant de CodeNarc (unplugin Maven est en cours de dveloppement au moment de l'criture du livre). Une configurationtypique de Ant pour lutiliser avec Jenkins ressemblerait ceci :

  • 249

    Vous pouvez intgrer CodeNarc dans un projet Grails simplement en installant le plugin CodeNarc :

    $ grails install-plugin codenarc

    Cela configurera CodeNarc pour analyser les fichiers Groovy dans le code de votre application Grails,aussi bien que dans les rpertoires src/groovy et test.

    Gradle 0.8 fournit aussi une prise en charge de CodeNarc dans le plugin de qualit de code, que vouspouvez le configurer dans vos builds comme montr ici :

    apply plugin: 'code-quality'

    Cela utilisera par dfaut le fichier de configuration de CodeNarc suivant config/codenarc/codenarc.xml. Vous pouvez redfinir cela avec la proprit codeNarcConfigFileName.

    Vous pouvez gnrer les rapports CodeNarc en excutant gradle codenarcMain ou, plus simplement,gradle check.

    9.4. Rapports de problmes de qualit de code avec leplugin ViolationsUn des plugins de qualit de code les plus utiles est le plugin Violations. Ce plugin nanalysera pas lecode source de votre projet (vous devez configurer le build pour faire cela), mais il fait un excellenttravail en laborant des rapports sur les mesures de la qualit du code pour les builds individuels et lestendances au fil du temps. Le plugin sadresse aux rapports sur les mesures de qualit de code venantdune large gamme doutils danalyse statique, comprenant :

    Pour JavaCheckstyle, CPD, PMD, FindBugs, and jcreport

    Pour Groovycodenarc

    Pour JavaScriptjslint

  • 250

    Pour .Netgendarme and stylecop

    Installer ce plugin est d'une simplicit. Il suffit daller sur lcran du Plugin Manager et de slectionnerle plugin Violations de Jenkins. Une fois que vous install le plugin et redmarr Jenkins, vous serezcapable de lutiliser pour vos projets.

    Le plugin Violations ne gnre pas de mesures de qualit de code lui-mme vous devez configurervotre build pour faire cela, comme il est montr dans la section prcdente. Un exemple pour faire celapour une tche de build Maven est illustr dans la Figure 9.3, Gnrer les rapports de qualit de codedans un build Maven. Notez que nous invoquons ici les goals du plugin Maven directement. Nousaurions pu aussi simplement excuter mvn site, mais si nous sommes uniquement intresss par lesmesures de qualit de code, et pas par les autres lments du site gnr par Maven, appeler le plugindirectement se traduira par des builds plus rapides.

    Figure 9.3. Gnrer les rapports de qualit de code dans un build Maven

    Une fois que vous lavez paramtr, vous pouvez configurer le plugin de violations pour gnrer desrapports, et si besoin est, des notifications de dclenchement, bass sur les rsultats de rapport. Il suffitdaller dans Actions la suite du build et de cocher la case Report Violations. Les dtails de laconfiguration varient en fonction du type de projet. Penchons-nous sur les tches de build Freestyledans un premier temps.

    9.4.1. Travailler avec des tches de build free-style

    Les tches de build free-style vous permettent la configuration la plus flexible, et sont votre uniqueoption pour des projets non Java.

    Lorsque vous utilisez le plugin Violations avec une tche de build free-style, vous devez spcifier leschemins de chaque rapport XML gnr par les outils danalyse de code statiques que vous avez utilis(voir Figure 9.4, Configurer le plugin violation pour un projet free-style). Le plugin peut rpondre plusieurs rapports depuis le mme outil, ce qui est utile pour des projets Maven multi-module il suffitalors dutiliser une expression gnrique pour identifier les rapports que vous voulez (par exemple, **/target/checkstyle.xml).

  • 251

    Figure 9.4. Configurer le plugin violation pour un projet free-style

    Le plugin Violations gnrera un graphique de suivi pour chaque type de problme au cours du temps(voir Figure 9.5, Les violations au cours du temps). Le graphique affiche une ligne de diffrentecouleur pour chaque type de violations que vous suivez, ainsi quun rsum des derniers rsultats.

    Figure 9.5. Les violations au cours du temps

    Vous pouvez aussi cliquer sur le graphique pour vous rendre un build particulier. Ici, vous pouvezvoir le nombre de problmes soulevs pour un build particulier (voir Figure 9.6, Les violations pourun build particulier), avec diverses ventilations par type de violation, svrit et fichier.

  • 252

    Figure 9.6. Les violations pour un build particulier

    Enfin, vous pouvez descendre vers une classe particulire, pour afficher la liste dtaille des problmesavec leurs emplacements dans le code source.

    Mais le plugin Violations permet aussi une gestion plus proactive de la qualit du code. Vous pouvezutiliser les rsultats des rapports danalyse de la qualit du code pour influencer licne mtorologiquedu tableau de bord de Jenkins. Cette icne mtorologique est normalement lie au nombre de buildsdfaillants parmi les cinq derniers, mais Jenkins peut aussi prendre en compte dautres facteurs, commeles rsultats de la qualit du code. Afficher une icne pluvieuse ou orageuse pour un projet sur le tableaude bord est une meilleure faon de sensibiliser sur les problmes de qualit du code que de simplementsappuyer sur des graphiques et des rapports sur la page de la tche de build.

    Pour le configurer, vous devez revenir dans la section Report Violations dans Actions la suite dubuild. Les trois premires colonnes dans Figure 9.4, Configurer le plugin violation pour un projet free-style montre une icne ensoleille, une icne orageuse et une balle jaune. Celle avec licne de tempsensoleill est le nombre maximum de violations tolres pour garder licne ensoleille sur la page dutableau de bord. La deuxime colonne, avec licne de temps orageux, est le nombre de violations quicausera laffichage de licne orageuse sur le tableau de bord. Si vous avez un nombre de violationsentre ces deux extrmes, vous aurez lune des icnes nuageuses.

    Vous pouvez spcifier diffrentes valeurs pour diffrents outils. Les seuils exacts varieront entre lesquipes et entre les projets, et aussi entre les outils. Par exemple, Checkstyle soulvera gnralementbeaucoup plus de problmes que FindBugs ou CPD, avec PMD quelque part entre. Vous devez ajusterles valeurs utilises pour reflter comment ces outils travaillent avec votre code de base, et vos attentes.

  • 253

    Vous pouvez aller encore plus loin avec la troisime colonne (celle avec la balle jaune). Cette colonnevous permet de spcifier le nombre de violations qui dclarera le build comme instable. Souvenez-vous,lorsquun build devient instable, Jenkins enverra des messages de notifications, donc cest une stratgieencore plus proactive.

    Par exemple, dans Figure 9.4, Configurer le plugin violation pour un projet free-style, nous avonsconfigur le nombre minimum des violations Checkstyle 10, ce qui signifie que licne du tempsensoleill apparatra uniquement sil y a au maximum 10 violations Checkstyle. Sil y en a plus de 10,le temps se dgradera progressivement, jusqu 200 violations marques, o il deviendra orageux. Etsil y a 500 violations Checkstyle ou plus, le projet sera signal instable.

    Maintenant regardez la configuration de CPD, le dtecteur de code dupliqu qui vient avec PMD. Dansce projet, nous avons adopt une politique zro tolrance pour le code dupliqu, donc licne ensoleilleest spcifie zro. Licne orageuse est spcifie 10, donc sil y a 10 violations de copi/coll ouplus, il sera dclar instable.

    Maintenant, sur la page du tableau de bord, le projet apparatra avec la fois un une icne de tempsorageux et comme instable, mme sil ny pas dchecs de tests (voir Figure 9.7, Configurer le plugin deviolations pour un projet free-style). Ce build particulier est instable parce quil y a 16 violations CPD.En complment, si vous placez votre souris sur licne du temps, Jenkins affichera quelques dtailssupplmentaires sur comment il a calcul ce statut particulier.

    Figure 9.7. Configurer le plugin de violations pour un projet free-style

    9.4.2. Travailler avec des tches de build Maven

    Les tches de build Maven dans Jenkins utilisent les conventions de Maven et les informations dufichier pom.xml du projet pour rendre la configuration plus facile et plus lgre. Lorsque vous utilisezle plugin Violations avec une tche de build Maven, Jenkins utilise ces conventions pour rduire laquantit de travail ncessaire pour configurer le plugin. Vous navez pas besoin de dire Jenkins otrouver les rapports XML pour la plupart des outils danalyse de code statique (par exemple, Checkstyle,PMD, FindBugs, et CPD), puisque Jenkins peut l'interprter depuis les conventions de Maven et lesconfigurations du plugin (voir Figure 9.8, Configurer le plugin Violations pour un projet Maven.).Si vous devez redfinir ces conventions, vous pouvez choisir loption Pattern dans la liste droulante XML filename pattern , et entrer le chemin comme vous pouvez le faire pour les tches de buildfree-style.

  • 254

    Figure 9.8. Configurer le plugin Violations pour un projet Maven.

    Le plugin Violations fonctionne bien avec des projets multi-module Maven, mais au moment de lardaction (de ce livre), il a besoin dun peu de peaufinage pour obtenir de meilleurs rsultats. Les tchesde build Maven comprennent la structure des projets multi-module (voir Figure 9.9, Les tches debuild Maven de Jenkins comprennent les structures multi-modules de Maven) ; de plus, vous pouvezdescendre dans nimporte quel module et obtenir une vue dtaille des rsultats de construction pourcette tche de build.

    Figure 9.9. Les tches de build Maven de Jenkins comprennent les structures multi-modules de Maven

  • 255

    Cest une fonctionnalit trs utile, mais cela signifie que vous devez faire un peu de travailsupplmentaire pour obtenir tous les avantages des plugins de violations des modules individuels. Pardfaut, le plugin Violations affichera une vue agrge des mesures de qualit de code comme celledans Figure 9.5, Les violations au cours du temps. Vous pouvez aussi cliquer sur le graphique desviolations, et voir les rapports dtaills de chaque module.

    Cependant, pour que ceci puisse fonctionner correctement, vous devez activer le plugin Violationsindividuellement pour chaque module en complment du projet principal. Pour ce faire, cliquez sur lemodule que vous voulez configurer dans lcran Modules, et ensuite cliquez sur le menu Configurer.Ici, vous verrez un petit groupe des options de configuration habituelles (voir Figure 9.10, Activer leplugin Violations pour un module individuel). Ici, il vous suffit dactiver loption Violations, et deconfigurer les seuils si besoin est. Le ct positif de cela est que vous pouvez dfinir diffrentes valeursde seuils pour des modules diffrents.

    Figure 9.10. Activer le plugin Violations pour un module individuel

    Une fois que cela est fait, lorsque vous cliquerez sur le graphique de violations agrges sur la pagedaccueil de la tche de build du projet, Jenkins listera les graphiques individuels de violations pourchaque module.

    9.5. Utiliser les rapports Checkstyle, PMD, et FindBugsVous pouvez aussi effectuer des rapports individuellement sur les rsultats de Checkstyle, PMD, etFindBugs. En complment du plugin Violations, il y a des plugins Jenkins qui produisent des graphiquesde tendance et des rapports dtaills pour chacun de ces outils de faon individuelle. Nous allons voir

  • 256

    comment le faire avec Checkstyle, mais cette approche sapplique aussi pour PMD et FindBugs. Vouspouvez aussi utiliser le plugin Analysis Collector pour afficher les rsultats combins dans un graphiquesimilaire celui produit par le plugin Violations.

    Vous pouvez installer ces plugins au travers du gestionnaire de plugin comme vous le faiteshabituellement. Les plugins en question sont appels, sans surprise, plugin Checkstyle, plugin PMD,et plugin FindBugs. Tous ces plugins utilisent le plugin Static Analysis Utilities, qu'il vous faut aussiinstaller (voir Figure 9.11, Installer les plugins Checkstyle et Static Analysis Utilities.).

    Figure 9.11. Installer les plugins Checkstyle et Static Analysis Utilities.

    Une fois que vous avez install ces plugins, vous pouvez paramtrer la cration des rapports dans laconfiguration de votre projet. Cochez la case "Publiez les analyses de rsultat Checkstyle". Dans unbuild free-style, vous aurez besoin de spcifier un patron de chemin pour trouver les rapports XML deCheckstyle ; dans un build Maven 2, Jenkins saurait o les chercher par lui-mme.

    Ceci fournira des rapports Checkstyle basiques, mais comme dhabitude, vous pouvez personnaliserceci en cliquant sur le bouton Avanc. Dans un build Maven 2, vous pouvez configurer les valeurs deseuils de la sant (combien de violations passeront le build d'ensoleill orageux), et aussi filtrer lespriorits de violations que vous voulez inclure dans le calcul. Par exemple, vous pourriez ne vouloirprendre en compte que les problmes de haute priorit pour le statut de licne mtorologique.

    Les builds free-style ont quelques options supplmentaires que vous pouvez configurer ; en particulier,vous pouvez rendre le build instable (balle jaune) ou mme en chec (balle rouge) si vous avez un nombrede violations suprieur celui dfini, ou s'il y a plus de nouvelle violations que le nombre donn(voirFigure 9.12, Configurer le plugin Checkstyle). Ainsi, dans la configuration de lillustration, sil ya plus de 50 nouvelles violations Checkstyle de nimporte quelle priorit dans un build, le build serasignal comme instable. Cela a certainement son utilit pour Checkstyle, mais cela peut aussi se rvlertrs utile avec FindBugs, o les problmes de haute priorit reprsentent souvent des bugs dangereuxet potentiellement bloquants.

  • 257

    Figure 9.12. Configurer le plugin Checkstyle

    Maintenant, lorsque le build s'excute, Jenkins gnrera un graphique de tendance et des rapportsdtaills pour les violations Checkstyle (voir Figure 9.13, Afficher les tendances Checkstyle). De l,vous pouvez descendre pour voir les violations par priorit, par catgorie, par type de dmarrage, parpackage, etc.

    Figure 9.13. Afficher les tendances Checkstyle

  • 258

    Comme nous lavons mentionn prcdemment, la mme approche marche aussi avec le plugin PMDet le plugin FindBugs. Ces plugins sont un excellent moyen de fournir des rapports plus concentrs surles rsultats dun outil particulier, et vous donnent aussi plus de contrle sur limpact que ces violationsauront sur les rsultats du build.

    9.6. Les rapports sur la complexit du codeLa complexit du code est un autre aspect important de la qualit du code. La complexit du code estmesure avec un certain nombre de moyens, mais une mesure de complexit gnralement utilise (etfacile comprendre) est la complexit cyclomatique, qui consiste mesurer le nombre de cheminsdiffrents travers une mthode. En utilisant cette mtrique, le code complexe a gnralement un grandnombre dinstructions conditionnelles et de boucles imbriques, qui rendent le code plus difficile comprendre et dboguer.

    Il y a aussi une thorie de qualit de code mettant en corrlation la complexit du code et la couverturedu code qui donne une ide gnrale de la fiabilit dune portion de code. Celle-ci est base sur lide(trs comprhensible) que le code qui est la fois complexe et peu test est plus susceptible de contenirdes bugs que du code simple et bien test.

    Le plugin Coverage Complexity Scatter Plot est conu pour vous laisser visualiser cette informationdans vos builds Jenkins (voir Figure 9.14, Un nuage de point couverture/complexit.). Les mthodesdangereusement complexes et/ou non testes apparatront hautes sur le graphique, alors que les mthodesbien crites et bien testes apparatront plus basses.

    Figure 9.14. Un nuage de point couverture/complexit.

    Le graphique de dispersion vous donne un bon aperu de ltat de votre code en termes de complexitet de couverture de test, mais vous pouvez aussi descendre pour poursuivre lenqute. Si vous cliquezsur nimporte quel point dans le graphique, vous pouvez voir les mthodes correspondantes, avec leurcouverture de test et leur complexit (voir Figure 9.15, Vous pouvez cliquer sur nimporte quel pointdu graphique pour poursuivre lenqute).

  • 259

    Figure 9.15. Vous pouvez cliquer sur nimporte quel point du graphique pour poursuivre lenqute

    Au moment de la rdaction de ce livre, le plugin ncessite Clover, donc votre build a besoin davoirgnr un rapport XML de couverture de Clover, et vous avez besoin davoir install et configur leplugin Clover de Jenkins (voir Section 6.6.2, Mesurer la couverture de code avec Clover). Cependant,un support pour Cobertura et dautres outils est prvu.

    9.7. Les rapports sur les tches ouvertes

    Quand il sagit de qualit de code, lanalyse statique nest pas le seul outil que vous pouvez utiliser. Unautre indicateur de la sant gnrale de votre projet peut tre trouv avec le nombre de FIXME, TODO,@deprecated, et autres balises similaires disperses dans le code source. Sil y en a beaucoup, celapeut tre un signe que le code de base a beaucoup de travail inachev, et nest donc pas dans un tattrs finalis.

    Le plugin Task Scanners de Jenkins permet de garder une trace de ces sortes de balises dans votre codesource, et optionnellement de signaler un build avec une mauvaise icne de temps sur le tableau de bordsil y a beaucoup trop de tches ouvertes.

    Pour le configurer, vous devez installer la fois le plugin Static Analysis Utilities et le plugin TaskScanner. Une fois qu'ils sont installs, vous pouvez activer le plugin dans votre projet en cochant la case Recherche des tches ouvertes dans le workspace dans la section Configuration du Build dans laconfiguration de la tche de votre projet.

    Configurer le plugin Task Scanner est assez simple (voir Figure 9.16, Configurer le plugin TaskScanner est simple). Vous entrez simplement les balises que vous souhaitez suivre, avec diffrentespriorits si vous considrez certaines balises comme tant plus importantes que dautres. Par dfaut, leplugin scrutera tout le code source java dans le projet, mais vous pouvez redfinir ce comportement encompltant le champ Files to scan. Dans Figure 9.16, Configurer le plugin Task Scanner est simple,par exemple, nous vrifions les balises pour les fichiers XML et JSP.

  • 260

    Figure 9.16. Configurer le plugin Task Scanner est simple

    Le bouton Avanc vous donne accs des options plus sophistiqus. Probablement, les plus utiles sontles seuils de sant, qui vous laissent dfinir le nombre maximum de problmes tolrs avant que le buildne soit plus considr ensoleill , et le nombre minimum de problmes requis pour le statut de temps orageux .

    Le plugin gnre un graphique qui montre les tendances de balises par ordre de priorit (voir Figure 9.17,Le graphique de tendances des tches ouvertes). Si vous cliquez sur le rapport des tches ouvertes,vous pouvez aussi voir le dtail des tches par module Maven, package ou fichier, ou encore une listedes tches ouvertes.

    Figure 9.17. Le graphique de tendances des tches ouvertes

  • 261

    9.8. Intgration avec SonarSonar3 est un outil qui centralise toute une gamme de mesures de qualit de code en un seul site web (voirFigure 9.18, Rapport de qualit de code par Sonar.). Il utilise un certain nombre de plugins Maven(Checkstyle, PMD, FindBugs, Cobertura ou Clover, et dautres) pour analyser des projets Maven etgnrer un ensemble complet de rapports sur la qualit du code. Les rapports Sonar sur la couverture ducode, le respect des rgles, et la documentation, mais aussi sur des mesures de plus haut niveau comme lacomplexit, la maintenabilit et mme la dette technique. Vous pouvez utiliser des plugins pour tendreses fonctionnalits et ajouter le support pour dautres langages (comme le support de CodeNarc pourdu code source Groovy). Les rgles utilises par divers outils sont gres et configures de manirecentralise sur le site web de Sonar, et les projets Maven en cours danalyse ne ncessitent aucuneconfiguration particulire. Cela fait de Sonar l'outil parfait pour travailler sur des projets Maven o vousavez un contrle limit sur les fichiers POM.

    Figure 9.18. Rapport de qualit de code par Sonar.

    Dans lune des utilisations les plus courantes de Sonar, Sonar excute automatiquement un ensemblede plugins Maven lis la qualit de code sur votre projet Maven, et stocke les rsultats dans une basede donnes relationnelle. Le serveur Sonar, que vous excutez sparment, analyse alors les rsultats etles affiche comme indiqu dans Figure 9.18, Rapport de qualit de code par Sonar..

    3 http://www.sonarsource.org

    http://www.sonarsource.orghttp://www.sonarsource.org

  • 262

    Jenkins sintgre bien avec Sonar. Le plugin Sonar de Jenkins vous laisse dfinir les instances Sonarpour tous vos projets, et active ensuite Sonar pour des builds particuliers. Vous pouvez excuter votreserveur Sonar sur une machine diffrente de votre instance Jenkins, ou sur la mme. La seule contrainteest que linstance Jenkins doit avoir un accs JDBC la base de donnes de Sonar, puisquil injecte desmesures de qualit de code directement dans la base de donnes, sans passer par le site web de Sonar(voir Figure 9.19, Jenkins et Sonar).

    Jenkins Sonar database

    Figure 9.19. Jenkins et Sonar

    Sonar a aussi une amorce Ant (avec une amorce Gradle en cours de dveloppement au moment de lardaction de ce livre) pour les utilisateurs non-Maven.

    Vous installez le plugin comme dhabitude, via le gestionnaire de plugin. Une fois install, vousconfigurez le plugin Sonar de Jenkins dans lcran Configurer le systme, dans la section Sonar. Il sagitde dfinir vos instances Sonar vous pouvez configurer autant dinstances que vous avez besoin. Laconfiguration par dfaut suppose que vous excutez une instance locale de Sonar avec la base de donnesembarque par dfaut. Ceci est utile des fins de test, mais nest pas trs volutif. Pour un environnementde production, vous excuterez alors Sonar sur une vraie base de donnes comme MySQL ou Postgres, etvous aurez besoin de configurer la connexion JDBC sur la base de donnes de production de Sonar dansJenkins. Vous pouvez faire ceci en cliquant le bouton Avanc et en remplissant les champs appropris(voir Figure 9.20, Configurer Sonar dans Jenkins).

  • 263

    Figure 9.20. Configurer Sonar dans Jenkins

    Lautre chose que vous devez configurer est le moment o le build de Sonar dbutera dans une tchede build o Sonar est activ. Vous configurez gnralement Sonar pour qu'il s'excute avec lune deslongues tches de build Jenkins, comme le build de mesure de qualit de code. Ce nest pas trs utiled'excuter le build Sonar plus dune fois par jour, puisque Sonar stocke les mesures sur des tranches de24 heures. La configuration par dfaut excutera le build de Sonar, dans une tche de build o Sonarest activ, chaque fois quune tche est dclenche par un build priodiquement planifi ou par un buildmanuel.

    Pour activer Sonar dans votre tche de build, avec des options de configuration lchelle du systme, ilsuffit de cocher loption Sonar dans Actions la suite du build (voir Figure 9.21, Configurer Sonar dansune tche de build). Sonar s'excutera chaque fois que votre build est lanc par lun des mcanismesde dclenchements dfinis ci-dessus.

  • 264

    Figure 9.21. Configurer Sonar dans une tche de build

    Vous configurez gnralement Sonar pour qu'il s'excute sur une base rgulire, par exemple tous lessoirs ou une fois par semaine. Vous pouvez donc activer Sonar sur votre tche de build de test unitaire/dintgration normal, simplement en ajoutant un ordonnanceur (voir Figure 9.22, Planifier les buildsSonar). Cela vite les dtails de configuration en double entre les tches. Ou, si vous avez dj unetche de build ordonnance qui dmarre avec une frquence approprie (comme un build ddi auxmesures de qualit de code), vous pouvez activer Sonar sur cette tche de build.

    Figure 9.22. Planifier les builds Sonar

    Si vous cliquez sur le bouton Avanc, vous pouvez spcifier dautres options plus sophistiques, commelancer votre build Sonar sur une branche spare, passer des options de ligne de commande Mavensupplmentaires (comme de la mmoire supplmentaire), ou redfinir la configuration par dfaut desdclencheurs.

    Par dfaut, Sonar s'excutera mme si le build normal choue. Cest gnralement ce que lon souhaite,puisque Sonar devrait enregistrer les builds et les tests dfaillants aussi bien que les rsultats russis.Cependant, si cest ncessaire, vous pouvez aussi dsactiver cette option dans les options avances.

  • 265

    9.9. ConclusionLa qualit de code est une partie importante du processus de build, et Jenkins fournit un excellent supportpour la vaste gamme doutils lis la qualit de code qui existent. En consquence, Jenkins devrait treun lment cl de votre stratgie sur la qualit du code.

  • Chapter 10. Builds avancs10.1. Introduction

    Dans ce chapitre, nous regarderons quelques configurations avances de tches de build. Noustraiterons des builds paramtrs, qui permettent Jenkins de demander l'utilisateur des paramtressupplmentaires qui seront passs la tche de build, et des tches de build multiconfigurations, qui vouspermettent d'excuter une simple tche selon de nombreuses variations. Nous verrons comment excuterles tches en parallle, et comment attendre le rsultat d'une ou plusieurs tches avant de continuer.Nous verrons enfin comment implmenter des stratgies de promotion de build et de pipelines de buildafin de pouvoir utiliser Jenkins non seulement comme un serveur de build, mais aussi comme un serveurde dploiement.

    10.2. Tches de build paramtres

    Les builds paramtrs sont un concept puissant vous permettant d'ajouter une nouvelle dimension vostches de build.

    Le plugin Parameterized Build vous permet de configurer des paramtres pour vos tches de build, quipeuvent tre entrs par l'utilisateur lorsque le build est dclench, ou (comme nous le verrons plus tard)depuis une autre tche.

    Par exemple, vous pourriez avoir une tche de dploiement, o vous choisiriez un environnement cibledans une liste droulante quand vous dmarrez le build. Vous pourriez aussi vouloir spcifier la versionde l'application que vous souhaitez dployer. Ou, en excutant une tche de build incluant des testsweb, vous pourriez spcifier le navigateur dans lequel vous voulez faire tourner vos tests Selenium ouWebDriver. Vous pouvez mme tltransfrer un fichier ncessaire l'excution de la tche de build.

    Notez que c'est le rle du script de build d'analyser et de traiter correctement les valeurs de paramtres Jenkins fournit simplement une interface utilisateur permettant d'entrer les valeurs des paramtres,puis de passer ces paramtres au script de build.

    10.2.1. Crer des tches de build paramtres

    Vous installez le plugin Parameterized Build comme d'habitude, via l'cran de gestion des plugins. Unefois que vous avez fait cela, configurer une tche de build paramtre est simple. Cochez simplementl'option Ce build a des paramtres et cliquez sur Ajouter un paramtre pour ajouter un nouveauparamtre de tche de build (voir Figure 10.1, Crer une tche de build paramtre). Vous pouvezajouter des paramtres n'importe quelle sorte de build, et vous pouvez ajouter autant de paramtresque vous voulez une tche de build donne.

  • 268

    Figure 10.1. Crer une tche de build paramtre

    Pour ajouter un paramtre votre tche de build, slectionnez simplement le type de paramtre dansla liste droulante. Cela vous permettra de configurer les dtails de votre paramtre (voir Figure 10.2,Ajouter un paramtre la tche de build). Vous pouvez choisir diffrents types de paramtres,comme des chanes de caractres, des boolens, et des listes droulantes. En fonction du type que vouschoisissez, vous devrez entrer des valeurs de configuration lgrement diffrentes, mais le processus debase est le mme. Tous les types de paramtres, l'exception du paramtre Fichier, ont un nom et unedescription, et le plus souvent une valeur par dfaut.

    Dans Figure 10.3, Ajouter un paramtre la tche de build, par exemple, nous ajoutons un paramtreappel version une tche de dploiement. La valeur par dfaut (RELEASE) sera initialement affichelorsque Jenkins demandera l'utilisateur de valoriser ce paramtre, donc si l'utilisateur ne change rien,cette valeur sera utilise.

    Figure 10.2. Ajouter un paramtre la tche de build

    Quand l'utilisateur dmarre un build paramtr (les builds paramtrs sont trs souvent dmarresmanuellement), Jenkins propose une page dans laquelle l'utilisateur peut entrer une valeur pour chacundes paramtres de la tche de build (voir Figure 10.3, Ajouter un paramtre la tche de build).

  • 269

    Figure 10.3. Ajouter un paramtre la tche de build

    10.2.2. Adapter vos build pour travailler avec des scripts de buildsparamtrs

    Une fois que vous avez ajout un paramtre, vous devez configurer vos scripts de build pour l'utiliser.Bien choisir le nom du paramtre est important, parce que c'est aussi le nom de la variable que Jenkinspassera comme variable d'environnement lorsqu'il lance la tche de build. Pour illustrer cela, considronsla configuration de build trs basique de Figure 10.4, Dmonstration d'un paramtre de build, o onaffiche simplement le paramtre de build en retour dans la console. Notez que, pour rendre les variablesplus portables travers diffrents systmes d'exploitation, il est prfrable de les mettre en majuscules.

    Figure 10.4. Dmonstration d'un paramtre de build

    Quand on excute cela, on obtient les lignes suivantes dans la console :

    Started by user anonymousBuilding on master[workspace] $ /bin/sh -xe /var/folders/y+/y+a+wZ-jG6WKHEm9KwnSvE+++TI/-Tmp-/jenkins5862957776458050998.sh+ echo Version=1.2.3Version=1.2.3Notifying upstream projects of job completionFinished: SUCCESS

    Vous pouvez aussi utiliser ces variables d'environnement au sein de vos scripts de build. Par exemple,dans un build Ant ou Maven, vous pouvez utiliser la proprit spciale env pour accder aux variablesd'environnement courantes :

  • 270

    Une autre option consiste passer les paramtres au script de build comme une valeur de proprit. Cequi suit est un exemple plus pratique d'un fichier POM de Maven. Dans cet exemple, Maven est configurpour dployer un fichier WAR spcifique. Nous fournissons la version du fichier WAR dployer dansla proprit target.version, qui est utilis dans la dclaration de la dpendance, comme montr ci-dessous :

    ... com.wakaleo.gameoflife gameoflife-web war ${target.version} RELEASE ...

    Quand on invoque Maven, on passe le paramtre comme l'une des proprits du build (voir Figure 10.5,Ajouter un paramtre la tche de build Maven). On peut ensuite utiliser un outil comme Cargo pourfaire le dploiement rel Maven tlchargera la version demande du WAR depuis le gestionnairede dpt d'entreprise, et la dploiera sur un serveur d'application.

    Figure 10.5. Ajouter un paramtre la tche de build Maven

    En rsum, cela montre comment il vous est possible d'intgrer des paramtres de tches de builddans vos builds. Toutefois, en plus des bons vieux paramtres de type chane de caractres, il existequelques types de paramtres plus sophistiqus, que nous regarderons dans les paragraphes suivants(voir Figure 10.6, Diffrents types de paramtres sont disponibles).

  • 271

    Figure 10.6. Diffrents types de paramtres sont disponibles

    10.2.3. Types de paramtres plus avancs

    Les paramtres Mot de passe sont, comme vous pourriez vous y attendre, trs similaires aux paramtresString, mis part qu'ils sont affichs comme des champs mot de passe.

    Il existe plusieurs cas o vous souhaiteriez prsenter un ensemble limit d'options de paramtres.Dans un build de dploiement, vous pourriez permettre l'utilisateur de choisir parmi un ensemblede serveurs cibles. Ou vous pourriez prsenter une liste de navigateurs supports pour une suite detests d'acceptation. Les paramtres Choix vous permettent de dfinir un ensemble de valeurs qui serontaffiches dans une liste droulante (voir Figure 10.7, Configurer un paramtre Choix). Vous devezfournir une liste de valeurs possibles, une par ligne, en commenant par la valeur par dfaut.

    Figure 10.7. Configurer un paramtre Choix

    Les paramtres Boolen sont, comme vous vous y attendez, des paramtres qui prennent comme valeurtrue ou false. Ils sont prsents en tant que case cocher.

    Deux types de paramtres plus exotiques, qui se comportent un peu diffremment des autres, sont lesparamtres Run et les paramtres Fichier.

    Les paramtres Run vous permettent de slectionner une excution particulire (ou un build) d'un builddonn (voir Figure 10.8, Configurer un paramtre Run). L'utilisateur effectue une slection partir

  • 272

    d'une liste de numros d'excution de build. L'URL correspondant l'excution est stocke dans leparamtre spcifi.

    Figure 10.8. Configurer un paramtre Run

    L'URL (qui devrait ressembler http://jenkins.myorg.com/job/game-of-life/197/) peut tre utilise pourobtenir une information ou des artefacts d'une excution de build. Par exemple, vous pourriez rcuprerle fichier JAR ou WAR archiv lors d'un build prcdent et excuter des tests plus pousss sur celui-ci dans une tche de build spare. Ainsi, pour accder au fichier WAR d'un build prcdent dans unprojet Maven multimodules, l'URL ressemblerait celle-ci :

    http://buildserver/job/game-of-life/197/artifact/gameoflife-web/target/ gameoflife.war

    Donc, en utilisant le paramtre configur dans Figure 10.8, Configurer un paramtre Run, vouspourriez accder au fichier WAR en utilisant l'expression suivante :

    ${RELEASE_BUILD}gameoflife-web/target/gameoflife.war

    Les paramtres Fichier vous permettent de tltransfrer un fichier dans l'espace de travail de latche de build, afin qu'il puisse tre utilis dans le script de build (voir Figure 10.9, Configurer unparamtre Fichier). Jenkins stockera le fichier l'emplacement spcifi dans l'espace de travail duprojet, o vous pouvez y accder dans vos scripts de build. Vous pouvez utiliser la variable WORKSPACEpour faire rfrence au rpertoire de l'espace de travail courant, afin que vous puissiez manipulerle fichier tltransfer dans Figure 10.9, Configurer un paramtre Fichier en utilisant l'expression${WORKSPACE}/deploy/app.war.

    Figure 10.9. Configurer un paramtre Fichier

  • 273

    10.2.4. Construire partir d'un tag Subversion

    Le dclenchement paramtr possde un support spcial pour Subversion, vous permettant ainsi deraliser un build partir d'un tag Subversion spcifique. C'est utile si vous voulez lancer un build derelease en utilisant un tag gnr par un build prcdent. Par exemple, une tche de build amont pourraitcrer un tag d'une rvision particulire. Vous pourriez aussi utiliser le processus standard de releaseMaven (voir Section 10.7.1, Gestion des releases Maven avec le plugin M2Release) pour gnrer unenouvelle release. Dans ce cas, un tag avec le numro de release Maven sera automatiquement gnrdans Subversion.

    Cette approche est utile pour des projets qui ont besoin d'tre partiellement ou entirement reconstruitsavant de pouvoir tre dploys sur une plateforme donne. Par exemple, vous pourriez avoir besoind'excuter le build Ant ou Maven en utilisant diffrentes proprits ou profils pour diffrentesplateformes, afin que les fichiers de configuration spcifiques puissent tre embarqus dans les WARou EAR dploys.

    Vous pouvez configurer un build Jenkins pour qu'il s'excute sur un tag slectionn en utilisant le typede paramtre List Subversion Tag (voir Figure 10.10, Ajouter des paramtres pour raliser un build partir d'un tag Subversion). Vous devez simplement fournir l'URL du dpt Subversion pointant surle rpertoire des tags de votre projet.

    Figure 10.10. Ajouter des paramtres pour raliser un build partir d'un tag Subversion

    Quand vous excuterez ce build, Jenkins proposera une liste de tags dans laquelle choisir (voirFigure 10.11, Raliser un build partir d'un tag Subversion).

    Figure 10.11. Raliser un build partir d'un tag Subversion

  • 274

    10.2.5. Raliser un build partir d'un tag Git

    Raliser un build partir d'un tag Git n'est pas aussi simple que de le faire partir d'un tag Subversion,bien que vous puissisez toujours utiliser un paramtre pour indiquer quel tag utiliser. En effet, cause dela nature mme de Git, quand Jenkins obtient une copie du code source depuis Git, il clone le dpt Git,en incluant tous les tags. Une fois que vous avez la dernire version du dpt sur votre serveur Jenkins,vous pouvez ensuite procder la rcupration d'une version en utilisant git checkout .

    Pour configurer cela avec Jenkins, vous devez commencer par ajouter un paramtre String votre tchede build (appele RELEASE dans cet exemple voir Figure 10.12, Configurer un paramtre pour untag Git). Contrairement au support Subversion, il n'est pas possible de lister les tags Git disponiblesdans une liste droulante, les utilisateur devront donc connatre le nom du tag qu'ils veulent livrer.

    Figure 10.12. Configurer un paramtre pour un tag Git

    Une fois que vous avez ajout ce paramtre, vous devez faire un checkout du tag correspondant une foisque le dpt a t clon localement. Ainsi, si vous avez un build freestyle, la premire tape du build seraun appel en ligne de commande Git pour faire un checkout du tag rfrenc par le paramtre RELEASE(voir Figure 10.13, Raliser un build partir d'un tag Git). Bien sr, un moyen plus portable de fairecela serait d'crire un simple script Ant ou Groovy pour faire l'quivalent d'une faon plus indpendantedu systme d'exploitation.

  • 275

    Figure 10.13. Raliser un build partir d'un tag Git

    10.2.6. Dmarrer une tche de build paramtre distance

    Vous pouvez aussi dmarrer une tche de build paramtre distance, en invoquant l'URL de la tchede build. La forme typique d'une URL de tche de build est illustre ci-aprs :

    http://jenkins.acme.org/job/myjob/buildWithParameters?PARAMETER=Value

    Ainsi, dans l'exemple ci-dessus, vous pourriez dclencher un build de la faon suivante :

    http://jenkins.acme.org/job/parameterized-build/buildWithParameters?VERSION=1.2.3

    Quand vous utilisez une URL pour dmarrer une tche de build de cette faon, rappelez-vous queles noms des paramtres sont sensibles la casse, et que les valeurs doivent tre chappes (commen'importe quel autre paramtre HTTP). Et si vous utilisez un paramtre Run, vous devez fournir le nomde la tche de build et le numro d'excution (e.g., game-of-life#197) et pas seulement le numrod'excution.

    10.2.7. Historique des tches de build paramtres

    Enfin, il est indispensable de savoir quels paramtres ont t utiliss pour lancer un build paramtrparticulier. Par exemple, dans une tche de build de dploiement automatis, il est utile de savoirexactement quelle version a rellement t dploye. Heureusement, Jenkins stocke ces valeurs dansl'historique de build (voir Figure 10.14, Jenkins stocke les valeurs des paramtres utilises pour chaquebuild), afin que vous puissiez toujours retrouver un ancien build et en vrifier les paramtres.

  • 276

    Figure 10.14. Jenkins stocke les valeurs des paramtres utilises pour chaque build

    10.3. Dclencheurs paramtrs

    Quand vous dclenchez une autre tche de build depuis une tche de build paramtre, il est souvent utilede pouvoir passer les paramtres du build courant au nouveau. Supposons, par exemple, que vous ayezune application qui doit tre teste sur plusieurs bases de donnes diffrentes. Comme nous l'avons vu,vous pourriez faire cela en configurant une tche de build paramtr qui accepte la base de donnes ciblecomme un paramtre. Vous slectionneriez une srie de builds, et tous auraient besoin de ce paramtre.

    Si vous essayez de faire cela en utiliser l'option conventionnelle "Construire d'autres projets" dans lasection Actions Post-Build, cela ne marchera pas. En effet, vous ne pouvez pas dclencher un buildparamtr de cette faon.

    Toutefois, vous pouvez le faire en utilisent le plugin Jenkins Parameterized Trigger. Ce plugin vouspermet de configurer vos tches de build la fois pour dclencher des builds paramtrs et pour passerdes paramtres arbitraires ces builds.

    Une fois que vous avez install ce plugin, vous trouverez l'option Dclencher des builds paramtrssur d'autres projets dans la page de configuration de votre tche de build (voir Figure 10.16, Ajouterun dclencheur paramtr une tche de build). Ceci vous permet de dmarrer une autre tche de buildde diffrentes faons. En particulier, vous pouvez lancer une tche de build ultrieure, en passant lesparamtres courant cette nouvelle tche, ce qui est impossible faire avec un builld paramtr normal.La meilleure faon de voir comment cela fonctionne est au travers d'un exemple.

    Dans Figure 10.15, Tche de build paramtr pour des tests unitaires nous avons une tche de buildinitiale. Cette tche prend un unique paramtre, DATABASE, qui spcifie la base de donnes utiliserpour les tests. Comme nous l'avons vu, Jenkins demandera l'utilisateur de saisir cette valeur chaquefois qu'un build sera lanc.

  • 277

    Figure 10.15. Tche de build paramtr pour des tests unitaires

    Supposons maintenant que nous voulons dclencher une seconde tche de build pour excuter des testsd'intgration plus complets une fois que la premire tche a termin. Cependant nous avons besoind'excuter les tests sur la mme base de donnes. On peut faire cela en configurant un dclencheurparamtr pour dmarrer cette seconde tche (voir Figure 10.16, Ajouter un dclencheur paramtr une tche de build).

    Figure 10.16. Ajouter un dclencheur paramtr une tche de build

    Dans ce cas, nous passons simplement les paramtres du build courant. Cette seconde tche de builddmarrera automatiquement aprs la premire, avec la valeur du paramtre DATABASE fournie parl'utilisateur. Vous pouvez aussi configurer finement la politique de dclenchement en indiquant Jenkinsquand le build doit tre lanc. Typiquement, vous dclencheriez seulement un build aval aprs que votrebuild ait russi, mais avec le plugin Parameterized Trigger vous pouvez aussi configurer les builds pourqu'ils dclenchent mme si le build est instable, ou seulement quand le build choue ou encore demander ce qu'il soit dclench quoi qu'il arrive au premier build. Vous pouvez mme configurer plusieursdclencheurs pour la mme tche de build.

  • 278

    Naturellement, la tche de build que vous dclenchez doit tre une tche de build paramtr (commeillustr dans Figure 10.17, La tche de build que vous dclenchez doit aussi tre une tche paramtre),et vous devez transmettre tous les paramtres qu'elle requiert.

    Figure 10.17. La tche de build que vous dclenchez doit aussi tre une tche paramtre

    Cette fonctionnalit possde en fait des applications bien plus larges que de simplement transmettreles paramtres du build courant. Vous pouvez aussi dclencher une tche de build paramtr avec unensemble arbitraire de paramtres, ou utiliser une combinaison de paramtres passs au build courant,et vos propres paramtres traditionnels. Ou alors, si vous avez beaucoup de paramtres, vous pouvezles charger partir d'un fichier de proprits. Dans Figure 10.18, Passer un paramtre prdfini unetche de build paramtr, nous passons la fois les paramtres du build courant (la variable DATABASEdans ce cas), et un paramtre additionnel appel TARGET_PLATFORM.

  • 279

    Figure 10.18. Passer un paramtre prdfini une tche de build paramtr

    10.4. Tches de build multiconfiguration

    Les tches de build multiconfiguration sont une fonctionnalit extrmement puissante de Jenkins. Unetche de build multiconfiguration peut tre vue comme une tche de build paramtr qui peut treautomatiquement lance avec toutes les combinaisons possibles de paramtres qu'elle puisse accepter.Elles sont particulirement utiles pour les tests, vous permettant ainsi de tester votre application avecune seule tche de build, mais avec une grande varit de conditions (navigateurs, bases de donnes,et ainsi de suite).

    10.4.1. Configurer un build multiconfiguration

    Pour crer une nouvelle tche de build multiconfiguration, choisissez simplement l'option suivante surla page Nouvelle Tche (voir Figure 10.19, Crer une tche de build multiconfiguration).

  • 280

    Figure 10.19. Crer une tche de build multiconfiguration

    Une tche de build multiconfiguration ressemble n'importe quelle autre tche, mais avec un lmentsupplmentaire trs important : la Matrice de Configuration (voir Figure 10.20, Ajouter un axe unbuild multiconfiguration). C'est l que vous dfinissez les diffrentes configurations qui seront utilisespour excuter vos builds.

    Figure 10.20. Ajouter un axe un build multiconfiguration

    Vous pouvez dfinir diffrents axes d'options de configuration, incluant l'excution de la tche de buildsur diffrents esclaves ou sur diffrents JDKs, ou en fournissant vos propres proprits personnalisesau build. Par exemple, dans les tches de build discutes prcdemmennt, nous pourrions vouloir testernotre application pour diffrentes bases de donnes et diffrents systmes d'exploitation. Nous pourrionsdfinir un axe dfinissant les machines esclaves avec diffrents systmes d'exploitation sur lesquels nousvoudrions faire tourner nos builds, et un autre axe dfinissant toutes les valeurs possibles de bases dedonnes. Jenkins excutera ensuite la tche de build pour chaque base de donnes et chaque systmed'exploitation possibles.

    Regardons prsent les types d'axes que nous pouvons dfinir.

    10.4.2. Configurer un axe Esclave

    La premire option consiste configurer votre build pour excuter simultanment le build sur diffrentesmachines esclaves (voir Chapter 11, Builds distribus). Evidemment, l'ide d'avoir un ensemble de

  • 281

    machines esclaves est gnralement pour que vous puissiez excuter votre build sur n'importe laquelle.Mais il y a des cas o il est normal d'tre plus slectif. Par exemple, vous pourriez vouloir lancer vostests sur Windows, Mac OS X, et Linux. Dans ce cas, vous crez un nouvel axe pour vos noeudsesclaves, comme montr dans Figure 10.21, Dfinir un axe de noeuds esclave. Vous pouvez choisirles noeuds que vous voulez utiliser de deux faons : par label ou par noeud individuel. Utiliser deslabels vous permet d'identifier des catgories de noeuds de construction (par exemple, des machinesWindows), sans lier le build aucune machine en particulier. C'est une option plus flexible, et ellerend plus facile l'extension de votre capacit de build si ncessaire. Parfois, cependant, vous pouvezrellement vouloir excuter un build sur une machine spcifique. Dans ce cas, vous pouvez utiliserl'option "Noeuds individuels" et choisir la machine dans la liste.

    Figure 10.21. Dfinir un axe de noeuds esclave

    Si vous avez besoin de plus de flexibilit, vous pouvez aussi utiliser une Label Expression, ce qui vouspermet de dfinir quels noeuds esclaves peuvent tre utiliss pour un axe particulier en utilisant desexpressions boolennes et des oprateurs logiques pour combiner les labels. Par exemple, supposonsque vous avez dfini des labels pour les machines esclaves en fonction du systme d'exploitation(windows, linux) et des bases de donnes installes (oracle, mysql, db2). Pour dfinir un axen'excutant les tests que pour les machines Windows sur lesquelles est install MySQL, vous pouvezutiliser une expression comme windows && mysql.

    Nous traitons du travail avec des noeuds esclaves et les builds distribus plus en dtail dans Chapter 11,Builds distribus.

    10.4.3. Configurer un axe JDK

    Si vous dployez votre application sur une large base client sur laquelle vous avez un contrle limitde l'environnement cible, vous pouvez avoir besoin de tester votre application en testant diffrentesversions de Java. Dans ce genre de cas, il est utile de pouvoir mettre en place un axe JDK dans unbuild multiconfiguration. Quand vous ajoutez un axe JDK, Jenkins propose automatiquement la listedes versions de JDK dont il a connaissance (voir Figure 10.22, Dfinir un axe de versions de JDK). Sivous avez besoin d'utiliser des JDKs additionnels, ajoutez les simplement votre page de configurationJenkins.

  • 282

    Figure 10.22. Dfinir un axe de versions de JDK

    10.4.4. Axe personnalis

    Le troisime type d'axe vous permet de dfinir diffrentes faons d'excuter votre tche de build, basessur des variables arbitraires que vous dfinissez. Par exemple, vous pouvez fournir une liste de basesde donnes que vous avez besoin de tester, ou une liste de navigateurs utiliser dans vos tests web.Ceci est trs similaire aux paramtres pour une tche de build paramtr, except que vous fournissezla liste complte des valeurs possibles, et que plutt que d'interroger l'utilisateur pour qu'il entre unevaleur, Jenkins lance le build avec toutes les valeurs fournies (Figure 10.23, Dfinir un axe spcifique l'utilisateur).

    Figure 10.23. Dfinir un axe spcifique l'utilisateur

    10.4.5. Excuter un Build Multiconfiguration

    Une fois que vous avez configur les axes, vous pouvez excuter votre build multiconfiguration commen'importe quel autre. Toutefois, Jenkins traitera chaque combinaison de variables comme un buildspar. Jenkins affiche les rsultats agrgs dans un tableau, o toutes les combinaisons sont montres(voir Figure 10.24, Rsultats de build multiconfiguration). Si vous cliquez sur les boules, Jenkins vousemmnera aux rsultats dtaills pour un build particulier.

  • 283

    Figure 10.24. Rsultats de build multiconfiguration

    Par dfaut, Jenkins excutera les tches de build en parallle. Toutefois, il y a quelques cas o cela n'estpas une bonne ide. Par exemple, de nombreuses applications web Java utilisent des tests Seleniumou WebDriver s'excutant sur une instance locale de Jetty automatiquement dmarre par la tche. Lesscripts de build de ce genre doivent tre spcialement configurs pour pouvoir s'excuter en paralllesur la mme machine, pour viter les conflits de ports. L'accs concurrent la base de donnes pendantles tests peut tre une autre source de problmes si la gestion de la concurrence n'est pas intgre laconception des tests. Si vos builds ne sont pas conus pour fonctionner en parallle, vous pouvez forcerJenkins excuter les tests de manire squentielle en cochant la case Excuter chaque configurationsquentiellement en bas de la section Configuration de la matrice.

    Par dfaut, Jenkins excutera toutes les combinaisons possibles des diffrents axes. Donc, dans l'exempleci-dessus, nous avons trois environnements, deux JDKs et quatre bases de donnes. Ceci rsulte en untotal de 24 builds. Toutefois, dans certains cas, excuter certaines combinaisons ne pourrait avoir aucunsens (ou n'tre pas possible). Par exemple, supposons que vous ayez une tche de build qui excutedes tests web automatiss. Si un axe contient les navigateurs web tester (Firefox, Internet Explorer,Chrome, etc.) et un autre les systmes d'exploitation (Linux, Windows, Mac OS), cela n'aurait pasbeaucoup de sens d'excuter Internet Explorer avec Linux ou Mac OS.

    L'option de Filtre de Combinaison vous permet de mettre en place des rgles dfinissant quellescombinaisons de variables sont valides. Ce champ est une expression boolene Groovy qui utilise les

  • 284

    noms des variables que vous dfinissez pour chaque axe. L'expression doit valoir true pour que lebuild s'excute. Par exemple, supposez que vous ayez une tche de build excutant des tests web dansdiffrents navigateurs sur diffrents systmes d'exploitation (voir Figure 10.25, Mettre en place un filtrede combinaison). Les tests ncessitent d'excuter Firefox, Internet Explorer et Chrome, sur Windows,Mac OS X, et Linux. Toutefois Internet Explorer ne fonctionne que sous Windows, et Chrome nefonctionne pas sous Linux.

    Figure 10.25. Mettre en place un filtre de combinaison

    Pour configurer un Filtre de Combinaison, nous pourrions utiliser une expression comme la suivante :

    (browser=="firefox")|| (browser=="iexplorer" && os=="windows")|| (browser=="chrome" && os != "linux")

    Ceci rsulterait dans le fait que seules les combinaisons correctes navigateur/systme d'exploitationseraient excutes (voir Figure 10.26, Rsultats de build utilisant un filtre de combinaison). Les buildsexcuts sont affichs dans les couleurs habituelles, alors que les builds non-excuts sont griss.

  • 285

    Figure 10.26. Rsultats de build utilisant un filtre de combinaison

    Une autre raison d'utiliser un filtre de build est qu'il y a simplement trop de combinaisons valides pours'excuter dans un temps raisonnable. Dans ce cas, la meilleure solution pourrait tre d'augmenter lacapacit de votre serveur de build. La deuxime meilleure solution, d'un autre ct, serait d'excuteruniquement un sous-ensemble des combinaisons, ventuellement excutant l'ensemble complet decombinaison pendant la nuit. Vous pouvez faire cela en utilisant la variable spciale index. Si vousincluez l'expression (index%2 == 0), par exemple, cela assurera que seulement un build sur deuxest en fait excut.

    Vous pourriez aussi vouloir que certains builds s'excutent avant les autres, comme tests de cohrence.Par exemple, vous pouvez vouloir excuter la configuration par dfaut (et, thoriquement, la plus fiable)pour votre application en premier, avant de continuer avec des combinaisons plus exotiques. Pour fairecela, vous pouvez utiliser l'option Execute touchstone builds first. Ici, vous entrez une valeur de filtre(comme celle montre ci-dessus) pour dfinir le ou les premiers builds excuter. Vous pouvez aussispcifier si le build devrait continuer seulement si ces builds sont russis, ou mme s'ils chouent.Une fois que ces builds se sont termins comme prvu, Jenkins procdera au lancement des autrescombinaisons.

    10.5. Gnrer vos tches de build MavenautomatiquementRdig par Evgeny Goldin

    Comme mentionn dans la section prcdente, le nombre de tches de build que votre serveur Jenkinshberge peut varier. Lorsque ce nombre grossira, il deviendra plus difficile non seulement de lesvoir dans le tableau de bord Jenkins, mais aussi de les configurer. Imaginez ce que ncessiterait la

  • 286

    configuration de 20 50 tches une par une ! De plus, plusieurs de ces tches pourraient avoir en commundes lments de configuration, comme des goals Maven ou des paramtres de configuration mmoire,ce qui rsulte en une configuration duplique et un surplus de maintenance.

    Par exemple, si vous dcidez d'excuter mvn clean install au lieu de mvn clean deploy pourvos tches de release et de passer des mthodes de dploiement alternatives, comme celles fourniespar le pluginArtifactory 1, vous n'aurez plus d'autre choix que d'ouvrir toutes les tches concernes etde les mettre jour manuellement.

    Sinon, vous pourriez tirer parti du fait que Jenkins est un outil simple et direct qui garde trace de toutesses dfinitions sur le disque dans des fichiers bruts. En effet, vous pouvez mettre jour les fichiersconfig.xml de vos tches directement dans le rpertoire .jenkins/jobs o ils sont conservs. Bienque cette approche fonctionnerait, elle est loin d'tre idale parce qu'elle implique un nombre assezimportant de slections manuelles et de remplacements dlicats dans des fichiers XML Jenkins.

    Il y a une troisime faon d'atteindre le nirvana des mises jour massives de tches : gnrer vos fichiersde configuration automatiquement en utilisant une sorte de fichier de dfinition. Le Maven JenkinsPlugin2 fait exactement cela : gnrer les fichiers config.xml pour toutes les tches en utilisant desdfinitions standards conserves dans un unique fichier pom.xml.

    10.5.1. Configurer une tche

    Quand vous configurez une tche avec le Maven Jenkins Plugin, vous pouvez dfinir tous les lmentshabituels de configuration, comme les goals Maven, l'emplacement du POM, les URL de dpts, lesadresses e-mail, le nombre de jours pendant lesquels conserver les logs, et ainsi de suite. Le plugin essaiede vous rapprocher au plus prs de la configuration classique d'une tche dans Jenkins.

    Jetons un oeil la tche de build de Google Guice3 :

    google-guice-trunk Building Google Guice trunk. Project Page code.google.com/p/google-guice false false jdk1.6.0

    1 http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin2 http://evgeny-goldin.com/wiki/Maven-jenkins-plugin3 http://code.google.com/p/google-guice/

    http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Pluginhttp://evgeny-goldin.com/wiki/Maven-jenkins-pluginhttp://evgeny-goldin.com/wiki/Maven-jenkins-pluginhttp://code.google.com/p/google-guice/http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Pluginhttp://evgeny-goldin.com/wiki/Maven-jenkins-pluginhttp://code.google.com/p/google-guice/

  • 287

    apache-maven-3 -Xmx256m -XX:MaxPermSize=128m 5 false -e clean install timer 0 0 * * * http://google-guice.googlecode.com/svn/trunk/ jenkins@evgeny-goldin.org

    Cette tche utilise un certain nombre de configurations standards comme , et . Le code est rcupr partir d'un dpt Subversion (dfini dans l'lment), et un cron qui excute la tche pendant la nuit 00:00. Les notificationsEmail sont envoyes aux personnes spcifies avec l'lment . Cette configuration ajoute aussiun lien vers la page du projet dans le tableau de description gnr automatiquement pour chaque tche.

    Cette tche gnre est affiche dans votre serveur Jenkins comme illustr dans Figure 10.27, Unetche gnre avec le Maven Jenkins plugin.

    Figure 10.27. Une tche gnre avec le Maven Jenkins plugin

    Voici une autre tche ralisant la build de la branche master du projet Jenkins hberg chez GitHub :

    jenkins-master jdk1.6.0 5

  • 288

    apache-maven-3 timer 0 1 * * * git git://github.com/jenkinsci/jenkins.git jenkins@evgeny-goldin.org false

    Elle gnre la tche montre dans Figure 10.28, Tche gnre jenkins-master.

    Figure 10.28. Tche gnre jenkins-master

    La documentation4 du plugin fournit une rfrence dtaille de tous les paramtres qui peuvent treconfigurs.

    10.5.2. Rutiliser une configuration de tche par hritage

    tre capable de gnrer des tches Jenkins jobs en utilisant une configuration centralise, comme unPOM Maven, rsout le problme de la cration et de la mise jour de plusieurs tches la fois. Tout ceque vous avez faire est de modifier les dfinitions de job, relancer le plugin et charger les dfinitionsmises jour avec Administrer Jenkins#Recharger la configuration partir du disque. Cette approche aaussi l'avantage de rendre facile le stockage de vos configurations de tche dans un systme de gestion deversions, ce qui rend par la mme plus facile le suivi des changements faits aux configurations de build.

    Cela ne rsout toutefois pas le problme consistant maintenir des tches qui partagent un certainnombre de proprits identiques, comme les goals Maven, les destinataires email ou l'URL du dpt

    4 http://evgeny-goldin.com/wiki/Maven-jenkins-plugin#.3Cjob.3E

    http://evgeny-goldin.com/wiki/Maven-jenkins-plugin#.3Cjob.3Ehttp://evgeny-goldin.com/wiki/Maven-jenkins-plugin#.3Cjob.3E

  • 289

    de code. Pour cela, le Maven Jenkins Plugin fournit de l'hritage de tches, dmontr dans l'exemplesuivant:

    google-guice-inheritance-base true jdk1.6.0 apache-maven-3 5 true -B -e -U clean install jenkins@evgeny-goldin.org google-guice-inheritance-trunk google-guice-inheritance-base http://google-guice.googlecode.com/svn/trunk/ google-guice-inheritance-3.0-rc3 google-guice-inheritance-base http://google-guice.googlecode.com/svn/tags/3.0-rc3/ google-guice-inheritance-2.0-maven google-guice-inheritance-base apache-maven-2 http://google-guice.googlecode.com/svn/branches/2.0-maven/

    Dans cette configuration, google-guice-inheritance-base est une tche parent abstraite contenant toutesles proprits communes : le nom du JDK, le nom de Maven, le nombre de jours de conservation des logs,la politique de mise jour SVN, les goals Maven et les destinataires email. Les trois tches suivantes sonttrs courtes, spcifiant simplement qu'elles tendent une tche et ajoutent les configurationsmanquantes (URLs de dpt dans ce cas). Une fois gnres, elles hritent de toutes les proprits dela tche parente automatiquement.

    Toute proprit hrite peut tre rdfinie, comme dmontr dans la tche google-guice-inheritance-2.0-maven o Maven 2 est utilis la place de Maven 3. Si vous voulez "annuler" une proprit hrite,vous devrez la redfinir avec une valeur vide.

  • 290

    L'hritage de tches est un concept trs puissant qui permet aux tches de former des groupeshirarchiques de n'importe quel type et dans n'importe quel but. Vous pouvez grouper vos tches d'IC,noctures ou de release de cette faon, en centralisant les dclencheurs d'excution partags, les goalsMaven ou les destinataires email dans des tches parentes. Cette approche emprunt au monde orientobject permet de rsoudre le problme de maintenance de tches partageant un certain nombre deproprits identiques.

    10.5.3. Le support des plugins

    En plus de configurer une tche et de rutiliser ses dfinitions, vous pouvez bnficier d'un supportspcial pour un certain nombre de plugins Jenkins. l'heure actuelle, une utilisation simplifie desplugins Parameterized Trigger et Artifactory est fournie, un support pour d'autres plugins populaires estprvu dans de futures versions.

    Ci-dessous se trouve un exemple d'invocation de tches avec le plugin Parameterized Trigger. Utilisercette option suppose que vous avez dj ce plugin install :

    google-guice-inheritance-trunk ... google-guice-inheritance-3.0-rc3, google-guice-inheritance-2.0-maven

    google-guice-inheritance-3.0-rc3 ...

    google-guice-inheritance-2.0-maven ...

    L'lment vous permet d'invoquer d'autres tches chaque fois que la tche courante se terminecorrectement. Vous pouvez crer un pipeline de tches de cette faon, vous assurant que chaque tchedu pipeline invoque la suivante. Notez que s'il y a plus d'un excuteur Jenkins disponible au momentde l'invocation, les tches spcifies dmarreront en parallle. Pour une excution en srie, vous devrezconnecter chaque tche amont une tche aval avec .

    Par dfaut, l'invocation ne se fait que quand la tche courante est stable. Ceci peut tre modifi, commemontr dans les exemples suivants :

  • 291

    jobA, jobB, jobC true

    jobA, jobB, jobC true

    jobA, jobB, jobC false false true

    La premire invocation dans l'exemple ci-dessus invoque toujours les tches avals. Ceci peut tre utilispour un pipeline de tches qui devraient toujours tre excutes mme si certaines, ou leurs tests,chouent.

    La seconde invocation dans l'exemple ci-dessus invoque les tches avals mme si une tche amont estinstable : l'invocation prend place quels que soient les rsultats des tests. Cela peut tre utilis pour unpipeline de tches moins sensibles aux tests et leurs checs.

    La troisime invocation ci-dessus invoque les tches avals seulement quand une tche amont chouemais pas lorsqu'elle est stable ou instable. Cette configuration peut vous tre utile si une tche en checdoit effectuer des actions additionnelles autres que les notifications email tradtionnelles.

    Artifactory5 est un dpt de binaires usage gnral qui peut tre utilis comme gestionnaire de dptMaven. Le plugin Jenkins Artifactory6, montr dans Figure 10.29, Configuration du plugin Jenkinspour Artifactory, fournit un certain nombre d'avantages pour les tches de build Jenkins. Nous avonsdj pass en revue quelques-unes d'entre elles dans Section 5.9.4, Dployer vers un gestionnairede dpt dentreprise, notamment la capacit dployer des artefacts l'achvement de la tche oud'envoyer avec des informations de l'environnement de build avec les artefacts pour une meilleuretraabilit.

    5 http://jfrog.org6 http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

    http://jfrog.orghttp://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Pluginhttp://jfrog.orghttp://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

  • 292

    Figure 10.29. Configuration du plugin Jenkins pour Artifactory

    Vous pouvez aussi utiliser le plugin Jenkins Artifactory conjointement au Maven Jenkins Plugin pourdployer dans Artifactory, comme montr dans l'exemple suivant :

    ... http://artifactory-server/ true true true

    Les informations d'identit pour le dploiement sont spcifies dans la configuration de Jenkins dansl'cran Administrer Jenkins#Configurer le systme. Elles peuvent aussi tre spcifies pour chaque tcheJenkins. Les dpts Maven par dfaut sont libs-releases-local et libs-snapshots-local.Vous trouverez plus de dtails dans la documentation du plugin l'adresse http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin.

    http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Pluginhttp://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

  • 293

    10.5.4. Les tches Freestyle

    En supplment des tches Maven, le Maven Jenkins Plugin vous permet de configurer des tchesfreestyle Jenkins. Un exemple est montr ici :

    free-style free git git://github.com/evgeny-goldin/maven-plugins-test.git apache-maven-3 -Xmx128m -XX:MaxPermSize=128m -ea plugins-version = 0.2.2 pwd; ls -al; du -hs .

    Les tches Freestyle vous permettent d'excuter un shell ou une commande batch, excuter Maven ouAnt, et invoquer d'autres tches. Elles fournissent un environnement d'excution bien pratique pour lesscripts systmes ou tout autre type d'activit qui n'est pas directement implmente dans Jenkins ou l'undes ses plugins. En utilisant cette approche, vous pouvez gnrer des fichiers de configuration de tchede build Freestyle de faon similaire l'approche que nous avons vue pour les tches de build Maven,ce qui peut aider rendre votre environnement de construction plus cohrent et maintenable.

    10.6. Coordonner vos buildsDclencher des tches avals est assez facile. Toutefois, quand on met en place des configurations detches de build plus importantes et plus compliques, on aimerait parfois tre capable de lancer desexcutions simultanes, ou ventuellement attendre la fin de certaines tches de build afin de continuer.Dans cette section, nous allons regarder les techniques et les plugins qui peuvent nous aider faire cela.

    10.6.1. Les builds parallles dans Jenkins

    Jenkins possde un support intgr pour les build parallles quand une tche dmarre, Jenkins va luiassigner le premier noeud de build disponible. Vous pouvez donc avoir potentiellement autant de buildsparallles en excution que vous avez de noeuds disponibles.

    Si vous avez besoin d'excuter une lgre variations de la mme tche de build en parallle, lestches de build multiconfiguration (voir Section 10.4, Tches de build multiconfiguration) sont uneexcellente option. Ceci peut s'avrer trs pratique comme moyen d'accler votre processus de build.Une application typique des tches de build multiconfiguration dans ce contexte est d'excuter des testsd'intgration en parallle. Vous pourriez dfinir des profils Maven par exemple, ou configurer votre

  • 294

    build pour utiliser des paramtres de ligne de commande pour dcider quels tests excuter. Une foisque vous avez configur vos scripts de build de cette faon, il est ais de configurer une tche de buildmulticonfiguration pour excuter un sous ensemble de vos tests d'intgration en parallle.

    Vous pouvez aussi faire que Jenkins dclenche plusieurs tches avals en parallle, en les listantsimplement dans le champ "Construire d'autres projets" (voir Figure 10.30, Dclencher plusieurs autresbuilds aprs une tche de build). Les tches de build suivantes seront excutes en parallle autant quepossible. Toutefois, comme nous le verrons plus loin, cela peut ne pas toujours tre exactement ce dontvous avez besoin.

    Figure 10.30. Dclencher plusieurs autres builds aprs une tche de build

    10.6.2. Graphes de dpendance

    Avant d'tudier les points les plus fins des buils parallles, il est utile de pouvoir visualiser les relationsentre vos tches de build. Le plugin Dependency Graph View analyse vos tches de build et affiche ungraphe dcrivant les connexions amont et aval entre vos tches. Ce plugin utilise graphviz7, que vousaurez besoin d'installer sur votre serveur si vous ne l'avez pas dj.

    Ce plugin ajoute une icne Graphe de dpendance dans le menu principal, qui affiche un graphe montrantles relations entre toutes les tches de build dans votre projet (au niveau tableau de bord), ou toutes lestches de build lies la tche de build courante (quand vous tes l'intrieur d'un projet particulier [voirFigure 10.31, Un graphe de dpendance de tche de build]). De plus, si vous cliquez sur une tche debuild dans le graphe, Jenkins vous emmnera directement vers la page projet de cette tche de build.

    7 http://www.graphviz.org

    http://www.graphviz.orghttp://www.graphviz.org

  • 295

    Figure 10.31. Un graphe de dpendance de tche de build

    10.6.3. Jonctions

    Lors de la configuration de pipelines de builds plus compliqus, vous rencontrerez frquemment dessituations o une tche de build ne peut dmarrer tant qu'un certain nombre d'autres tches de build nesont pas termines, mais que ces tches amont ne ncessitent pas d'tre excutes squentiellement. Parexemple, dans Figure 10.31, Un graphe de dpendance de tche de build, imaginez que la tche debuild phoenix-deploy-to-uat ait en fait besoin que trois tches russissent avant qu'elle puisse treexcute : phoenix-compatibility-tests, phoenix-load-tests, et phoenix-performance-tests.

    On peut configurer cela en utilisant le plugin Joins, que vous devez installer de la faon habituellevia le centre de mise jour. Une fois qu'il est install, vous configurez une jonction dans la tche debuild qui initie le processus de jonction (ici, ce serait phoenix-web-tests). Dans notre exemple, nousdevons modifier la tche de build phoenix-web-tests afin qu'elle dclenche en premier phoenix-compatibility-tests, phoenix-load-tests, et phoenix-performance-tests, et ensuite, sices trois russissent, la tche de build phoenix-deploy-to-uat.

    Nous le faisons en configurant simplement le champ dclencheur de jonction avec le nom de la tche debuild phoenix-deploy-to-uat (voir Figure 10.32, Configurer une jonction dans la tche de buildphoenix-web-tests). Le champ Construire d'autres projets n'est pas modifi, et liste encore les tchesde build dclencher immdiatement aprs la tche courante. Le champ dclencheur de jonction contientles tches de build lancer une fois que toutes les tches avals immdiates se sont termines.

  • 296

    Figure 10.32. Configurer une jonction dans la tche de build phoenix-web-tests

    Rsultat, vous n'avez plus besoin du dclencheur de build original pour la tche de build final, puisquec'est prsent redondant.

    Ce nouveau droulement apparat bien dans les graphes de dpendance illustrs dans Figure 10.33, Ungraphe de dpendance de tche de build plus compliqu.

    Figure 10.33. Un graphe de dpendance de tche de build plus compliqu

  • 297

    10.6.4. Plugin Locks and Latches

    Dans d'autres situations, vous pourriez tre capable de lancer une srie de builds en parallle jusqu' uncertain point, mais certaines tches de build pourraient ne pas pouvoir tre lances en parallle parcequ'elles accdent des ressources en concurrence. Bien sr, des tches de build bien conues devraients'efforcer d'tre aussi indpendantes que possible, mais cela peut parfois tre difficile. Par exemple,diffrentes tches de build peuvent accder la mme base de donnes de test, ou des fichiers sur ledisque dur, et faire cela simultanment pourrait potentiellement compromettre le rsultat des tests. Unetche de build de performance pourrait avoir besoin d'un accs exclusif au serveur de test, afin d'avoirdes rsultats cohrents chaque fois.

    Le plugin Locks and Latches vous permet d'une certaine faon de contourner ce problme. Ce pluginpermet de configuration des verrous (ndt: locks) pour certaines ressources, de faon similaire auxverrous en programmation multithreade. Supposez, par exemple, dans les tches de build dpeintesdans Figure 10.33, Un graphe de dpendance de tche de build plus compliqu, que les tests de chargeet les tests de performance soient excuts sur un serveur ddi, mais qu'une seule tche de build puissetre excute la fois sur ce serveur. Imaginez de plus que les tests de performance pour les autresprojets soient aussi excuts sur ce serveur.

    Pour viter la contention sur le serveur de performance, vous pourriez utiliser le plugin Locks andLatches pour mettre en place un accs par rservation de "verrou" ce serveur pour une tche uninstant donn. Premirement, dans la page de configuration du systme, vous devez ajouter un nouveauverrou dans la section Verrous (voir Figure 10.34, Ajouter un nouveau verrou). Ce verrou sera ensuitedisponible toutes les tches de build sur le serveur.

    Figure 10.34. Ajouter un nouveau verrou

    Ensuite, vous devez configurer chaque tche de build qui utilisera la ressource en contention. Dans lasection Environnement de build, vous trouverez un champ Verrous. Cochez la case et slectionnez leverrous que vous venez juste de crer (voir Figure 10.35, Configurer une tche de build pour utiliserun verrou). Une fois que avez fait cela pour chacune des tches de build qui ont besoin d'accder laressource en question, seule une des tches de build pourra s'excuter un instant donn.

  • 298

    Figure 10.35. Configurer une tche de build pour utiliser un verrou

    10.7. Pipelines de build et promotionsL'intgration continue ne consiste pas simplement construire et tester automatiquement un logiciel,elle peut aussi apporter une aide dans un contexte plus large de dvloppement de produit logiciel etde cycle de vie de release. Dans de nombreuses organisation, la vie d'une version particulire d'uneapplication ou d'un produit dmarre en dveloppement. Lorsqu'on l'estime prte, elle est passe l'quipe d'assurance qualit pour la tester. S'ils considrent la version acceptable, ils la transmettent des utilisateurs slectionns pour davantage de tests dans un environnement de tests d'acceptation. Siles utilisateurs sont contents, elle est envoye en production. Bien sr, il y a presque autant de variationsde cela qu'il y a d'quipes de dveloppement, mais un principe commun est que des versions spcifiquessont slectionnes, selon certains critres de qualit, afin d'tre promues" l'tape suivante du cyclede vie. Ceci est connu sous l'appellation promotion de build, et le processus plus global est connu sousle nom de pipeline de build. Dans cette section, nous regarderons comment implmenter des pipelinesde build en utilisant Jenkins.

    10.7.1. Gestion des releases Maven avec le plugin M2Release

    Une part importante de tout pipeline de build est d'avoir une stratgie de release bien dfinie. Ceciimplique, entre autres choses, de ddier comment et quand lancer une nouvelle release, et commentl'identifier avec un libell unique ou numro de version. Si vous travaillez avec des projets Maven,utiliser le plugin Maven Release pour grer les numros de versions est une pratique hautementrecommande.

    Les projets Maven utilisent des numros de version bien dfinis et bien structurs. Un numro deversion typique est compos de trois digits (e.g., 1.0.1). Les dveloppeurs travaillent sur des versionsSNAPSHOT (e.g.,1.0.1-SNAPSHOT), qui, comme son nom l'indique, n'est pas conu pour tredfinitif. Les releases dfinitives (e.g., 1.0.1) sont construites une seule fois et dployes dans le dptlocal d'entreprise (ou le dpt central Maven pour les bibliothques opensource), o elles peuvent leurtour tre utilises par d'autres projets. Les numros de version utiliss dans des artefacts Maven sontune part critique du systme de gestion de dpendances Maven, et il est fortement conseill de respecterles conventions Maven.

    Le plugin Maven Release aide automatiser le processus de mise jour des numros de version Mavende vos projets. En rsum, cela vrifie, construit et teste votre application, monte les numros de version,

  • 299

    met jour votre systme de contrle de versions avec les tags appropris, et dploie les versions derelease de vos artefacts dans votre dpt Maven. C'est une tche fastidieuse faire manuellement, leplugin Maven Release est donc un excellent moyen d'automatiser les choses.

    Toutefois, le plugin Maven Release peut aussi tre capricieux. Des fichiers locaux non-archivs oumodifis peuvent faire chouer le processus, par exemple. Le processus est aussi consommateur entemps et consomme intensivement le CPU, plus spcialement pour les gros projets : cela construitet excute entirement l'ensemble de tests unitaires et d'intgration plusieurs fois, rcupre une copiepropre du code depuis le dpt, et envoie plusieurs artefacts au dpt d'entreprise. Concrtement, cen'est pas le genre de chose que vous voulez excuter sur une machine de dveloppeur.

    Il est donc de bon ton d'excuter ce processus sur votre serveur de build.

    Une faon de faire cela est de configurer une tche manuelle de build spciale invoquant le plugin MavenRelease. Toutefois, le plugin M2Release propose une approche plus simple. En utilisant ce plugin, vouspouvez ajouter la possibilit de construire une version de release Maven une tche existante. Vouspouvez ainsi viter de dupliquer des tches de builds inutilement, facilitant par la mme la maintenancedu serveur.

    Une fois ce plugin install, vous pouvez configurer toute tche de build pour qu'elle propose unetape manuelle de release Maven. Ceci s'effectue en cochant la case Maven release build dans lasection Environnement de Build (voir Figure 10.36, Configurer une release Maven en utilisant leplugin M2Release). Ici, vous dfinissez les goals que vous voulez excuter pour le build (typiquementrelease:prepare release:perform).

    Figure 10.36. Configurer une release Maven en utilisant le plugin M2Release

    Lorsque ceci est configur, vous pouvez dclencher manuellement une release Maven en utilisant unenouvelle option de menu appele Perform Maven Release (voir Figure 10.37, L'option de menuPerform Maven Release).

  • 300

    Figure 10.37. L'option de menu Perform Maven Release

    Cela dclenchera une tche de build spciale utilisant les goals que vous avez fournis dans laconfiguration du plugin (voir Figure 10.38, Effectuer une release Maven dans Jenkins). Jenkins vousoffre le choix d'utiliser soit les numros de version par dfaut fournis par Maven (par exemple, la version1.0.1-SNAPSHOT sera livre avec la version 1.0.1, et le numro de version en dveloppement serapositionne 1.0.2-SNAPSHOT), soit de fournir vos propres numros de version personnaliss. Si, parexemple, vous voulez livrer une version majeure vous pourriez dcider de spcifier manuellement 1.1.0comme numro de version et 1.1.1-SNAPSHOT comme prochain numro de version de dveloppement.

    Si vous avez un projet multimodule Maven, vous pouvez choisir une configuration de numro de versionunique pour tous les modules, ou de fournir une mise jour de numro de version diffrente pour chaquemodule. Notez que ce n'est gnralement pas une pratique recommande que de fournir des numros deversion diffrents pour diffrents modules dans un projet multimodule.

  • 301

    Figure 10.38. Effectuer une release Maven dans Jenkins

    En fonction de votre configuration SCM, vous pourriez aussi avoir besoin de fournir un nom d'utilisateuret un mot de passe valide pour permettre Maven de crer les tags dans votre dpt de code source.

    L'dition professionnelle du Dpt d'Entreprise Nexus fournit une fonctionnalit appele StagingRepositories, qui permet de dployer des artefacts dans un espace spcial de staging afin de fairedavantage de tests avant de les livrer officiellement. Si vous utilisez cette fonctionnalit, vous devezparamtrer plus finement votre configuration de serveur de build pour de meilleurs rsultats.

    Nexus Professional travaille en crant un nouvel espace de staging pour chaque adresse IP unique,utilisateur de dploiement et User-Agent HTTP. Une machine de build Jenkins donne aura toujours lamme adresse IP et le mme utilisateur. Toutefois, vous voudrez typiquement avoir un espace de stagingspar pour chaque build. L'astuce est alors de configurer Maven pour qu'il utilise une chane de User-Agent HTTP unique pour le processus de dploiement. Vous pouvez le faire en configurant le fichiersettings.xml sur votre serveur de build afin qu'il contienne quelque chose dans le genre des lignessuivantes (l'ID doit correspondre l'ID du dpt de release de la section deployment de votre projet) :

    nexus my_login my_password User-Agent Maven m2Release (java:25.66-b01 ${env.BUILD_TAG }

    10.7.2. Copier des artefacts

    Pendant un processus de build impliquant plusieurs tches de build, comme celle illustre dansFigure 10.33, Un graphe de dpendance de tche de build plus compliqu, il peut parfois tre utile

  • 302

    de rutiliser des artefacts produits par un build dans une tche de build ultrieure. Par exemple, vouspourriez vouloir excuter une srie de tests web en parallles sur des machines spares, en utilisant desserveurs d'application locaux pour amliorer les performances. Dans ce cas, il est normal de rcuprerle binaire exact qui a t produit dans le build prcdent, plutt que de le reconstruire chaque fois ou, sivous utilisez Maven, de reposer sur un build SNAPSHOT dploy dans le dpt d'entreprise. En effet,ces deux approches pourraient vous faire courir le risque de rsultats de build incohrent : si vous utilisezune SNAPSHOT d'un dpt d'entreprise, par exemple, vous utiliserez le dernier build SNAPSHOT, quipourrait ne pas ncessairement tre celui construit dans la tche de build amont.

    Le plugin Copy Artifact vous permet de copier des artefacts d'un build amont et de les rutiliser dansvotre build courant. Une fois que vous avez install ce plugin et redmarr Jenkins, vous pourrez ajouterune nouvelle tape de build appele Copier des artefacts d'un autre projet vos tches de build freestyle(voir Figure 10.39, Ajouter une tape de build Copier des artefacts d'un autre projet).

    Figure 10.39. Ajouter une tape de build Copier des artefacts d'un autre projet

    Cette nouvelle tape de build vous permet de copier des artefacts d'un projet dans l'espace de travail duprojet courant. Vous pouvez spcifier n'importe quel autre projet, bien que ce sera typiquement l'unedes tches de build amont. Et bien sr vous pouvez spcifier, avec une grande flexibilit et prcision,les artefacts exacts que vous souhaitez copier.

    Vous devez spcifier o trouver les fichiers que vous voulez dans l'espace de travail de l'autre tche debuild, et o Jenkins doit les mettre dans votre espace de travail courant. Ceci peut tre une expressionrgulire flexible (comme **/*.war, pour tout fichier WAR produit par la tche de build), ou celapeut tre beaucoup plus prcis (comme gameoflife-web/target/gameoflife.war). Notez quepar dfaut, Jenkins copiera la structure de rpertoire en mme temps que le fichier que vous rcuprez,ainsi si le fichier WAR se trouve dans dans le rpertoire target du module gameoflife-web, Jenkinsle placera dans le rpertoire gameoflife-web/target de votre espace de travail courant. Si cela nevous convient pas, vous pouvez cocher l'option Aplatir l'arborescence pour dire Jenkins de mettretous les artefacts la racine du rpertoire que vous spcifiez (ou, par dfaut, dans l'espace de travailde votre projet).

  • 303

    Souvent, vous voudrez simplement rcuprer des artefacts depuis le build russi le plus rcent. Toutefois,vous voudrez parfois plus de prcision. Le champ "Quel build vous permet de spcifier o chercher desartefacts d'un bon nombre d'autres faons, incluant le dernier build sauv (builds qui ont t marqus "toujours conserver"), le dernier build russi, ou mme un numro spcifique de build.

    Si vous avez install le plugin Build Promotion (voir Section 10.7.3, Promotions de build), vouspouvez aussi slectionner le dernier artefact promu dans un processus de promotion en particulier. Pourfaire cela, choisissez "Spcifier par permalien", puis choisissez le processus de promotion de buildappropri. C'est un excellent moyen de s'assurer d'un pipeline de build fiable et cohrent. Par exemple,vous pouvez configurer un processus de promotion de build pour dclencher un build qui copie un fichierWAR gnr depuis le dernier build promu et le dploie sur un serveur particulier. Ceci vous assure dedployer le bon fichier binaire, mme si d'autres builds se sont produits depuis.

    Si vous copiez des artefacts d'une tche de build multimodule Maven, Jenkins copiera, par dfaut, tousles artefacts de ce build. Toutefois vous tes souvent intress uniquement par un artefact spcifique(comme l'artefact WAR pour une application web, par exemple).

    Ce plugin est particulirement utile quand vous avez besoin d'excuter des tests fonctionnels ou deperformance sur votre application web. Il est souvent stratgiquement utile de placer ces tests dans unprojet spar, et non comme une partie de votre processus de build principal. Cela facilite l'excutionde ces tests sur diffrents serveurs ou d'excuter le sous-ensemble des tests en parallle, tout en utilisantle mme artefact binaire pour dployer et tester.

    Par exemple, imaginez que vous avez une tche de build par dfaut appele gameoflife qui gnre unfichier WAR, et que vous vouliez dployer ce WAR sur un serveur d'application local et excuter unesrie de tests fonctionnels. De plus, vous voulez pouvoir faire cela en parallle sur plusieurs machinesdistribues.

    Une faon de faire cela serait de crer un projet Maven ddi pour lancer les tests fonctionnels sur unserveur arbitraire. Ensuite, vous mettriez en place une tche de build pour excuter ces tests fonctionnels.La tche de build utiliserait le plugin Copy Artifact pour rcuprer le dernier fichier WAR (ou mme ledernier fichier WAR promu, pour plus de prcision), et le dploierait sur une instance Tomcat locale enutilisant Cargo. Cette tche de build pourrait ensuite tre configure en tant que tche de build (matrix)configurable, et excute en parallle sur plusieurs machines, ventuellement avec des paramtres deconfiguration supplmentaires pour filtrer les excutions de test de chaque build. Chaque excutionde build utiliserait ensuite sa propre copie du fichier WAR original. Un exemple d'une configurationcomme celle-ci est illustr dans Figure 10.40, Excuter des tests web sur un fichier WAR copi.

  • 304

    Figure 10.40. Excuter des tests web sur un fichier WAR copi

    Le plugin Copy Artifact n'est pas restreint la rcupration de fichiers depuis des tches de buildconventionnelles. Vous pouvez aussi copier des artefacts partir de tches de build multiconfiguration(voir Section 10.4, Tches de build multiconfiguration). Les artefacts de chaque configurationexcute seront copis dans l'espace de travail courant, chacun dans son propre rpertoire. Jenkinsconstruira une structure de rpertoire en se basant sur les axes utiliss dans le build multiconfiguration.Par exemple, imaginez que nous ayons besoin de produire une version hautement optimise de notreproduit pour un certain nombre de bases de donnes et de serveurs d'application cibles. Nous pourrionsfaire cela avec une tche de build multiconfiguration comme celle illustre dans Figure 10.41, Copier partir d'un build multiconfiguration.

  • 305

    Figure 10.41. Copier partir d'un build multiconfiguration

    Le plugin Copy Artifacts peut dupliquer n'importe lequel ou mme tous les artefacts produits par cettetche de build. Si vous spcifiez un build multiconfiguration comme source de vos artefacts, le plugincopiera les artefacts de toutes les configurations dans l'espace de travail de la tche de build cible,en utilisant une structure de rpertoire imbrique base sur les axes du build multiconfiguration. Parexemple, si vous dfinissez le rpertoire cible comme multi-config-artifacts, Jenkins copierales artefacts dans un certain nombre de sous-rpertoires dans le rpertoire cible, chacun avec un nomcorrespondant un ensemble particulier de paramtres. Ainsi, en utilisant la tche de build illustre dansFigure 10.41, Copier partir d'un build multiconfiguration, le fichier JAR personnalis pour Tomcatet MySql serait copi dans le rpertoire $WORKSPACE/multi-config-artifacts/APP_SERVER/tomcat/DATABASE/mysql.

    10.7.3. Promotions de build

    Dans le monde de l'Intgration Continue, tous les builds crs ne sont pas gaux. Par exemple, vouspourriez vouloir dployer la dernire version de votre application web sur un serveur de test, maisseulement aprs avoir russi un certain nombre de tests fonctionnels automatiss ou de charge. Ou vouspourriez vouloir que les testeurs puissent marquer certains builds comme tant prts pour un dploiementpour les tests d'acceptation utilisateur, une fois qu'ils ont termin leurs propres tests.

    Le plugin Promoted Builds vous permet d'identifier des builds spcifiques ayant atteint des critresadditionnels de qualit, et de dclencher des actions sur ces builds. Par exemple, vous pourriez construireune application web dans une tche de build, excuter une srie de tests automatiss dans un buildultrieur, puis dployer le fichier WAR gnr sur le serveur de tests d'acceptation utilisateur poureffectuer davantage de tests.

    Voyons comment cela fonctionne en pratique. Dans le projet illustr ci-dessus, une tche de buildpar dfaut (phoenix-default) excute des tests unitaires et d'intgration, puis produit un fichierWAR. Ce fichier WAR est ensuite rutilis pour des tests plus tendus (dans la tche de buildphoenix-integration-tests) et ensuite pour une srie de tests web automatiss (dans la tche

  • 306

    de build phoenix-web-test). Si le build russit les tests web automatiss, nous aimerions dployerl'application dans un environnement de tests fonctionnels o elle pourrait tre teste par des testeurshumains. Le dploiement dans cet environnement est effectu avec la tche de build phoenix-test-deploy. Une fois que les testeurs ont valid la version, elle peut tre promue vers l'environnement detests d'acceptation utilisateur, et enfin en production. La stratgie complte de promotion est illustredans Figure 10.42, Tches de build dans le processus de promotion.

    Figure 10.42. Tches de build dans le processus de promotion

    Cette stratgie est facile implmenter en utiliser le plugin Promoted Builds. Une fois que vousl'avez install de la faon habituelle, vous trouverez une nouvelle case "Promouvoir builds quand"dans la page de configuration de la tche. Cette option est utilis pour configurer les processus depromotion de build. Vous dfinissez un ou plusieurs processus de promotion de build dans la tche debuild initiale du processus (phoenix-default dans cet exemple), comme illustr dans Figure 10.43,Configurer un processus de promotion de build. Une tche de build peut tre le point de dpart deplusieurs processus de promotion de build, certains automatiss, certains manuels. Dans Figure 10.43,Configurer un processus de promotion de build, par exemple, il y a un processus de promotion de buildautomatis appel promote-to-test et un manuel appel promote-to-uat. Les processus de promotion debuild automatiss sont dclenchs par les rsultats de tches de build avals. Les processus de promotion

  • 307

    manuels (indiqus en cochant la case Seulement si approuv manuellement) peuvent uniquement tredclenchs par une intervention utilisateur.

    Figure 10.43. Configurer un processus de promotion de build

    Regardons prsent comment configurer le processus de build automatis promote-to-test.

    Vous devez commencer par dfinir comment le processus de promotion de build sera dclench. Lapromotion de build peut tre soit automatique, base sur le rsultat d'une tche de build aval, soit activemanuellement par un utilisateur. Dans Figure 10.43, Configurer un processus de promotion de build,la promotion de build pour cette tche de build sera automatiquement dclenche lorsque les tests webautomatiss (excut par la tche de build phoenix-web-tests) auront russi.

    Vous pouvez aussi faire que certaines tches de build ne puissent tre promues que manuellement,comme illustr dans Figure 10.44, Configurer un processus manuel de promotion de build. Lapromotion de build manuelle est utilise pour les cas o une intervention humaine est requise pourapprouver une promotion de build. Le dploiement dans l'environnement de test d'acceptation utilisateurou de production en sont des exemples courants. Autre exemple, lorsque vous voulez suspendretemporairement les promotions de build pour une courte priode, comme l'approche d'une release.

    Les builds manuels, comme leur nom le suggre, ncessite d'tre approuvs manuellement avant depouvoir tre excuts. Si le processus de promotion consiste dclencher une tche de build paramtre,vous pouvez aussi fournir des paramtres que l'approbateur devra entrer lors de l'approbation. Danscertains cas, il peut tre utile de dsigner certains utilisateurs autoriss activer la promotion manuelle.Vous pouvez faire cela en spcifiant une liste d'utilisateurs ou de groupes dans la liste d'approbateurs.

  • 308

    Figure 10.44. Configurer un processus manuel de promotion de build

    Parfois, il est utile de donner un peu de context une personne approuvant une promotion. Quand vousconfigurez un processus de promotion manuel, vous pouvez aussi spcifier d'autres conditions devanttre remplies, en particulier des tches de build avals (ou amonts) qui doivent avoir t construites avecsuccs (voir Figure 10.45, Voir les dtails d'une promotion de build). Celles-ci apparatront dans lesMet Qualifications (pour les tches de build en succs) et dans les Unmet Qualifications (pour lestches de builds qui ont chou ou n'ont pas encore t excutes).

  • 309

    Figure 10.45. Voir les dtails d'une promotion de build

    Vous devez ensuite dire Jenkins ce qu'il doit faire lorsque le build est promu. Cela se fait en ajoutant desactions, tout comme dans une tche de build freestyle. Ceci rend les promotions de build extrmementflexible, parce que vous pouvez ajouter pratiquement n'importe quelle action disponible dans une tchede build freestyle normale, incluant n'importe quelles tapes additionnelles offertes par le pluginsinstalls sur votre instance Jenkins. Les actions courantes incluent l'invocation de script Maven ou Ant,le dploiement d'artefacts dans un dpt Maven, ou le dclenchement d'un autre build.

    Une chose importante garder l'esprit ici est que vous ne pouvez pas vous reposer sur des fichiers del'espace de travail lors de la promotion de votre build. En effet, au moment o vous promouvez votrebuild, automatiquement ou manuellement, d'autres tches de build pourraient avoir supprim ou rcritles fichiers que vous avez besoin d'utiliser. Pour cette raison, il est imprudent, par exemple, de dployerun fichier WAR directement partir de l'espace de travail vers un serveur d'application pendant unprocessus de promotion de build. Une solution plus robuste consiste dclencher une tche de buildspare et d'utiliser le plugin Copy Artifacts (voir Section 10.7.2, Copier des artefacts) pour rcuprerprcisment le bon fichier. Dans ce cas, vous copierez des artefacts que vous avez demand Jenkinsde conserver, plutt que de copier directement des fichiers de l'espace de travail.

    Pour que la promotion de build fonctionne correctement, Jenkins doit pouvoir lier prcisment les tchesde build avals celles en amont. La faon la plus prcise de faire cela est d'utiliser les fingerprints. Dans

  • 310

    Jenkins, un fingerprint est le somme de contrle MD5 d'un fichier produit ou utilis dans une tche debuild. En faisant correspondre les fingerprints, Jenkins est capable d'identifier tous les builds utilisantun fichier particulier.

    Dans le contexte de la promotion de build, une stratgie courante est de construire votre application uneseule fois, puis d'excuter des tests sur les fichiers binaires gnrs dans une srie de tches de buildsavals. Cette approche fonctionne bien avec la promotion de build, mais vous devez vous assurer queJenkins crer un fingerprint des fichiers partags ou copis entre tches de build. Dans l'exemple montrdans Figure 10.43, Configurer un processus de promotion de build, notamment, nous avons besoinde faire deux choses (Figure 10.46, Utiliser fingerprints dans le processus de promotion de build).Premirement, nous devons archiver le fichier WAR gnr afin qu'il puisse tre utilis dans le projetaval. Deuximement, nous devons enregistrer un fingerprint des artefacts archivs. Vous faites cela encochant l'option Enregistrer les fingerprints de fichiers pour tracer leur utilisation, et en spcifiant lesfichiers pour lesquels vous voulez crer un fingerprint. Un raccourci utile consiste simplement crerun fingerprint pour tous les fichiers archivs, puisque ce sont les fichiers qui vont typiquement trercuprs et rutiliss par les tches de build avals.

    Figure 10.46. Utiliser fingerprints dans le processus de promotion de build

    C'est tout ce que vous avez besoin de faire pour configurer le processus initial de build. L'tape suivanteconsiste configurer les tests d'intgration excuts dans la tche de build phoenix-integration.Ici, nous utilisons le plugin Copy Artifact pour rcuprer le WAR gnr par la tche de build phoenix-default (voir Figure 10.47, Rcuprer le fichier WAR depuis la tche de build amont). Commecette tche de build est dclenche immdiatement aprs la tche de build phoenix-default, on peutsimplement rcuprer le fichier WAR depuis le dernier build russi.

  • 311

    Figure 10.47. Rcuprer le fichier WAR depuis la tche de build amont

    Cependant, ce n'est pas encore tout fait tout ce que nous devons faire pour les tests d'intgration. Latche de build phoenix-integration est suivie de la tche de build phoenix-web, qui excute lestests web automatiss. Pour s'assurer que le mme fichier WAR est utilis chaque tape du processusde build, nous devons le rcuprer dans la tche de build amont phoenix-integration, et non depuisla tche originale phoenix-default (qui pourrait avoir t excute nouveau dans l'intervalle). Nousavons donc aussi besoin d'archiver le fichier WAR dans la tche de build phoenix-integration (voirFigure 10.48, Archiver le fichier WAR dans la tche aval).

    Figure 10.48. Archiver le fichier WAR dans la tche aval

    Dans la tche de build phoenix-web, nous rcuprons ensuite le WAR depuis la tche phoenix-integration, en utilisant une configuration trs similaire celle montre ci-dessus (voir Figure 10.49,Rcuprer le fichier WAR depuis la tche d'intgration).

    Figure 10.49. Rcuprer le fichier WAR depuis la tche d'intgration

  • 312

    Pour que le processus de promotion de build fonctionne correctement, il y a une chose importante deplus que nous devons configurer dans la tche de build phoenix-web. Comme nous l'avons voquprcdemment, Jenkins a besoin de pouvoir tre sr que le fichier WAR utilis dans ces tests est lemme que celui gnr dans le build original. Nous faisons cela en activant la cration de fingerprintsur le fichier WAR que nous avons rcupr depuis la tche de build phoenix-integration (qui,rappelez-vous, a originellement t construit par la tche phoenix-default). Comme nous avonscopi ce fichier WAR dans l'espace de travail, une configuration comme celle de Figure 10.50, Nousavons besoin de dterminer le fingerprint du fichier WAR que nous utilisons fonctionnera trs bien.

    Figure 10.50. Nous avons besoin de dterminer le fingerprint du fichier WAR que nous utilisons

    L'tape final consiste configurer la tche de build phoenix-deploy-to-test pour rcuprer ledernier WAR promu (plutt que le dernier russi). Pour faire cela, nous utilisons nouveau le pluginCopy Artifact, mais cette fois nous choisissons l'option "Spcifier par permalien". Ici, Jenkins proposera,entre autres choses, les processus de promotion de build configurs pour la tche de build partir delaquelle vous tes en train de copier. Donc, dans Figure 10.51, Rcuprer le dernier fichier WARpromu, nous rcuprons le dernier fichier WAR promu par la tche phoenix-default, ce qui estprcisment ce que nous voulons.

    Figure 10.51. Rcuprer le dernier fichier WAR promu

    Notre processus de promotion est maintenant prt pour l'action. Quand les tests web automatissrussiront lors d'un build particulier, la tche de build originale sera promu et le fichier WARcorrespondant dploy dans l'environnement de test. Les builds promus sont indiqus par une toile dansl'historique de build (voir Figure 10.52, Les builds promus sont indiqus par une toile dans l'historiquede build). Par dfaut, les toiles sont jaunes, mais vous pouvez configurer la couleur de l'toile dansla configuration de la promotion de build.

  • 313

    Figure 10.52. Les builds promus sont indiqus par une toile dans l'historique de build

    Vous pouvez aussi utiliser l'entre de menu Etat de Promotion (ou cliquez sur l'toile colore dansl'historique de build) pour voir les dtails d'une promotion de build particulire, et mme de rexcutermanuellement une promotion (voir Figure 10.45, Voir les dtails d'une promotion de build). Toutepromotion de build peut tre dclenche manuellement, en cliquant sur "Forcer la promotion" (si cettetche de build n'a jamais t promue) ou R-excuter la promotion (si elle l'a t).

    10.7.4. Agrger des rsultats de tests

    Lorsqu'on rpartit diffrents types de tests dans diffrentes tches de build, il est facile de perdre lavision globale des rsultats de tests de l'ensemble. Ces rsultats sont disperss parmi les diverses tchesde build, sans un endroit central o voir le nombre total de tests excuts et chous.

    Un bon moyen d'viter ce problme est d'utiliser la fonctionnalit d'agrgation de rsultats de tests deJenkins. Ceci rcuprera tout rsultat de test depuis les tches de build avals, et les agrgera dans la tchede build amont. Vous pouvez configurer cela dans la tche de build initiale (amont) en cochant l'option"Agrger les rsultat de test avals" (voir Figure 10.53, Rapport sur l'agrgation des rsultats de test).

    Figure 10.53. Rapport sur l'agrgation des rsultats de test

  • 314

    Les rsultats de test agrgs peuvent tre consults dans la page de dtails du build (voir Figure 10.54,Visualisation des rsultats de tests agrgs). Malheureusement, ces rsultats de test agrgsn'apparaissent pas dans les rsultats de test globaux, mais vous pouvez afficher la liste complte destests excuts en cliquant sur le lien Rsultats de Test Agrgs sur la page du build particulier.

    Figure 10.54. Visualisation des rsultats de tests agrgs

    Pour que cela fonctionne correctement, vous devez vous assurer d'avoir configur la cration defingerprint pour les fichiers binaires utiliss chaque tape. Jenkins agrgera seulement les rsultats detest avals de builds contenant un artefact avec le mme fingerprint.

    10.7.5. Pipelines de Build

    Le dernier plugin que nous allons regarder dans cette section est le plugin Build Pipeline. Le pluginBuild Pipelines emmne l'ide de la promotion de build encore plus loin, et vous aide concevoir etsuperviser des pipelines de dploiement. Un pipeline de dploiement est une faon d'orchestrer vosbuilds au travers d'une srie de passages garantissant la qualit, avec des approbations automatises oumanuelles chaque tape, culminant avec le dploiement en production.

    Le plugin Build Pipeline fournit une autre faon de dfinir des tches de build avals. Un pipeline de build,contrairement aux dpendances avals conventionnelles, est considr comme un processus linaire, unesrie de tches de build excutes en squence.

  • 315

    Pour utiliser ce plugin, commencez par configurer les tches de build avals pour chaque tche de builddans le pipeline, en utilisant le champ Construire d'autres projets comme vous le feriez habituellement.Le plugin Build Pipeline utilise les configurations de build amont ou aval standards, et pour les tapesautomatiques c'est tout ce que vous avez faire. Toutefois, le plugin Build Pipeline supporte aussiles tapes de build manuelles, o un utilisateur doit manuellement approuver l'tape suivante. Pourles tapes manuelles, vous devez aussi configurer les Post-build Actions de votre tche de buildamont : cochez simplement la case Build Pipeline Plugin -> Spcifier Projet Aval, slectionnez l'tapesuivante dans votre projet, et cochez l'option Require manual build executor (voir Figure 10.55,Configurer une tape manuelle dans le pipeline de build).

    Figure 10.55. Configurer une tape manuelle dans le pipeline de build

    Une fois que vous avez configur votre processus de build votre convenance, vous pouvez configurerla vue build pipeline. Vous pouvez crer cette vue comme n'importe quelle autre (voir Figure 10.56,Crer une vue Build Pipeline).

    Figure 10.56. Crer une vue Build Pipeline

    Il y a une astuce connatre lors de la configuration de la vue, cependant. Au moment de l'criture deces lignes, il n'y a pas d'option de menu ou de bouton vous permettant de configurer la vue directement.En fait, vous devez entrer l'URL manuellement. Heureusement, ce n'est pas difficile : ajoutez juste/configure la fin de l'URL lorsque vous affichez cette vue. par exemple, si vous avez appelcette vue phoenix-build-pipeline, comme montr ici, l'URL pour configurer cette vue serait http://my_jenkins_server/view/phoenix-build-pipeline. (voir Figure 10.57, Configurer une vueBuild Pipeline).

  • 316

    Figure 10.57. Configurer une vue Build Pipeline

    La chose la plus importante configurer dans cet cran est la tche initiale. Ceci marque le point d'entrede votre pipeline de build. Vous pouvez dfinir de multiples vues de pipeline de build, chacune avecune tche initiale diffrente. Vous pouvez aussi configurer le nombre maximum de squences de build faire apparatre la fois sur l'cran.

    Une fois que vous avez configur le point de dpart, vous pouvez retourner la vue pour voir l'tatcourant de votre pipeline de build. Jenkins affiche les tches de build successives horizontalement, enutilisant une couleur pour indiquer le rsultat de chaque build (Figure 10.58, Un Pipeline de Builden action). Il y a une colonne pour chaque tche de build dans le pipeline. Ds lors que la tche debuild initiale dmarre, une nouvelle ligne apparat sur cette page. Alors que le build progresse parmi lestches de build successives, Jenkins ajoute une bote colore dans les colonnes successives, indiquantle rsultat de chaque tape. Vous pouvez cliquer sur la bote pour descendre dans un rsultat de buildparticulier pour plus de dtails. Enfin, si une excution manuelle est requise, un bouton sera affich afinque l'utilisateur puisse dclencher la tche.

  • 317

    Figure 10.58. Un Pipeline de Build en action

    Ce plugin est encore relativement nouveau, et ne s'intgre pas avec les autres plugins que nous avonsvus ici. En particulier, il est vraiment conu pour un pipeline de build linaire, et ne s'en sort pas trsbien avec des branches ou des tches de build parallles. Nanmoins, il donne une excellente visionglobale d'un pipeline de build.

    10.8. ConclusionLes tches de build d'Intgration Continue sont beaucoup plus que de simples excutions planifies descripts de build. Dans ce chapitre, nous avons revu un certain nombre d'outils et de techniques vouspermettant d'aller au del de vos tches de build typiques, en les combinant afin qu'elles travaillentensemble comme partie d'un processus plus large. Nous avons prsent vu comment les tches de buildparamtres et multiconfiguration ajoutent un lment de flexibilit aux tches de build ordinaires envous permettant d'excuter la mme tche de build avec diffrents ensembles de paramtres. D'autresoutils aident coordonner et orchestrer des groupes de tches de build relies. Les plugins Joins etLocks and Latches vous aident coordonner des tches de build s'excutant en parallle. Et les pluginsBuild Promotions et Build Pipelines, avec l'aide du plugin Copy Artifacts, rendent relativement facilela conception et la configuration de stratgies de promotion de build complexes pour vos projets.

  • Chapter 11. Builds distribus11.1. IntroductionL'une des fonctionnalits les plus puissantes de Jenkins est sans aucun doute sa capacit rpartir lestches de build sur un grand nombre de machines. Il est assez simple de configurer une ferme de serveursde build, soit pour rpartir la charge sur de multiples machines, soit pour excuter des tches de builddans diffrents environnements. C'est une stratgie trs efficace qui peut potentiellement accrotre defaon considrable la capacit de votre infrastructure d'IC.

    Les builds distribus sont gnralement utiliss soit pour absorber une charge additionnelle, parexemple pour absorber les pics d'activit dans les builds en ajoutant dynamiquement des machinessupplmentaires selon les besoins, soit pour excuter des tches de build spcialises sur des systmesd'exploitation ou des environnements spcifiques. Par exemple, vous pourriez avoir besoin d'excuterune tche de build spciale sur une machine ou un systme d'exploitation particulier. Si vous avez besoind'excuter des tests web en utilisant Internet Explorer, vous devrez utiliser une machine Windows. Oualors une de vos tches de build pourrait tre particulirement consommatrice en ressources, et ncessited'tre excute sur une machine ddie afin de ne pas pnaliser d'autres tches de build.

    La demande pour des serveurs de build peut aussi fluctuer dans le temps. Si vous travaillez avec descycles de release de produit, vous pouvez avoir besoin de beaucoup plus de tches de build en finde cycle, par exemple, lorsque des tests fonctionnels ou de rgression plus complets deviennent plusfrquents.

    Dans ce chapitre, nous verrons comment configurer et grer une ferme de serveurs de build en utilisantJenkins.

    11.2. L'Architecture de build distribue de JenkinsJenkins utilise une architecture matre/esclave pour grer les builds distribus. Votre serveur Jenkinsprincipal (celui que nous avons utilis jusqu' prsent) est le matre. En un mot, le rle du matre est degrer l'ordonnancement des tches de build, de rpartir les builds sur les esclaves pour leur excutionrelle, surveiller les esclaves (en les mettant ventuellement hors-ligne si ncessaire) et enfin enregistreret prsenter les rsultats de build. Mme dans une architecture distribue, une instance matre de Jenkinspeut aussi excuter des tches de build directement.

    Le rle des esclaves est de faire ce qu'on leur dit, ce qui inclut l'excution de tches de build envoyes parle matre. Vous pouvez configurer un projet pour qu'il s'excute toujours sur un esclave particulier, sur untype particulier de machine, ou simplement laisser Jenkins slectionner le prochain esclave disponible.

    Un esclave est un petit excutable Java qui fonctionne sur une machine distante et se met en coutede requtes de la part de l'instance matre Jenkins. Les esclaves peuvent (et c'est gnralement lecas) s'excuter sur diffrents systmes d'exploitation. L'instance esclave peut tre dmarre de faons

  • 320

    diverses, en fonction du systme d'exploitation et de l'architecture rseau. Une fois que l'instanceesclave est en marche, elle communique avec l'instance matre au travers d'une connexion TCP/IP. Nousregarderons diffrentes configurations dans le reste de ce chapitre.

    11.3. Stratgies Matre/Esclave dans JenkinsIl existe diffrentes faons de configurer une ferme de build distribue avec Jenkins, en fonction devotre systme d'exploitation et de votre architecture rseau. Dans tous les cas, le fait qu'une tche debuild s'excute sur un esclave, et comment cet esclave s'excute, est transparent pour l'utilisateur final :les rsultats du build et les artefacts finiront toujours sur le serveur matre.

    Crer un nouveau noeud esclave Jenkins est un processus simple. Premirement, rendez vous dansl'cran Administrer Jenkins et cliquez sur Grer les noeuds. Cet cran affiche la liste des agentsesclaves (aussi connus en tant que Noeuds en termes plus politiquement corrects), comme montr dansFigure 11.1, Grer les noeuds esclaves. A partir de l, vous pouvez configurer de nouveaux noeudsen cliquant sur Nouveau noeud. Vous pouvez aussi configurer quelques-uns des paramtres lis votreinstallation de build distribue (see Section 11.5, Surveillance des noeuds).

    Figure 11.1. Grer les noeuds esclaves

    Il y a plusieurs stratgies diffrentes lorsqu'il s'agit de grer les noeuds esclaves Jenkins, en fonction devos systmes d'exploitation cibles et d'autres considrations architecturales. Ces stratgies affectent lafaon dont vous configurez vos noeuds esclaves, nous devons donc les considrer sparment. Dans lessections suivantes, nous regarderons les faons les plus frquemment utilises pour installer et configurerdes esclaves Jenkins :

    Le matre dmarre l'agent esclave via SSH

    Dmarrage manuel de l'agent esclave en utilisant Java Web Start

    Installation de l'agent esclave en tant que service Windows

    Dmarrage de l'agent esclave directement depuis la ligne de commande sur la machine esclave

    Chacune de ces stratgies possde ses utilisations, ses avantages et ses inconvnients. Regardonschacune d'entre elles.

  • 321

    11.3.1. Le matre dmarre l'agent esclave en utilisant SSH

    Si vous travaillez dans un environnement Unix, la faon la plus pratique de dmarrer un esclave Jenkinsest sans aucun doute d'utiliser SSH. Jenkins possde son propre client SSH intgr, et presque tous lesenvironnements Unix supportent SSH (habituellement sshd) de base.

    Pour crer un esclave de type Unix, cliquez sur le bouton Nouveau noeud comme nous l'avons mentionnci-dessus. Cela vous demande d'entrer le nom de votre esclave, et son type (voir Figure 11.2, Crerun nouveau noeud esclave). Au moment de l'criture de ces lignes, seuls les esclaves passifs sontsupports en standard; ces esclaves rpondent simplement aux requtes de build en provenance du noeudmatre. C'est la faon la plus commune de mettre en place une architecture de build distribue, et c'estla seule option disponible dans une installation par dfaut.

    Figure 11.2. Crer un nouveau noeud esclave

    Dans cet cran, vous devez simplement fournir un nom pour votre esclave. Lorsque vous cliquez surOK, Jenkins vous permet de fournir plus de dtails sur vos machines esclaves (voir Figure 11.3, Crerun noeud esclave Unix).

  • 322

    Figure 11.3. Crer un noeud esclave Unix

    Ce nom est simplement un moyen unique pour identifier votre machine esclave. Ce peut tre n'importequoi, mais il pourrait tre utile que ce nom vous rappelle la machine physique sur laquelle celafonctionne. Il est aussi utile que ce nom soit compatible avec le systme de fichiers et un format URL.Les espaces sont autoriss, mais cela vous facilitera la vie de les viter. Ainsi, Slave-1 est meilleurque Slave 1.

    La description est aussi purement destine la lecture humaine, et peut tre utilise pour indiquerpourquoi utiliser cet esclave plutt qu'un autre.

    Comme sur l'cran principal de configuration Jenkins, le nombre d'excuteurs vous permet de dfinir lenombre de tches de build concurrentes que ce noeud peut excuter.

    Tout noeud esclave Jenkins ncessite aussi un emplacement qu'il puisse utiliser comme racine, ou,plus prcisment un rpertoire ddi sur la machine esclave que l'agent esclave puisse utiliser pourexcuter des tches de build. Vous dfinissez ce rpertoire dans le champ racine du disque distant. Vousdevez fournir un chemin local, spcifique l'OS, tel que /var/jenkins pour une machine Unix ouC:\jenkins sur Windows. Rien d'essentiel n'est stock dans ce rpertoire tout ce qui est importantest renvoy la machine matre une fois que le build est effectu. Vous n'avez donc gnralement pasbesoin de vous inquiter de sauvegarder ces rpertoires comme c'est le cas avec ceux du matre.

    Les libells sont un concept particulirement utile quand votre architecture distribue commence grossir. Vous dfinissez des libells, des tags, pour chaque noeud de build, et configurez ensuite unetche de build afin qu'elle s'excute avec un libell particulier. Les libells peuvent avoir trait au systme

  • 323

    d'exploitation (unix, windows, macosx, etc.), aux environnements (staging, recette, dveloppement,etc.) ou n'importe quel critre que vous trouveriez utile. Par exemple, vous pouvez configurer vos testsautomatiss WebDriver/Selenium pour qu'ils s'excutent avec Internet Explorer, mais seulement sur desnoeuds esclaves avec le libell windows.

    Le champ Utilisation vous permet de configurer l'intensit avec laquelle Jenkins utilisera cet esclave.Vous avez le choix parmi trois options : utiliser cet esclave autant que possible, rserver pour les tchesde build ddies, ou le mettre en ligne quand c'est ncessaire.

    La premire option Utiliser cet esclave autant que possible, indique Jenkins d'utiliser librement cetesclave ds qu'il devient disponible, pour toute tche qu'il peut excuter. C'est de loin l'option la plusutilise, et gnralement celle que vous voulez.

    Quelques fois, cependant, la seconde option peut s'avrer utile. Dans la configuration du projet, vouspouvez lier une tche de build un noeud spcifique c'est utile quand une tche particulire, comme undploiement automatis ou une suite de tests de performance, ncessite d'tre excute sur une machinespcifique. Dans ce cas, l'option Rserver cette machine pour les tches associes uniquement peutavoir du sens. Vous pouvez aller encore plus loin en positionnant le nombre maximum d'Excuteurs 1. Dans ce cas, non seulement cet esclave sera rserv pour un type particulier de tche, mais il serauniquement capable d'excuter une seule de ces tches de build tout instant. C'est une configurationtrs utile pour les tests de performance ou de charge, o vous avez besoin de rserver la machine pourqu'elle excute ses tests sans interfrence.

    La troisime option est Mettre cet esclave en ligne lors de demande et hors-ligne sinon (voirFigure 11.4, Mettre un esclave hors-ligne lorsqu'il est inactif). Comme le nom l'indique, cette optionindique Jenkins de mettre cet esclave en ligne lorsque la demande est leve et de le mettre hors-ligne lorsque la demande faiblit. Ceci permet de garder quelques esclaves de build pour les priodesd'utilisation importante, sans avoir maintenir dessus un agent esclave fonctionnant en permanence.Quand vous choisissez cette option, vous devez aussi fournir quelques dtails supplmentaires. LeDlai de la demande indique combien de minutes les tches doivent avoir attendu dans la file d'attenteavant que cet esclave ne soit mis en ligne. Le champ Dlai d'inactivit indique combien de temps l'esclavedoit avoir t inactif avant que Jenkins ne le mette hors-ligne.

    Figure 11.4. Mettre un esclave hors-ligne lorsqu'il est inactif

    La mthode de lancement dcide de comment Jenkins lancera le noeud, comme nous l'avons mentionnprcdemment. Pour la configuration dont nous parlons ici, vous choisiriez Lancer les agents esclavessur machines Unix via SSH. Le bouton Avanc vous permet d'entrer des dtails additionnels dontJenkins a besoin pour se connecter la machine esclave Unix : un nom d'hte, un login et mot de passe

  • 324

    et un numro de port. Vous pouvez aussi fournir un chemin vers un fichier de cl prive SSH sur lamachine matre (e.g., id_dsa ou id_rsa) utiliser pour une authentification sans mot de passe parcls Publique/Prive.

    Vous pouvez aussi configurer quand Jenkins dmarre ou arrte l'esclave. Par dfaut, Jenkins garderasimplement l'esclave en fonctionnement et l'utilisera chaque fois qu'il en aura besoin (option Garder cetesclave en ligne autant que possible). Si Jenkins remarque que l'esclave est dconnect (par exemple cause d'un redmarrage serveur), il essaiera de le redmarrer s'il le peut. Sinon, Jenkins peut tre plusconservateur avec vos ressources systmes, et mettre l'esclave hors-ligne lorsqu'il n'en a pas besoin.Pour faire cela, choisissez simplement l'option Mettre cet esclave en ligne si ncessaire et hors-ligneen cas d'inactivit. C'est utile si vous avez rgulirement des pics et accalmies de l'activit de build,car un esclave peut tre mis hors-ligne pour conserver les ressources systmes pour d'autres tches, etremis en ligne lorsque c'est ncessaire.

    Jenkins a aussi besoin de savoir o il peut trouver les outils de build dont il a besoin pour vos tches debuild sur les machines esclaves. Ceci inclut aussi bien les JDKs que les outils de build comme Maven,Ant, et Gradle. Si vous avez configur vos outils de build pour tre automatiquement installs, vousn'aurez gnrallement pas de configuration supplmentaire effectuer pour vos machines esclaves;Jenkins tlchargera et installera les outils au besoin. D'un autre ct, si vos outils de build sont installslocalement sur la machine esclave, vous aurez besoin d'indiquer Jenkins o il peut les trouver. Ceci sefait en cochant la case Emplacement des outils, et en fournissant les chemins locaux pour chaque outilncessaire vos tches de build (voir Figure 11.5, Configurer l'emplacement des outils).

    Figure 11.5. Configurer l'emplacement des outils

  • 325

    Vous pouvez aussi spcifier des variables d'environnement. Celles-ci seront passes vos tches debuild, et ce peut tre un moyen de permettre vos tches de se comporter diffremment en fonction del'endroit o elles s'excutent.

    Une fois que vous avez fait cela, votre nouveau noeud esclave apparatra dans la liste des ordinateurssur la page des Noeuds Jenkins (voir Figure 11.6, Votre nouveau noeud esclave en action).

    Figure 11.6. Votre nouveau noeud esclave en action

    11.3.2. Dmarrer l'agent esclave manuellement via Java Web Start

    Une autre option est de dmarrer l'agent esclave depuis la machine esclave elle-mme en utilisant JavaWeb Start (JNLP). Cette approche est utile si le serveur ne peut pas se connecter l'esclave, par exemplesi la machine esclave s'excute de l'autre ct d'un firewall. Cela fonctionne quel que soit le systmed'exploitation de votre esclave, toutefois c'est l'option la plus souvent utilise pour les esclaves Windows.Cela prsente quelques inconvnients majeurs : le noeud esclave ne peut pas tre dmarr, ou redmarr,automatiquement par Jenkins. Ainsi, si l'esclave tombe, l'instance matre ne peut pas le redmarrer.

    Quand vous faites cela sur une machine Windows, vous devez dmarrer l'esclave Jenkins manuellementau moins une fois. Ceci implique d'ouvrir un navigateur sur la machine, ouvrir la page du noeud esclavesur le matre Jenkins et de lancer l'esclave en utilisant l'icne JNLP bien visible. Une fois que vous avezlanc l'esclave, vous pouvez l'installer comme un service Windows.

    Il y a aussi des moments o vous avez besoin de faire cela depuis la ligne de commande, dans unenvironnement Unix. Vous pourriez avoir besoin de a cause d'un firewall ou d'autres problmesrseau, ou parce que SSH n'est pas disponible dans votre environnement.

    Dtaillons prsent les deux processus.

    La premire chose que vous devez faire dans tous les cas est de crer un nouvel esclave. Comme pour toutnoeud esclave, vous faites cela en cliquant sur l'entre Nouveau noeud dans l'cran Noeuds. Lors de lasaisie des dtails concernant votre noeud esclave, assurez-vous de choisir Lancer les agents esclave viaJNLP dans le champ Mthode de lancement (voir Figure 11.7, Crer un noeud esclave pour JNLP).Rappelez-vous aussi que c'est un noeud esclave Windows, la racine du systme de fichiers distant doit

  • 326

    tre un chemin Windows (comme C:\jenkins-slave). Ce rpertoire n'a pas exister : Jenkins lecrera automatiquement s'il manque.

    Figure 11.7. Crer un noeud esclave pour JNLP

    Une fois que vous avez sauv cette configuration, connectez-vous, ensuite, sur la machine esclave etouvrez l'cran du noeud esclave dans un navigateur, comme montr sur Figure 11.8, Lancer un esclavevia Java Web Start. Vous verrez un large bouton orange Lancer si vous cliquez sur ce bouton, vousdevriez tre capable de lancer un agent esclave directement depuis votre navigateur.

    Figure 11.8. Lancer un esclave via Java Web Start

    Si tout va bien, ceci ouvrira une petite fentre indiquant que votre esclave est prsent en fonctionnement(voir Figure 11.9, L'agent esclave Jenkins en action).

  • 327

    Figure 11.9. L'agent esclave Jenkins en action

    Les navigateurs sont inconstants, toutefois, et Java Web Start n'est pas toujours simple utiliser. Cetteapproche fonctionne habituellement avec Firefox, bien que vous deviez auparavant avoir install le JREJava pour que Firefox comprenne Java. Utiliser JNLP avec Internet Explorer requiert un ensemble (nonngligeable) de bricolages pour associer les fichiers *.jnlp avec l'excutable Java Web Start, un fichierappel javaws, que vous trouverez dans le rpertoire bin de Java. Il est en fait probablement plussimple de le lancer depuis la ligne de commande comme discut ci-dessous.

    Une approche plus fiable, quoique bas-niveau, est de dmarrer l'esclave depuis la ligne de commande.Pour faire a, invoquez simplemet l'excutable javaws depuis une fentre de commande comme suit :

    C:> javaws http://build.myorg.com/jenkins/computer/windows-slave-1/slave-agent.jnlp

    La commande exacte que vous devez excuter, notamment avec l'URL correcte, est idalement affichedans la fentre du noeud esclave Jenkins juste en dessous du bouton de lancement JNLP (voirFigure 11.8, Lancer un esclave via Java Web Start).

    Si la scurit est active sur votre serveur Jenkins, Jenkins communiquera avec l'esclave sur un portspcifique non standard. Si pour une raison quelconque ce port est inaccessible, le noeud esclavechouera au lancement et affichera un message d'erreur similaire celui montr dans Figure 11.10,L'esclave Jenkins chouant la connexion au matre.

    Figure 11.10. L'esclave Jenkins chouant la connexion au matre

    Ceci est habituellement le signe qu'un firewall bloque un port. Par dfaut, Jenkins choisit alatoirementun port pour la communication TCP avec ses esclaves. Cependant si vous devez avoir un port spcifiqueque votre firewall autorise, vous pouvez forcer Jenkins utiliser un port fixe dans l'cran de configuration

  • 328

    systme en slectionnant l'option Fixe dans Port TCP pour les agents esclaves JNLP, comme montrdans Figure 11.11, Configurer le port de l'esclave Jenkins.

    Figure 11.11. Configurer le port de l'esclave Jenkins

    11.3.3. Installer un esclave Jenkins en tant que service Windows

    Une fois que vous avez dmarr votre esclave sur votre machine Windows, vous pouvez vous pargnerla peine d'avoir le redmarrer manuellement chaque fois que votre machine redmarre en l'installantcomme un service Windows. Pour faire cela, slectionnez l'option de menu Installer comme ServiceWindows dans le menu Fichier de la fentre de l'agent esclave (voir Figure 11.12, Installer l'esclaveJenkins en tant que service Windows).

    Figure 11.12. Installer l'esclave Jenkins en tant que service Windows

    Une fois que c'est fait, votre noeud esclave Jenkins dmarrera automatiquement chaque fois quela machine dmarre, et peut tre administr comme n'importe quel autre service Windows (voirFigure 11.13, Grer le service Windows Jenkins).

    Figure 11.13. Grer le service Windows Jenkins

  • 329

    11.3.4. Dmarrer le noeud esclave en mode Headless

    Vous pouvez aussi dmarrer un agent esclave en mode headless, directement depuis la ligne decommande. C'est utile si vous n'avez pas d'interface utilisateur disponible, par exemple si vous dmarrezun noeud esclave JNLP sur une machine Unix. Si vous travaillez avec des machines Unix, il estgnralement plus facile et plus flexible d'utiliser simplement une connexion SSH, mais il y a parfoisdes contraintes de rseau ou d'architecture qui vous empchent d'utiliser SSH. Dans ce genre de cas, ilest encore possible d'excuter un noeud esclave depuis la ligne de commande.

    Pour dmarrer le noeud esclave de cette faon, vous devez utiliser le fichier slave.jar de Jenkins.Vous pouvez le trouver dans JENKINS_HOME/war/WEB-INF/slave.jar. Une fois ce fichier localiset copi sur la machine esclave Windows, vous pouvez l'excuter comme suit :

    java -jar slave.jar \ -jnlpUrl http://build.myorg.com/jenkins/computer/windows-slave-1/slave-agent.jnlp

    Et si votre serveur Jenkins ncessite une authentification, passez simplement l'option -authusername:password :

    java -jar slave.jar \ -jnlpUrl http://build.myorg.com/jenkins/computer/windows-slave-1/slave-agent.jnlp -auth scott:tiger

    Une fois que vous avez dmarr l'agent esclave, assurez de l'installer en tant que service Windows,comme indiqu dans la section prcdente.

    11.3.5. Dmarrer un esclave Windows en tant que service distant

    Jenkins peut aussi grer un esclave Windows distant comme un service Windows, en utilisant leservice Windows Management Instrumentation (WMI) qui est install par dfaut sur Windows 2000ou suprieur (voir Figure 11.14, Permettre Jenkins de contrler un esclave Windows comme unservice Windows). Quand vous choisissez cette option, vous avez seulement besoin de fournir un nomd'utilisateur et un mot de passe Windows. Le nom du noeud doit tre le nom de machine de la machineesclave.

    Ceci est certainement pratique, parce que cela ne requiert pas de se connecter la machine Windowspour la configurer. Toutefois, cette mthode possde quelques limitations en particulier, vous nepouvez pas excuter d'applications ncessitant une interface graphique, vous ne pouvez donc pas mettreen place un esclave de cette faon pour faire du test Web, par exemple. En pratique, cela peut se rvlerun peu compliqu paramtrer, parce que vous pourriez avoir besoin de configurer le firewall Windowspour ouvrir les ports et services appropris. Si vous rencontrez des problmes, assurez-vous que votreconfiguration rseau autorise les connexions TCP aux ports 135, 139, et 445, ainsi que les connexionsUDP aux ports 137 et 138 (voir https://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM pour plus de dtails).

    https://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOMhttps://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM

  • 330

    Figure 11.14. Permettre Jenkins de contrler un esclave Windows comme un service Windows

    11.4. Associer une tche de build avec un esclave ou ungroupe d'esclaves

    Dans la section prcdente, nous avons vu comment attribuer des libells vos noeuds esclaves. C'estun moyen commode pour grouper vos esclaves en fonction de caractristiques telles que le systmed'exploitation, l'environnement cible, le type de base de donnes, ou tout autre critre pertinent dansvotre processus de build. Une application commune de cette pratique est d'excuter des tests fonctionnelsspcifiques un OS sur des noeuds esclaves ddis, ou de rserver une machine particulire aux testsde performance).

    Une fois que vous avez affect vos libells vos noeuds esclaves, vous devez aussi dire Jenkins oil peut excuter les tches de build. Par dfaut, Jenkins utilisera simplement le premier noeud esclavedisponible, ce qui offre gnralement le meilleur temps de traitement global. Si vous avez besoind'attacher une tche de build une machine ou un groupe de machines particulier, vous devez cocherla case Resteindre les emplacements o ce projet peut s'excuter dans la page de configuration dubuild (voir Figure 11.15, Excuter une tche de build sur un noeud esclave particulier). Ensuite, entrezle nom de la machine, ou un libell identifiant un groupe de machines, dans le champ Expression delibell. Jenkins fournira une liste droulante dynamique montrant les noms de machines et libells deau fur et mesure que vous tapez.

  • 331

    Figure 11.15. Excuter une tche de build sur un noeud esclave particulier

    Ce champ admet aussi des expressions boolennes, ce qui vous permet de dfinir des contraintes pluscompliques spcifiant o votre build devrait s'excuter. Le plus simple pour expliquer comment utiliserces expressions est de montrer des exemples. Supposez que vous avez une ferme de construction avecdes noeuds esclaves Windows et Linux (identifis par les libells windows et linux), distribus surtrois sites (sydney, sanfrancisco, et london). Votre application ncessite aussi d'tre teste surdiffrentes bases de donnes (oracle, db2, mysql, et postgres). Vous pouvez aussi utiliser deslibells pour distinguer les noeuds esclaves utiliss pour dployer vers diffrents environnements (test,test d'acceptation, production).

    L'utilisation la plus simple des expressions de libells est de dfinir o une tche de build peut ou nepeut pas tre excute. Si vos tests web ncessitent Internet Explorer, par exemple, vous aurez besoinde les excuter sur une machine Windows. Vous pourriez exprimer cela en indiquant simplement lelibell suivant :

    windows

    Sinon, vous pourriez vouloir excuter vos tests sur Firefox, mais seulement sur des machines Linux.Vous pourriez exclure les machines Windows de l'ventails des noeuds candidats en utilisant l'oprateur! :

    !windows

    Vous pouvez aussi utiliser les oprateurs et (&&) et ou (!!) pour combiner les expressions. Par exemple,supposez que la base Postgres soit uniquement teste pour Linux. Vous pourriez dire Jenkins d'excuterune tche de build particulire seulement sur les machines Linux sur lesquelles est install Postgres enutilisant l'expression suivante :

  • 332

    linux && postgres

    Ou vous pourriez spcifier qu'une tche de build particulire doit uniquement tourner surl'environnement de test d'acceptation utilisateur de Sydney ou Londres :

    uat && (sydney || london)

    Si votre nom de machine contient des espaces, vous devrez les entourer de double quotes :

    "Windows 7" || "Windows XP"

    Il y a aussi deux oprateurs logiques plus avancs que vous pourriez trouver utile. L'oprateur implique(=>) vous permet de dfinir une contrainte logique de la forme si A est vrai, alors B doit aussi trevrai. Par exemple, supposez que vous ayez une tche de build qui peut s'excuter sur n'importe quelledistribution Linux, mais que si c'est une machine Windows, ce doit tre Windows 7. Vous pourriezexprimer cette contrainte comme suit :

    windows -> "Windows 7"

    L'autre oprateur logique est l'oprateur si-et-seulement-si (. Cette opration vous permet dedfinir des contraintes plus fortes de la forme "Si A est vrai, alors B doit tre vrai, mais si A est faux, alorsB doit tre faux". Par exemple, supposez que les tests Windows 7 doivent uniquement tre excuts surl'environnement de tests d'acceptation utilisateur, et que seuls les tests Windows 7 doivent tre excutsdans l'environnement de tests d'acceptation. Vous pourriez exprimer cela comme montr ici :

    "Windows 7" uat

    11.5. Surveillance des noeuds

    Jenkins ne distribue pas les tches de build aux agents esclaves et advienne que pourra : il surveille pro-activement les machines esclaves, et mettra un noeud offline s'il considre que celui-ci est incapabled'effectuer un build sans danger. Vous pouvez dfinir exactement ce que Jenkins surveille dans l'cranGrer les noeuds (voir Figure 11.16, Jenkins surveille proactivement vos agents de build). Jenkinssurveille les agents esclave de plusieurs faons. Il surveille le temps de rponse : un temps de rponseexcessif peut indiquer soit un problme rseau soit que la machine est tombe. Il surveille aussi laquantit d'espace disque, l'espace disque temporaire et l'espace de swap disponible l'utilisateur Jenkinssur la machine esclave, puisque les tches de build peuvent notoirement tre consommatrices en espacedisque. Il garde aussi un oeil sur les horloges systmes, parce que si les horloges ne sont pas correctementsynchronises, des erreurs bizarres peuvent apparatre. Si l'un de ces critres n'est pas rempli, Jenkinsmettra automatiquement le serveur hors-ligne.

  • 333

    Figure 11.16. Jenkins surveille proactivement vos agents de build

    11.6. Cloud computingLe cloud computing consiste utiliser des ressources matrielles sur Internet comme extension et/ouen remplacement de votre architecture informatique locale. Le cloud computing est en expansion dansplusieurs domaines de l'entreprise, incluant l'email et le partage de document (Gmail et Google Apps sontdes exemples particulirement connus, mais il y en a d'autres), stockage de donnes hors-site (commeAmazon S3), aussi bien bien que des services techniques comme des dpts de code source (commeGitHub, Bitbucket, etc.) et de nombreux autres.

    Bien sr les solutions d'architecture matrielle externalise existent depuis longtemps. Le point principalqui distingue le cloud computing des services plus traditionnels est la vitesse et la flexibilit avec laquelleun service peut tre mont, et dmont quand il n'est plus ncessaire. Dans un environnement de cloudcomputing, une nouvelle machine peut fonctionner et tre disponible en quelques secondes.

    Cependant, le cloud computing dans le contexte de l'Intgration Continue n'est pas toujours aussi simplequ'il n'y parat. Pour qu'une approche base sur le cloud fonctionne, certaines de vos ressources internespourraient devoir tre disponibles au monde extrieur. Ceci peut inclure l'ouverture d'accs votresystme de contrle de version, votre base de donnes de test, et n'importe quelle autre ressourceque vos builds et vos tests requirent. Tous ces aspects doivent tre examins attentivement lors duchoix d'une architecture d'IC base sur le cloud, et pourrait limiter vos options si certaines ressourcesne peuvent tout simplement pas tre accdes depuis Internet. Malgr tout, l'IC base sur le cloud a lepotentiel pour vous offrir d'normes bnfices sur l'volutivit de votre infrastructure.

    Dans les sections suivantes, nous regarderons comment utiliser les services de cloud computingd'Amazon EC2 pour mettre en place une ferme de build base sur le cloud.

    11.6.1. Utiliser Amazon EC2

    En plus de vendre des livres, Amazon est l'un des fournisseurs les plus connus de services cloudcomputing. Si vous tes prt payer pour le service, Amazon peut vous fournir des machines de build quipeuvent soit tre utilises de faon permanente comme partie de votre ferme de build, soit mis en ligneau besoin lorsque vos machines de build existantes deviennent surcharges. C'est un moyen excellent

  • 334

    et raisonnablement coteux pour absorber la charge exceptionnel de build en fonction de vos besoins,et sans le mal de tte associ des machines physiques supplmentaires maintenir.

    Si vous voulez la flexibilit d'une architecture d'IC base sur le cloud, mais que vous ne voulez pasexternaliser votre matriel, une autre option est de mettre en place un cloud Eucalyptus. Eucalyptusest un outil open source qui vous permet de crer localement un cloud priv sur du matriel existant.Eucalyptus utilise une API compatible avec Amazon EC2 et S3, et fonctionne bien avec Jenkins.

    11.6.1.1. Mettre en place votre ferme de build Amazon EC2

    Amazon EC2 est probablement le service de cloud computing commercial le plus populaire et le plusconnu. Pour utiliser ces services, vous devrez crer un compte EC2 avec Amazon si vous n'en avezpas dj un. Le processus requis pour faire cela est bien document sur le site web d'Amazon, nousn'insisterons donc pas ici sur le sujet. Une fois que vous avez cr votre compte, vous pouvez crer desmachines virtuelles et des images de machines qui formeront votre ferme de build base sur EC2.

    Quand vous utilisez Amazon EC2, vous crez des machines virtuelles, appeles instances, en utilisantla console de gestion Amazon Web Services (AWS) (voir Figure 11.17, Vous grez vos instances EC2en utilisant la console de gestion Amazon AWS). Ce site web vous permet de grer vos instancesen fonctionnement et d'en crer de nouvelles. Vous crez ces instances partir d'images prdfinies,appeles Amazon Machine Images (AMIs). Il y a plusieurs images AMI, la fois d'Amazon et dansle domaine public, que vous pouvez utiliser comme point de dpart, couvrant la plupart des systmesd'exploitation populaires. Une fois que vous avez cr une nouvelle instance, vous pouvez vous yconnecter soit via SSH (pour les machines unix) soit via une connexion distance Windows, pour laconfigurer en fonction de ce que vous voulez en faire.

    Figure 11.17. Vous grez vos instances EC2 en utilisant la console de gestion Amazon AWS

    Pour mettre en place une ferme de build, vous aurez galement besoin de configurer la votre, rendez-vous simplement dans le menu Paires de cls dans la Scurit du serveur de build afin d'tre en mesured'accder vos instances EC2. En particulier, vous aurez besoin d'installer les outils de l'API AmazonEC2, de configurer les cls prives/publiques appropries, et d'autoriser les connexions SSH depuisvotre serveur ou votre rseau vers vos instances Amazon. Encore une fois, les dtails indiquant commentfaire cela sont bien documents pour tous les systmes d'exploitation principaux sur le site web EC2.

  • 335

    Vous pouvez utiliser les instances Amazon EC2 de deux faons soit vous crez les machinesesclaves sur Amazon EC2 et les utilisez comme machines distantes, soit vous demandez Jenkins deles crer dynamiquement pour vous la demande. Ou vous pouvez avoir une combinaison des deux.Les approches ont leur utilit, et nous discuterons de chacune d'elles dans les sections suivantes.

    11.6.1.2. Utiliser des instances EC2 comme partie de votre ferme de build

    Crer une nouvelle instance EC2 revient tout simplement choisir une image de base que vous voulezutiliser. Vous devrez juste fournir quelques dtails de base propos de l'instance, comme sa taille etsa capacit, et la cl prive que vous voulez utiliser pour accder la machine. Amazon crera ensuiteune nouvelle machine virtuelle base sur cette image. Une fois que vous avez configur cela, uneinstance EC2 est en substance une machine comme n'importe quelle autre, et il est simple et commodede configurer des machines EC2 permanentes ou semi-permanentes comme part de votre infrastructurede build. Vous pourriez mme opter pour utiliser une image EC2 pour votre serveur matre.

    Configurer une instance EC2 existante comme un esclave Jenkins est peu diffrent que de configurern'importe quel autre esclave distant. Si vous mettez en place un esclave EC2 Unix ou Linux, vousdevrez rfrencer le fichier de cl prive (voir Figure 11.18, Configurer un esclave Amazon EC2)que vous avez utilis pour crer l'instance EC2 sur la console de gestion AWS. En fonction du typede Linux que vous utilisez, vous pourriez aussi avoir besoin de fournir un nom d'utilisateur. La plupartdes distributions se connectent en tant que root, mais certaines, comme Ubuntu, ncessitent un nomd'utilisateur diffrent.

    Figure 11.18. Configurer un esclave Amazon EC2

    11.6.1.3. Utiliser des instances dynamiques

    La seconde approche implique de crer de nouvelles machines Amazon EC2 dynamiquement,lorsqu'elles sont ncessaires. Configurer des instances ddies n'est pas difficile, mais cela ne s'adaptepas trs bien la charge. Une meilleure approche est de laisser Jenkins crer de nouvelles instances enfonction du besoin. Pour faire cela, vous aurez besoin d'installer le plugin Jenkins Amazon EC2. Ceplugin permet Jenkins de dmarrer des esclaves EC2 sur le cloud la demande, et de les teindreensuite lorsqu'ils ne sont plus ncessaires. Le plugin fonctionne la fois avec Amazon EC2, et Ubuntu

  • 336

    Enterprise Cloud. Nous nous concentrerons ici sur Amazon EC2. Notez qu' l'criture de ces lignes leplugin supportait seulement la gestion des images EC2 Unix.

    Une fois que vous avez install le plugin et redmarr Jenkins, allez dans l'cran principal deconfiguration et cliquez sur Ajouter un Nouveau Cloud (voir Figure 11.19, Configurer un esclaveAmazon EC2). Choisissez Amazon EC2. Vous devez fournir votre cl d'identification d'accs Amazon(NdT : Amazon Access Key ID) et votre cl d'accs secrte afin que Jenkins puisse communiquer avecvotre compte Amazon EC2. Vous pouvez accder ceux-ci dans l'cran Paires de cls de votre tableaude bord EC2.

    Figure 11.19. Configurer un esclave Amazon EC2

    Vous devrez aussi fournir votre cl prive RSA. Si vous n'en avez pas, rendez vous simplement dans lemenu Paires de cl dans l'cran Security Credential et crez en une. Cela crera une nouvelle paire decl pour vous et tlchargera la cl prive. Conservez la cl prive dans un endroit sr (vous en aurezbesoin si vous voulez vous connecter vos instances EC3 via SSH).

    Dans les options avances, vous pouvez utiliser le champ Limite d'Instances pour limiter le nombred'instances EC2 que Jenkins lancera. Cette limite est lie au nombre total d'instances en excution, passeulement celles que Jenkins excute en ce moment. C'est une mesure de scurit utile, parce que vouspayez pour le temps pendant lequel vos instances restent actives.

    Une fois que vous avez configur votre connexion EC2 globale, vous devez dfinir les machines aveclesquelles vous travaillerez. Vous faites cela en spcifiant l'identifiant d'Image Miroir Amazon (AMI) del'image serveur avec laquelle vous aimeriez dmarrer. Amazon fournit quelques images de dmarrage,et plusieurs autres le sont par la communaut, toutefois elles ne fonctionneront pas toutes avec EC2. A

  • 337

    l'criture de ces lignes, seules certaines images bases sur des distributions Linux 32-bit fonctionnentcorrectement.

    Les images AMI prdfinies par Amazon et publiques sont des points de dpart utiles pour vos machinesvirtuelles permanentes, mais pour les besoins inhrents la mise en oeuvre d'un cloud dynamiquebas sur EC2, vous devez dfinir vos propres AMI avec les outils essentiels (Java, outils de build,configuration SCM etc.) prinstalls. Heureusement, c'est un processus simple : dmarrez simplementavec une AMI gnrique (de prfrence une compatible avec le plugin Jenkins EC2), et installez toutce dont vous avez besoin. Assurez-vous d'utiliser une image EBS. De cette faon, les changementsque vous faites sur votre instance serveur sont sauvegards sur un volume EBS afin que vous ne lesperdiez pas lorsque le serveur s'teint. Crez alors une nouvelle image en slectionnant l'option Crerune image dans l'cran Instances de la console de gestion EC2 (voir Figure 11.20, Crer une nouvelleimage Amazon EC2). Vrifiez que SSH est ouvert depuis l'adresse IP de votre serveur de build dans legroupe de scurit par dfaut sur Amazon EC2. Si vous ne faites pas cela, Jenkins chouera aprs avoirattendu trop longtemps le dmarrage du nouveau noeud esclave.

    Une fois que vous aurez prpar votre image, vous serez capable de l'utiliser pour votre configurationEC2.

    Figure 11.20. Crer une nouvelle image Amazon EC2

    A prsent, Jenkins crera automatiquement une nouvelle instance EC2 en utilisant cette image lorsquec'est ncessaire, et supprimera (ou la terminera, en termes Amazon) l'instance une fois qu'il n'en auraplus besoin. Sinon, vous pouvez ajouter un nouvel esclave EC2 manuellement depuis l'cran Noeuds enutilisant le bouton Provisionner via EC2 (voir Figure 11.21, Ajouter un nouvel esclave Amazon EC2manuellement). C'est un moyen utile pour tester votre configuration.

  • 338

    Figure 11.21. Ajouter un nouvel esclave Amazon EC2 manuellement

    11.7. Utiliser le service CloudBees DEV@cloud

    Un autre option que vous pourriez considrer est d'excuter votre instance Jenkins en utilisant unearchitecture base sur le cloud ddie Jenkins, comme le service DEV@cloud offert par CloudBees.CloudBees fournit du "Jenkins as a service" et d'autres services de dveloppement varis (comme Sonar)autour de Jenkins. En utilisant un service spcifique ddi Jenkins, il n'est pas ncessaire d'installer (oude grer) des matres ou esclaves Jenkins sur vos machines. Une instance matre est automatiquementconfigure pour vous, et quand vous donnez une tche construire, CloudBees met disposition unesclave pour vous et le reprend quand la tche est effectue.

    Comment cette approche se compare-t-elle l'architecture base sur Amazon EC2 que nous avonsprsent dans la section prcdente ? L'avantage principal est qu'il y a beaucoup moins de travail effectuer dans la gestion du matriel de votre architecture d'IC. Utiliser l'infrastructure Amazon EC2vous vite d'avoir vous soucier du matriel, mais vous avez encore configurer et grer vos imagesde serveur par vous-mme. L'architecture CloudBees DEV@cloud est de plus haut-niveau, un servicecentr sur l'IC, qui fournit non seulement un serveur Jenkins mais aussi d'autres outils en relation commedes dpts SVN ou Git, de la gestion utilisateur, et Sonar. En plus, le modle de tarification (paiement la minute) est sans doute mieux adapt une architecture d'IC base sur le cloud que l'approche parpaiement l'heure utilise par Amazon.

    Les services bass sur Amazon EC2 sont souvent, mais pas toujours, utilis dans un environnement de"cloud hybride" o vous dchargez vos tches sur le cloud, mais un certaine quantit de vos build restentchez vous. Le service DEV@cloud de CloudBees est une solution de cloud public o le build complet sedroule dans le cloud (bien que CloudBees offre une solution similaire fonctionnant sur un cloud priv).

    Crer un compte CloudBees DEV@cloud est facile, et vous pouvez en utiliser un gratuit pourexprimenter le service (notez que le service gratuit CloudBees a seulement un nombre limit de pluginsdisponibles ; vous devrez vous inscrire la version professionnelle pour pouvoir utiliser la gammecomplte de plugins). Pour crer un compte CloudBees, allez sur la page d'enregistrement1. Vous devrezentrer quelques informations telles que le nom d'utilisateur, des informations email, et un nom de compte.

    1 https://grandcentral.cloudbees.com/account/signup

    https://grandcentral.cloudbees.com/account/signuphttps://grandcentral.cloudbees.com/account/signup

  • 339

    Une fois enregistr, vous aurez accs la fois aux services DEV@cloud et RUN@cloud (en rsum laplateforme entire CloudBees).

    A ce stade, vous devrez souscrire au service DEV@cloud. Pour nos besoins, vous pouvez vous ensortir en choisissant simplement l'option gratuite. Vous devrez attendre quelques minutes que CloudBeesmette disposition un matre Jenkins pour vous. L'tape suivante est de valider votre compte (ceci aideCloudBees viter la cration de comptes factices de faire tourner des tches fallacieuses sur le service).Cliquez sur le lien de validation, et entrez votre numro de tlphone. Un appel entrant automatiquevous donnera un code ; entrez le code sur le formulaire. Une fois ceci fait, vous pouvez commencer excuter des builds.

    Votre premire escale aprs connexion sera la console de gestion (appele GrandCentral). Cliquez surle bouton Jenkins Builds pour vous rendre sur votre matre Jenkins flambant neuf.

    A partir de l, votre interaction avec la plateforme DEV@cloud est exactement comme un Jenkinsautonome. Quand vous crez une nouvelle tche de build, pointez simplement sur votre dpt de codesource existant et appuyez sur build repository. DEV@cloud mettra disposition un esclave pour vouset lancera un build (cela pourrait prendre une minute ou deux pour prparer l'esclave).

    11.8. ConclusionDans le domaine de l'Intgration Continue, les builds distribus sont la cl d'une architecture vraimentvolutive. Que vous ayez besoin de capacit de build supplmentaire en un claquement de doigt, ou si vosmodles de build sont sujet des priodes de pics de demande, une architecture de build distribue est unexcellent moyen d'absorber une charge additionnelle. Les builds distribus sont aussi un bon moyen pourdlguer des tches spcialises, comme du test web spcifique un OS, certaines machines ddies.

    Une fois que vous commencez suivre le chemin des builds distribus, les fermes distribues bases surle cloud sont une extension trs logique. Mettre vos serveurs de build dans le cloud simplifie l'volutivitde votre infrastructure de build lorsque cela devient ncessaire, et autant que ncessaire.

  • Chapter 12. Dploiement automatiset livraison continue12.1. Introduction L'Intgration Continue ne devrait pas s'arrter une fois que votre application compile correctement.Elle ne devrait pas non plus s'interrompre une fois que des tests, contrles automatiques ou audit de laqualit du code puissent tre lancs. L'enchainement naturel, une fois toutes ces tapes mises en oeuvre,est d'tendre votre processus de construction automatis au dploiement. Cette pratique est connueglobalement sous le nom de Dploiement Automatis ou Dploiement Continu.

    Dans sa forme la plus labore, le Dploiement Continu est le processus o toute modification ducode, dote des tests automatiss et autres vrifications appropries, est immdiatemement dployeen production. Le but est de rduire la dure du cycle ainsi que le temps et l'effort du processusde dploiement. Cela aide galement les quipes de dvelopemment rduire le temps ncessairepour livrer des fonctionnalits individuelles ou des corrections de bogue, et par consquent augmentesignificativement la productivit des quipes. Rduire ou liminer ces priodes d'intenses activitsmenant une livraison traditionnelle ou un dploiement libre galement du temps et des ressourcespour amliorer les processus et pour l'innovation. Cette approche est comparable la philosophie del'amlioration continue promue par des processus Lean tel que Kanban.

    Cependant, dployer systmatiquement le dernier code en production n'est pas toujours appropri,quelque soit la qualit de vos tests automatiss. De nombreuses organisations ne sont pas prpares ce que de nouvelles versions apparaissent sans annonce chaque semaine. Des utilisateurs ont peuttre besoin d'tre forms, du marketing peut tre ncessaire autour du produit et ainsi de suite. Unevariante plus conservative de ce principe, souvent vue dans les organisations de grande taille, est d'avoirle processus de dploiement entirement automatis mais de dclencher le dploiement effectif viaun mcanisme un clic. Cela est connu sous le nom de Livraison Continue, et a tous les avantagesdu Dploiement Continu sans ses inconvnients. Des variantes au processus de Livraison Continuepeuvent aussi impliquer des dploiements automatiss vers certains environnement (tels que test etAQ) tout en utilisant un dploiement manuel un clic pour d'autres environnements (tels que recetteet production). La caractristique la plus importante de la Livraison Continue est que chaque buildayant pass avec succs tous les tests automatiss et vrifications de qualits appropris puisse trepotentiellement dploy en production au moyen d'un processus entirement automatis et dclenchvia un clic, au choix de l'utilisateur final et en quelques minutes. Le processus n'est cependant pasautomatique : c'est l'quipe mtier et non informatique qui dcide du meilleur moment pour livrer lesdernires modifications.

    Le Dploiement Continu et la Livraison Continue sont tous deux considrs, juste titre, comme signesd'un haut niveau de maturit en termes de processus de build et de pratiques SDLC. Ces techniques nepeuvent exister sans un ensemble trs solide de tests automatiss. Pas plus qu'ils ne peuvent exister sans

  • 342

    un environnement d'Intgration Continue et un squenceur de build robuste. En effet, le DploiementContinu ou la Livraison Continue reprsente gnralement la dernire tape et le but d'un pipelinede build. Cependant, vu les avantages significatifs que ces pratiques apportent, elles sont un objectifpertinent. Dans la suite de ce chapitre nous allons utiliser le terme "Dploiement Continu" pour parlertant de Dploiement Continu que de Livraison Continue. En effet, le Dploiement Continu peut tre vucomme la Livraison Continue avec une tape finale (le dploiement en production) dicte par la partiemtier plutt que l'quipe de dvelopement.

    12.2. Mise en oeuvre du dploiement automatis etcontinu

    Dans sa forme la plus lmentaire, le Dploiement Automatis peut tre aussi simple que l'criture devos propres scripts afin de dployer votre application vers un serveur particulier. L'avantage principalde la solution scripte est la simplicit et l'aisance en termes de configuration. Cependant, une telleapproche peut atteindre ses limites si vous avez besoin de mettre en oeuvre des actions de dploiementplus labores, telles qu'installer un logiciel sur une machine ou redmarrer le serveur. Pour des scnariosplus avancs, vous pourriez avoir besoin d'un outil de dploiement/configuration plus sophistiqu telque Puppet ou Chef.

    12.2.1. Le script de dploiement

    Une part essentielle de toute initiative de Dploiement Automatis est un processus de dploiementscript. Bien que celui puisse sembler vident, il y a encore de nombreuses organisations o ledploiement demeure un processus consommateur de resources, compliqu et lourd, incluant copiemanuelle de fichiers, excution manuelle de script, des notes crites la main et ainsi de suite. La bonnenouvelle est qu'en gnral cela n'a vocation pas rester ainsi. Avec un peu de travail, il est gnralementpossible d'crire un script pour automatis la plupart, voir l'intgralit, du processus.

    La complexit d'un script de dploiement varie normment d'une application une autre. Pour unsimple site web, un dploiement de script peut se limiter resynchroniser un dossier sur le serveurcible. De nombreuses applications Java ont Ant ou des plugins Maven qui peuvent tre utilisspour le dploiement. Pour une architecture plus complique, le dploiement peut impliquer plusieursapplications et services sur de multiples serveurs en grappe, le tout coordinn de faon extrment prcise.La plupart des processus de dploiement sont entre ces deux extrmes.

    12.2.2. Mises jour de base de donnes

    Dployer votre application vers le serveur d'application est gnralement seulement une partie dupuzzle. Les bases de donnes, relationnelles ou autres, jouent presque toujours un rle central dansl'architecture logiciel. Bien sr, idalement, votre base de donnes devrait tre parfaite ds le dbut,mais cela est rarement le cas dans le monde rel. En effet, lorsque vous mettez jour votre application,vous avez gnralement galement besoin de mettre une ou plusieurs bases de donnes jour.

  • 343

    Les mises jour de base de donnes sont gnralement plus difficile mettre en oeuvre que les mises jour applicatives, vu que tant la structure que les donnes sont susceptibles d'tre modifies. Cependant,les mises jour de base de donnes sont critiques pour le dveloppement et le dploiement. Elles mritentdonc de l'attention et de la planification.

    Certains frameworks, tels que Ruby on Rails et Hibernate, peuvent supporter automatiquement deschangements structurels d'une base de donnes. En utilisant ces frameworks, vous pouvez usuellementspcifier si vous voulez crer un nouveau schma de la base chaque mise jour ou si vous voulezmettre jour le schma tout en conservant les donnes. Bien que cela semble utile premire vue, cesfonctionnalits sont en fait juste suffisantes pour des environnements non critiques. Ces outils ne grentpas bien les migrations de donnes, point pourtant essentiel. Par exemple, si vous crez une colonnedans votre base de donnes, le processus de mise jour va simplement crer une nouvelle colonne:il ne va pas copier les donnes de l'ancienne colonne vers la nouvelle, pas plus qu'il ne va supprimerl'ancienne colonne de la table mise jour.

    Heuresement, cela n'est pas la seule approche disponible. Un autre outil qui tente de rsoudre le problmecomplexe des mises jour de base de donnes est Liquibase1. Liquibase est un outil open source quipermet d'organiser des processus de mises jour entre versions d'une base de donnes travers uneapproche de haut niveau.

    Liquibase garde un historique des mises jour appliques dans une table de la base de donnes. Ilpeut ainsi aisment amener n'importe quelle base vers l'tat souhait. Par consquent, pas de risqued'appliquer deux fois le mme script de mise jour : Liquibase applique seulement les scripts qui n'ontpas encore t appliqus. Liquibase est aussi capable de dfaire des changements, du moins pour certainstypes de changements. Vu que cela ne fonctionne pas pour tous les changements (les donnes d'unetable supprime, par exemple, ne peuvent pas tre restaures) il est prfrable de ne pas trop comptersur cette fonctionnalit.

    Dans Liquibase, les changements de la base de donnes sont aggrgs sous la forme "d'ensemblesde changement", chacun reprsentant la mise jour dans un format XML indpendant de la basede donnes. Ces ensembles de changement peuvent inclure tous les changements que vous pourriezappliquer une base de donnes, de la cration ou suppression de table la cration ou mise jour decolonne, index ou cls trangres :

    1 http://www.liquibase.org/

    http://www.liquibase.org/http://www.liquibase.org/

  • 344

    Les ensembles de changement peuvent aussi reflter des modifications une table existante. Parexemple, l'ensemble de changement suivant reprsente le renommage d'une colonne :

    Etant donn que cette reprsentation concerne la nature smantique du changement, Liquibaseest capable de raliser correctement tant la mise jour du schma que la migration de donnescorrespondante.

    Liquibase peut aussi bien grer les changements de donnes que de structure. Par exemple, l'ensemblede changement suivant insre une nouvelle ligne de donnes dans une table :

    Chaque ensemble de changements a un identifiant et un auteur, ce qui facilite la traabilit et rduit lerisque de conflit. Les dveloppeurs peuvent tester leurs ensembles de changements leur propre base dedonnes et les archiver une fois qu'ils sont prts. Bien sr, l'tape suivante est de configurer Jenkins pourqu'il applique les mises jour Liquibase la base de donnes approprie avant que les tests d'intgrationou que les dploiements d'applications ne soient raliss, gnralement en tant que partie du script debuild ordinaire du projet.

    Liquibase s'intgre bien dans le processus de build. Il peut tre excut depuis la ligne de commandeou tre intgr dans Ant ou Maven. Pour ce dernier, par exemple, vous pouvez configurer le "MavenLiquibase Plugin" comme suit :

    org.liquibase liquibase-plugin 1.9.3.0 true src/main/resources/liquibase.properties

  • 345

    ...

    En utilisant ainsi Liquibase avec Maven, vous pourriez mettre jour une base de donnes cible vers leschma courant en utilisant ce plugin:$ mvn liquibase:update

    Les informations de connexion par dfaut la base de donnes sont spcifies dans le fichier src/main/resources/liquibase.properties, et ont l'aspect suivant :changeLogFile = changelog.xmldriver = com.mysql.jdbc.Driverurl = jdbc:mysql://localhost/ebankusername = scottpassword = tigerverbose = truedropFirst = false

    Vous pouvez toutefois surcharger n'importe laquelle de ces proprits depuis la ligne de commande, cequi rend facile de configurer un build Jenkins pour mettre jour diffrentes bases de donnes.

    D'autres commandes similaires vous permettent de gnrer un script SQL (si vous avez besoin de lesoumettre votre administrateur de base donnes par exemple), ou de revenir une version prcdentedu schma.

    Cela n'est bien sr qu'un exemple d'une solution possible. D'autres quipes prfrent maintenirmanuellement une srie de scripts SQL de mises jour, voir crivent leur propre solution. L'importantest d'avoir un outillage vous permettant de mettre jour diffrentes bases de donnes de faon fiable etreproductible lors de vos dploiements applicatifs.

    12.2.3. Tests fumigatoires

    N'importe quel dploiement automatis srieux a besoin d'tre suivi par une srie de tests fumigatoiresautomatiss. Un sous ensemble des tests d'acceptance automatiss peut faire un bon candidat. Les testsfumigatoires devraient tre non intrusifs et relativement rapides. Ils doivent pouvoir tre excuts enproduction, ce qui est susceptible de restreindre le nombre d'actions possibles durant les tests.

    12.2.4. Revenir sur des changements

    Un autre aspect important considrer lors de la mise en place du Dploiement Automatis estcomment revenir en arrire si quelque chose se passe mal. Cela est encore plus important si vous voulezimplmenter du Dploiement Continu. Il est en effet critique de pouvoir revenir en arrire si besoin.

    La mise en oeuvre varie grandement en fonction de l'application. Bien qu'il soit relativement simple deredployer une version prcdente d'une application en utilisant Jenkins (nous verrons cela plus loindans ce chapitre), l'application n'est gnralement pas le seul acteur en jeu. Un retour en arrire de labase de donnes un tat prcdent est souvent mettre en oeuvre.

  • 346

    Nous avons vu comment il est possible d'utiliser Liquibase pour les mises jour de base de donnes, etbien sr de nombreuses autres stratgies sont galement possibles. Cependant, revenir un tat prcdentde la base de donnes prsente des dfis particuliers. Liquibase, par exemple, permet de revenir surcertains changements de structure de la base de donnes, mais pas de tous. De plus, des donnes perdues(lors de la suppression de table par exemple) ne peuvent tre restaures en utilisant que Liquibase.

    La faon la plus fiable de retourner un tat prcdent est probablement de prendre une image de labase juste avant la mise jour. Cette image peut ensuite tre utilise lors de la restauration. Une mthodeefficace est d'automatiser ce processus dans Jenkins dans la tche de dploiment, et de sauver l'imagede la base et le fichier binaire dployable en tant qu'artfacts. De cette faon, vous pouvez aismentrestaurer la base de donnes en utilisant l'image sauvegarde et ensuite de redployer l'application enutilisant le fichier dployable sauv. Nous allons regarder un exemple de cette stratgie plus loin dansce chapitre.

    12.3. Dployer vers un serveur d'application

    Jenkins fournit des plugins pour aider dployer votre application vers un certain nombre de serveursd'applications frquemment utiliss. Le plugin Deploy vous permet de dployer vers Tomcat, JBoss, etGlassFish. Et le plugin Deploy Websphere tente de s'occuper des particularits du serveur d'applicationIBM WebSphere.

    Pour d'autres serveurs d'application, vous devez gnralement intgrer le processus de dploiement dansvos scripts de build, ou de recourir des scripts personnaliss, pour dployer votre application. De mme,pour les autres langages, votre procesus de dploiement variera, mais il impliquera souvent d'utiliserdes scripts shell. Par exemple, pour une application Ruby on Rails, vous pouvez utiliser un outil tel queCapistrano or Chef, ou simplement un script shell. Pour une application PHP, un transfert FTP ou viascp peut suffire.

    Regardons en premier certaines stratgies possibles pour dployer votre application Java vers un serveurd'application.

    Lorsque l'application est dploye sur un serveur d'application en fonctionnement, cela est dsignsous le terme dploiement chaud. Cela est gnralement une faon rapide et efficace de mettre votreapplication en ligne. Cependant, en fonction de votre application et de votre serveur d'application, cetteapproche est connue pour causer des fuites de mmoire ou des problmes de verrous sur des resources.Les anciennes versions de Tomcat, par exemple, taient particulirement connues pour cela. Si vousrencontrez ce type de problme, vous pourriez avoir forcer un redmarrage de l'application chaquedploiement, ou planifier un redmarrage de l'application chaque nuit sur votre serveur de test.

    12.3.1. Dployer une application Java

    Dans cette section, nous allons regarder un exemple montrant comment dployer votre application webJava ou JEE vers un serveur d'application tel que Tomcat, JBoss, ou GlassFish.

  • 347

    L'un des principes fondamentaux du dploiement automatis est de rutiliser vos fichiers binairesdployables. Il est inefficace et potentiellement dangereux de raliser un nouveau build pendantle processus de dploiement. En effet, imaginer que vous excutiez une srie de tests unitaire etd'intgration sur une version donne de votre application, avant de la dployer dans un environnementde test. Si vous reconstruisez le binaire avant de le dployer, le code source peut avoir changer depuisla version teste, et donc vous ne savez pas exacement ce que vous dployez.

    Un processus plus efficace est de rutiliser des binaires gnrs par un build prcdent. Par exemple,vous pourriez configurer une tche de build de faon excuter les tests unitaires et d'intgration avantde dployer un fichier binaire (gnralement un fichier WAR ou EAR). Vous pouvez faire cela trsefficacement en utilisant le plugin Copy Artifact (voir Section 10.7.2, Copier des artefacts). Ce pluginvous permet de copier un artefact d'un autre espace de travail dans l'espace de travail de la tche de buildcourante. Cela, lorsque combin avec un trigger de build normal ou avec le plugin Build Promotion,vous permet de dployer prcisment le fichier binaire que vous avez construit et test dans la phaseprcdente.

    Cette approche impose certaines contraintes dans la faon de construire votre application. En particulier,toute configuration spcifique un environnement doit tre externalise hors de l'application; lesconnections JDBC et autres lments de configuration ne doivent pas tre inclus dans votre fichier WAR,mais plutt, par exemple, tre dfinis au moyen de JDNI ou dans un fichier de proprits externe. Sice n'est pas le cas, vous pourriez devoir construire partir d'une rvision donnes du gestionnaire desource, comme discut pour Subversion dans Section 10.2.4, Construire partir d'un tag Subversion.

    12.3.1.1. Utiliser le plugin Deploy

    Si vous dployez sur serveur Tomcat, JBoss ou GlassFish, l'outil le plus utile votre disposition seraprobablement le plugin Deploy. Ce plugin rend relativement simple l'intgration de ces plateformes dansvotre processus de build Jenkins. Si vous dployer sur IBM Websphere, vous pouvez utilisez le plugin Websphere Deploy dans le mme but.

    Voyons ce plugin en action, en utilisant le squenceur de build illustr dans Figure 12.1, Une chanesimple de dploiement automatis.

    Figure 12.1. Une chane simple de dploiement automatis

  • 348

    Ici, le build par dfaut (gameoflife-default) excute les tests unitaires et d'intgration, puis cr undployable binaire sous la forme d'un fichier WAR. Le build des mtriques (gameoflife-metrics)lance des contrles supplmentaires sur les standards de codage et la couverture des tests. Si ces deuxbuilds russissent, l'application sera automatiquement dploye vers l'environnement de test par la tchede build gameoflife-deploy-to-test.

    Dans la tche de build gameoflife-deploy-to-test, nous utilisons le plugin Copy Artifact plugin pourrcuprer le fichier WAR gnr dans la tche gameoflife-default puis nous le copions dansl'espace de travail de la tche courante (voir Figure 12.2, Copier l'artefact binaire dployer).

    Figure 12.2. Copier l'artefact binaire dployer

    Ensuite, nous utilisons le plugin Deploy pour dployer le fichier WAR sur le serveur de test. Biensr, il est gnralement possible, et pas trop difficile, d'crire la main un tel script de dploiement.Dans certains cas, cela peut tre votre seul recours. Toutefois, si un plugin Jenkins existe pour votreserveur d'application, cela peut simplifier considrablement les choses de l'utiliser. Si vous dployez surTomcat, JBoss, ou GlassFish, le plugin Deploy est susceptible de vous aider. Ce plugin utilise Cargopour se connecter votre serveur d'application et y dployer (ou redployer) votre application. Il suffitslectionner le type de serveur vis, spcifier son URL ainsi qu'un nom et mot de passe d'utilisateurayant les droits de dploiement (voir Figure 12.3, Dployer sur Tomcat avec le plugin Deploy).

    Figure 12.3. Dployer sur Tomcat avec le plugin Deploy

    Cela est connu comme le dploiement chaud, c'est dire que l'appplication est dploye sur un serveuren cours de fonctionnement. Cela est gnralement une faon rapide et efficace d'avoir votre application

  • 349

    en ligne, et devrait tre votre solution prfre pour cela. Cependant, en fonction de votre application etde votre serveur, cette approche fut parfois source de fuites de mmoire ou de verrouillage de ressources.Les anciennes versions de Tomcat, par exemple, taient bien connues pour cela. Si cela vous arrive,vous pourriez avoir planifier des redmarrages aprs chaque dploiement, ou ventuellement planifierdes redmarrages nocturnes du serveur d'application de votre environnement de test.

    12.3.1.2. Redployer une version spcifique

    Lorsque vous dployez votre application de faon automatise ou continuellement, il devient critiquede bien identifier la version de l'application actuellement dploye. Il y a plusieurs faons de faire cela,qui varient essentiellement en fonction du rle de Jenkins dans l'architecture de build et de dploiement.

    Certaines quipes utilisent Jenkins comme la source de vrit, o les artefacts sont la fois construits etgards pour rfrence. Si vous stockez vos artefacts dployables dans Jenkins, il est alors parfaitementlogique de dployer vos artefacts directement depuis votre instance Jenkins. Cela est facile faire : dansla prochaine section nous verrons comment faire cela au moyen des plugins Copy Artifacts, Deploy,et Parameterized Trigger.

    Alternativement, si vous gardez vos artefacts dans un dpt d'entreprise tel que Nexus ou Artifactory,alors ce dpt devrait tre le point central de rfrence : les artefacts devraient tre construits et dployspar Jenkins, et les dployer ensuite depuis ici. C'est typiquement le cas lorsque vous utilisez Mavencomme votre outil de build. Des quipes utilisant Gradle ou Ivy sont aussi susceptibles d'utiliser cetteapproche. Les gestionnaires de dpt tels que Nexus et Artifactory, particulirement dans leur ditionscommerciales, rendent cette stratgie plus aise en offrant des fonctionnalits telles que la promotionde build et des dpts intermdiaires qui aident contrler les versions des artefacts.

    Voyons prsent comment vous pourriez implmenter chacune de ces stratgies en utilisant Jenkins.

    12.3.1.3. Dployer une version depuis un build Jenkins prcdent

    Redployer un artefact prddement dploy dans Jenkins est relativement simple. DansSection 12.3.1.1, Utiliser le plugin Deploy, nous avons vu comment utiliser les plugins CopyArtifacts et Deploy pour dployer un fichier WAR produit par une tche de build prcdente vers unserveur d'application. Ce dont nous avons besoin prsent est de laisser l'utilisateur spcifier la version dployer, plutt que de se contenter de dployer le dernier build.

    Nous pouvons faire cela en utilisant le plugin Parameterized Trigger (voir Section 10.2, Tches debuild paramtres). En premier lieu, nous ajoutons un paramtre la tche de construction, en utilisantle type de paramtre Build selector for Copy Artifact (voir Figure 12.4, Ajouter un paramtre Buildselector for Copy Artifact).

  • 350

    Figure 12.4. Ajouter un paramtre Build selector for Copy Artifact

    Cela ajoute un nouveau paramtre votre tche de build (voir Figure 12.5, Configurer le slecteur deparamtrage de build). Vous devez entrer un nom et une description courte. Le nom fourni sera utiliscomme une variable d'environnement pour les tapes suivantes du build.

    Figure 12.5. Configurer le slecteur de paramtrage de build

    Le slecteur de paramtrage de build vous permet de choisir un build prcdent de diverses faons,y compris le dernier build russi, le build en amont ayant dclench cette tche de build ou un buildspcifique. Toutes ces options seront offertes l'utilisateur lorsqu'il ou elle dclenchera un build. Leslecteur par dfaut vous permet de spcifier laquelle de ces options sera propos par dfaut.

    Lorsque l'utilisateur slectionne une tche de build particulire, le numro de build sera galement stockdans la variable d'environnement pour l'utiliser dans les tapes du build. La variable d'environnement estappel COPYARTIFACT_BUILD_NUMBER_MY_BUILD_JOB, o MY_BUILD_JOB est le nom de la tche debuild originelle (en lettres majuscules et avec les caractres autres que AZ convertis en blanc souligns).Par exemple, si nous copions un artefact avec le numro de build 4 vers le project gameoflife-default,la variable d'environnement COPYARTIFACT_BUILD_NUMBER_GAMEOFLIFE_DEFAULT aura la valeurde 4.

  • 351

    La seconde partie de la configuration est de dire Jenkins ce qu'il doit rcuprer, et en provenancede quelle tche de build. Dans la section Build de la configuration de notre projet, nous ajoutons unetape Copy artifacts from another project. L nous spcifions le projet o l'artefact a t construit etarchiv (gameoflife-default dans notre exemple). Vous devez aussi faire en sorte que Jenkins utilise lebuild spcifi dans le paramtre dfini prcdement. Cela se fait en choisissant Specified by a buildparameter dans l'option Which build et en fournissant le nom de variable donn plus tt dans leslecteur de paramtrage de build (voir Figure 12.6, Specifier o trouver les artefacts dployer).Ensuite, il suffit de configrer les artefacts copier comme nous l'avons fait dans l'exemple prcdent.

    Figure 12.6. Specifier o trouver les artefacts dployer

    Enfin, nous dployons l'artefact copi en utilisant le plugin Deploy, comme illustr dans Figure 12.3,Dployer sur Tomcat avec le plugin Deploy.

    Voyons comment ce build fonctionne en pratique. Lorsque nous dclenchons un build manuellement,Jenkins va proposer une liste d'options vous permettant de choisir le build redployer (voir Figure 12.7,Choix du build redployer).

    Figure 12.7. Choix du build redployer

    La plupat de ces options sont explicites.

    L'option latest successful build correspond au build le plus rcent sans prendre en compte les buildschous. Cette option va donc se contenter de dployer nouveau la dernire version. Si vous utilisez

  • 352

    cette option, vous voudrez probablement cocher la case Stable builds only, qui excluera galementtout build instable.

    Si vous avez choisi de supprimer les anciens builds, vous serez capable d'indiquer que certaines tchesde build doivent tre ternellement conserves (voir Section 5.3.1, Options Gnrales). Dans ce cas,vous pouvez choisir de dployer le Latest saved build.

    Une option raisonnable pour une tche de build automatise la fin d'un squenceur de build estUpstream build that triggered this job. Ainsi, vous pouvez tre sr que vous allez dployer l'artefactqui a t gnr (ou promu) par la prcdente tche de build, mme si d'autres builds ont eu lieu depuis.Il est important de noter que, bien que ce type de build paramtr est souvent utilis pour dployermanuellement un artefact spcifique, il peut aussi tre utilis efficacement au sein d'un build automatis.S'il n'est pas dclench manuellement, le build va simplement utiliser la valeur dfinie dans le champdefault selector.

    Vous pouvez aussi choisir l'option Specified by permalink (voir Figure 12.8, Utiliser l'optionSpecified by permalink). Cela vous permet de choisir parmi un certain nombre de valeurs, telles quele dernier build, le dernier build stable, le dernier build russi et ainsi de suite.

    Figure 12.8. Utiliser l'option Specified by permalink

    Cependant, si vous voulez redployer une version particulire de votre application, une option plus utileest Specific build (voir Figure 12.9, Utiliser un build spcifique). Cette option vous demande defournir un numro de build particulier indiquant le build dployer. Cela est la faon la plus flexible deredployer une application, vous avez seulement besoin de connatre le numro du build redployer,mais cela n'est gnralement pas difficile trouver en regardant l'historique du build de la tche de buildoriginelle.

    Figure 12.9. Utiliser un build spcifique

  • 353

    Cela est une faon pratique de dployer ou redployer des artefacts de build Jenkins prcdents.Cependant, dans certains cas, vous pourriez prfrer utiliser un artefact stock dans un dpt d'entreprisecomme Nexus ou Artifactory. Nous allons voir un exemple de cela dans la prochaine section.

    12.3.1.4. Dployer une version depuis un dpt Maven

    De nombreuses organisations utilisent un gestionnaire de dpt tel que Nexus ou Artifactory afin destocker et partager des artefacts binaires tels que des fichiers JAR. Cette stratgie est communmentutilise avec Maven, mais galement avec d'autres outils de build tels que Ant (coupl Ivy ou auxMaven Ant Tasks) et Gradle. Dans un environnement d'Intgration Continue, les versions snapshots etdlivrables sont construites sur votre serveur Jenkins, puis dployes sur votre gestionnaire de dpt(voir Figure 12.10, Utiliser un dpt d'entreprise Maven). A chaque fois qu'un dveloppeur enregistreun changement dans le code source sur le systme de contrle des versions, Jenkins va prendre ceschangements et construire de nouvelles versions snapshot des artefacts correspondant. Jenkins deploiealors ces artefacts snapshots sur le gestionnaire de dpt d'entreprise, o ils peuvent tre mis dispositiondes autres dveloppeurs de l'quipe ou d'autres quipes au sein de l'organisation. Nous avons discutsur la faon de faire pour que Jenkins dploie automatiquement les artefacts Maven dans Figure 12.10,Utiliser un dpt d'entreprise Maven. Une approche similaire peut tre suivie avec Gradle ou Ivy.

    CI build server

    Snapshotdeployments

    Maven enterpriserepository

    Automatedupdates and builds

    SCM server

    Sourcecode changes

    Developers

    Snapshotupdates

    Figure 12.10. Utiliser un dpt d'entreprise Maven

    Les conventions Maven se basent sur un systme bien dfini d'identifiants de version, faisant ladistinction entre des versions SNAPSHOTS et RELEASE. Les versions SNAPSHOT sont considrescomme des builds potentiellement instables des dernires sources, tandis que les versions RELEASEsont des versions officielles tant passes au travers d'un processus de livraison plus formel.

  • 354

    Typiquement, les artefacts SNAPSHOT sont rservs un usage interne l'quipe de dveloppement,tandis que les versions RELEASE sont considres comme prtes pour des tests plus avancs.

    Une approche trs similaire peut tre utilise pour des artefacts dployables tels que les fichiers WAR ouEAR, qui sont construits et tests sur le serveur d'intgration continue, puis dploys automatiquementvers le dpt d'entreprise, souvent au sein d'un squenceur de build impliquant des tests automatiss etdes contrles qualit (voir Section 10.7, Pipelines de build et promotions). Les versions SNAPSHOTsont typiquement dployes sur un serveur de test pour des tests automatiss ou manuels, afin dedterminer si une version est prte pour tre officiellement publies.

    La stratgie exacte utilise pour dterminer quand une version est crer et comment elle est dployevarie grandement d'une organisation une autre. Par exemple, certaines quipes prfrent un processusformel la fin de chaque itration, avec un numro de version bien dfini et des notes de livraisoncorrespondantes distribues aux quipes d'assurance qualit pour des tests supplmentaires. Quand uneversion particulire obtient le feu vert de l'assurance qualit, elle peut tre dploye en production.D'autres prfrent utiliser un processus lean, dployant une nouvelle version lorsqu'un correctif ou unenouvelle fonctionnalit est prt tre dploy. Si une quipe est particulirement confiante dans sestests automatiss et ses contrles qualit, il est mme possible d'automatiser compltement le processus,en gnrant et livrant une nouvelle version priodiquement (par exemple chaque nuit) ou chaque foisqu'un changement a t ralis.

    Il y a de nombreuses faons d'implmenter ce type de stratgie. Dans le reste de cette section,nous verrons comment la raliser via un projet Maven multimodule conventionnel. Notre projetde dmonstration est une application web nomme gameoflife, consistitue de trois modules :gameoflife-core, gameoflife-services et gameoflife-web. Le module gameoflife-webgnre un fichier WAR incluant les JAR des deux autres modules. Le WAR est ce que nous voulonsdployer :

    tuatara:gameoflife johnsmart$ ls -ltotal 32drwxr-xr-x 16 johnsmart staff 544 16 May 09:58 gameoflife-coredrwxr-xr-x 8 johnsmart staff 272 4 May 18:12 gameoflife-deploydrwxr-xr-x 8 johnsmart staff 272 16 May 09:58 gameoflife-servicesdrwxr-xr-x 15 johnsmart staff 510 16 May 09:58 gameoflife-web-rw-r--r--@ 1 johnsmart staff 12182 4 May 18:07 pom.xml

    Prcdement dans ce chapitre, nous avons vu comment utiliser le plugin Deploy pour dployer unfichier WAR gnr par la tche de build courante vers un serveur d'application. Ce que nous voulonsmaintenant c'est dployer une version arbitraire du fichier WAR vers un serveur d'application.

    Dans Section 10.7.1, Gestion des releases Maven avec le plugin M2Release, nous avons discut decomment configurer Jenkins pour invoquer le plugin Maven Release afin de gnrer une version releaseformelle de l'application. La premire tape du dploiement dbute ici, nous supposerons donc que celaa t configur et que plusieurs versions releases ont dj t dployes sur notre gestionnaire de dptd'entreprise.

  • 355

    La prochaine tape implique de crer un projet ddi pour le processus de dploiement. Ce projet seraun projet Maven standard.

    La premire chose faire est de mettre en place un projet de dploiement ddi. Dans sa forme la plussimple, ce projet va simplement rcuprer la version requise de votre fichier WAR depuis le gestionnairede dpt pour le dployer avec Jenkins. Dans le fichier pom.xml qui suit, nous utilisons le modulemaven-war-plugin pour rcuprer la version spcifie du fichier WAR gameoflife-web. Cetteversion est spcifie dans la proprit target.version :

    4.0.0 com.wakaleo.gameoflife gameoflife-deploy-with-jenkins 0.0.1-SNAPSHOT war com.wakaleo.gameoflife gameoflife-web ward ${target.version} maven-war-plugin gameoflife com.wakaleo.gameoflife gameoflife-web RELEASE

    Ensuite, nous configurons un build Jenkins pour invoquer le fichier pom.xml en utilisant une valeur pourla proprit dfinie par l'utilisateur (voir Figure 12.11, Dployer un artefact depuis un dpt Maven).Notez que nous avons dfini la valeur par dfaut RELEASE pour qu'ainsi, par dfaut, la versionrelease la plus rcente soit dploye. Sinon, l'utilisateur peut fournir le numro de version de la version dployer ou redployer.

  • 356

    Figure 12.11. Dployer un artefact depuis un dpt Maven

    La suite de cette tche de build rcupre simplement le projet dployer et appelle le but mvn package,puis dploie le fichier WAR en utilisant le plugin Deploy (voir Figure 12.12, Prparer le WAR dployer). La proprit target.version sera automatiquement passe dans la tche de build etutilise pour dployer la bonne version.

    Figure 12.12. Prparer le WAR dployer

    Des techniques similaires peuvent tre utilises pour d'autres types de projet. Si vous dployez sur unserveur d'application non support par le plugin Deploy, vous avez aussi la possibilit d'crire un scriptspcifique dans le langage de votre choix et en faisant en sorte que Jenkins passe le numro de versiondemand comme dcrit plus haut.

    12.3.2. Dployer des applications base de scripts telles Ruby etPHP

    Dployer des projets utilisant des langages de script tels que PHP et Ruby est gnralement plus simpleque de dployer des applications Java, bien que les problmatiques lies aux mises jour de base dedonnes soient similaires. En effet, bien souvent ces dploiement impliquent essentiellement de copierdes fichiers vers un serveur distant. Pour obtenir les fichiers en premier lieu, vous avez le choix entre lescopiers depuis l'espace de travail d'une autre tche de build via l'option Copy Artifacts, ou de rcuprer

  • 357

    directement le code source depuis le dpt de code source, en utilisant au besoin une rvision spcifiqueou un tag comme dcrit pour Subversion dans Section 10.2.4, Construire partir d'un tag Subversionet pour Git dans Section 10.2.5, Raliser un build partir d'un tag Git. Une fois le code source prsentdans votre espace de travail Jenkins, vous n'avez simplement qu' le copier vers le serveur cible.

    Un outil utile pour ce type de dploiement est la srie de plugins Publish Over pour Jenkins (PublishOver FTP, Publish Over SSH, et Publish Over CIFS). Ces plugins fournissent une faon uniforme etflexible de dployer vos artefacts applicatifs vers d'autres serveurs via diffrents protocoles, incluantCIFS (pour les disques Windows partags), FTP, et SSH/SFTP.

    La configuration de chacun de ces plugins est similaire. Une fois les plugins installs, vous devez dfinirles configurations des htes, qui sont gres ensemble dans l'cran principal de configuration. Vouspouvez crer autant de configurations d'htes que dsir. Elles apparaitront dans une liste droulantedans la page de configuration de la tche.

    La configuration des htes a des libells explicites (voir Figure 12.13, Configurer un hte distant). Lenom apparatra dans la liste droulante des configurations de tches de build. Vous pouvez configurerune authentification FTP au moyen d'un identifiant et mot de passe, ou bien, pour le SSH, une clSSH ou un identifiant/mot de passe. Vous devez galement fournir un rpertoire existant sur le serveurdistant qui servira de rpertoire racine pour cette configuration. Dans les Options avances, vous pouvezgalement configurer le port SSH et la dure d'expiration.

    Figure 12.13. Configurer un hte distant

  • 358

    Une fois vos htes configurs, vous pouvez configurer vos tches de build afin qu'elles dploient desartefacts vers ces htes.Vous pouvez faire cela en tant qu'tape de build (voir Figure 12.14, Dployerdes fichiers vers un hte distant dans la section build) ou en tant qu'action faisant suite au build (voirFigure 12.15, Dployer des fichiers vers un hte distant depuis les actions ralises aprs le build).Dans les deux cas, les options sont similaires.

    Figure 12.14. Dployer des fichiers vers un hte distant dans la section build

    En premier lieu, vous devez slectionner l'hte cible depuis la liste des htes que vous avez configurdans la section prcdente. Ensuite, vous indiquez les fichiers que vous voulez transfrer. Cela se faiten dfinissant un ou plusieurs Transfer sets. Un Transfer set est un ensemble de fichiers (dfinis parune expression Ant) que vous dployez vers le dossier spcifi sur le serveur distant. Vous pouvezaussi fournir un prfix supprimer, cela vous permet de laisser de ct des dossiers non ncessairesque vous ne voulez pas voir apparatre sur le serveur (tel que le chemin target/site dans l'exemple).Vous pouvez ajouter autant d'emsenble de transfert que requis, de faon avoir les fichiers voulus surle serveur distant. Le plugin propose galement plusieurs options pour excuter des commandes sur leserveur distant une fois le transfert fini ou pour exclure certains fichiers ou applatir les dossiers.

  • 359

    Figure 12.15. Dployer des fichiers vers un hte distant depuis les actions ralises aprs le build

    12.4. ConclusionLe Dploiement Automatis, et ses formes plus avances, le Dploiement Continu ou la LivraisonContinue, peuvent tre considrs comme le point culminant d'une infrastructure moderne d'IntgrationContinue.

    Dans ce chapitre, nous avons vu plusieurs techniques de Dploiement Automatis, essentiellement axesautour de dploiements Java. Cependant, les principes gnraux discuts ici sont valables pour n'importequelle technologie. En effet, le processus de dploiement dans de nombreuses autres technologies,spcialement pour les langages de scripts tels Ruby et PHP, sont considrablement plus simple que leurquivalent Java, impliquant essentiellement de copier des fichiers vers le serveur de production. Rubybnficie aussi d'outils tels qu'Heroku et Capistrano pour aider accomplir cette tche.

    Il y a plusieurs aspects importants prendre en compte lors de la mise en place d'un DploiementAutomatis. En premier lieu, le Dploiement Automatis est le point final de votre architectured'Intgration Continue : vous devez dfinir un squenceur de build, de la compilation initiale et destests unitaires vers des tests fonctionnels et d'acceptation automatiss ainsi que des contrles de qualitdu code, culminant au dploiement vers une ou plusieurs plate formes. Le degr de confiance dansvotre squenceur de build dpend largement du degr de confiance que avez en vos tests. En d'autres

  • 360

    termes, plus les tests sont douteux et limits, le plus tt vous aurez recourir des tests manuels et une intervention humaine.

    Finallement, si possible, il est important de construire vos artefacts dployables en une fois seulement,et ensuite de les rutiliser dans les tapes suivantes, que ce soit pour les tests fonctionnels ou desdploiements vers diffrentes plateformes.

  • Chapter 13. Maintenir Jenkins13.1. Introduction Dans ce chapitre, nous allons discuter de quelques trucs et astuces que vous pourriez trouver utile lorsde la maintenance d'une instance Jenkins consquente. Nous regarderons des choses comme limiter etsurveiller l'espace disque, comment donner assez de mmoire Jenkins et comment archiver les tchesde build ou les migrer d'un serveur un autre. Certains de ces sujets sont abords ailleurs dans le livre,mais ici nous allons regarder ces lments du point de vue d'un administrateur systme.

    13.2. Surveillance de l'espace disqueL'historique des builds prend de l'espace disque. De plus, Jenkins analyse les builds prcdents lorsqu'ilcharge la configuration d'un projet. Ainsi, le chargement d'une tche avec un millier de builds archivsprendra bien plus de temps qu'une tche n'en n'ayant que 50. Si vous avez un gros serveur Jenkins avecdes dizaines ou des milliers de tches, le temps total est proportionellement multipli.

    La faon la plus simple de plafonner l'utilisation de l'espace disque est probablement de limiter le nombrede builds qu'un projet conserve dans son historique. Cela se configure en cochant la case "Supprimerles anciens builds" en haut de la page de configuration d'un projet (voir Figure 13.1, Suppression desanciens builds ). Si vous dites Jenkins de ne garder que les 20 derniers builds, il commencera effacer les plus vieux builds une fois ce nombre atteint. Vous pouvez limiter le nombre d'anciens buildsconservs par un nombre de builds ou par date (par exemple les builds de moins de 30 jours). Jenkinsfait cela intelligemment: il gardera toujours le dernier build russi au sein de son historique, ainsi vousne perdrez jamais votre dernier build russi.

    Figure 13.1. Suppression des anciens builds

    Le problme avec la suppresion des anciens builds est que vous perdez l'historique des builds parla mme occasion. Pourtant, Jenkins utilise cet historique pour raliser diffrents graphiques sur les

  • 362

    rsultats des tests et les mtriques de build. Limiter le nombre de build conserv 20, par exemple,implique que Jenkins affichera des graphiques contenant seulement 20 points. Cela peut tre un peulimit. Cette sorte d'information peut tre trs utile aux dveloppeurs. Il est souvent intressant depouvoir afficher l'volution des mtriques sur l'ensemble de la vie du projet, et pas seulement sur les2 dernires semaines.

    Heuresement, Jenkins a un mcanisme mme de rendre les dveloppeurs et les administraturs systmesheureux. En gnral, les lments prenant le plus de place sont les artefacts de build : fichiers JAR,WAR et ainsi de suite. L'historique de build en elle-mme est principalement constitue de fichiersde log XML, qui ne prennent pas trop de place. Si vous cliquez sur le button "Avanc...", Jenkinsvous offre la possibilit de supprimer les artefacts mais pas les donnes du build. Dans Figure 13.2,Supprimer les anciens builds options avances , par exemple, nous avons configur Jenkins pourqu'il garde les artefacts 7 jours au maximum. Cette option est vraiment pratique si vous avez besoinde limiter l'utilisation du disque tout en dsirant fournir l'ensemble des mtriques pour les quipes dedveloppement.

    Figure 13.2. Supprimer les anciens builds options avances

    N'hsitez pas tre drastique, en gardant un nombre maximal d'artefact assez faible. Souvenez vous queJenkins gardera toujours le dernier build stable et le dernier russi, quelque soit sa configuration. Ainsi,vous aurez toujours au moins le dernier build russi ( moins bien sr qu'il n'y ait pas encore eu de buildrussi). Jenkins offre galement de marquer un build particulier "Conserver ce build sans limite detemps", afin que certains builds importants ne puissent tre supprims automatiquement.

    13.2.1. Utiliser le plugin "Disk Usage"

    Le plugin Disk Usage est un des plus utiles pour un administrateur Jenkins. Ce plugin conserve etreporte l'espace disque utilis par vos projets. Il vous permet de reprer et corriger les projets qui utilisenttrop d'espace.

    Vous pouvez installer le plugin Disk Usage de la faon habituelle, depuis l'cran "Gestion des plugins".Aprs installation du plugin et redmarrage de Jenkins, le plugin Disk Usage enregistre la quantitd'espace disque utilise par chaque projet. Il ajoute galement un lien "Disk usage" sur la page

  • 363

    "Administrer Jenkins". Ce lien vous permet d'afficher la quantit totale d'espace utilis par vos projets(voir Figure 13.3, Voir l'utilisation d'espace disque ).

    Figure 13.3. Voir l'utilisation d'espace disque

    La liste est trie par utilisation totale d'espace disque, ainsi les projets utilisant le plus d'espaceapparaissent en haut. La liste fournit deux valeurs par projet. La colonne "Builds" indique l'espace disquetotal utilis par l'historique des builds, tandis que la colonne "Workspace" est l'espace disque utilispour construire le projet. Pour les projets en cours, l'espace utilis par l'espace de travail tend trerelativement stable, tandis que la valeur pour l'historique des builds croit au cours du temps, parfois une vitesse excessivement rapide, moins que vous ne fassiez quelque chose. Vous pouvez garder souscontrle l'espace disque utilis par l'historique d'un projet en limitant le nombre de builds conservs eten faisant attention quels artefacts sont conservs.

    Pour se faire une ide sur la vitesse laquelle l'espace disque est utilis, vous pouvez aussi afficherl'espace disque utilis par chaque projet au cours du temps. Pour faire cela, vous devez configurer leplugin sur la page "Configurer le systme" (voir Figure 13.4, Affichage de l'utilisation disque d'unprojet ).

    Figure 13.4. Affichage de l'utilisation disque d'un projet

    Cela va enregistrer et afficher combien d'espace disque vos projets consomment au cours du temps. Leplugin "Disk Usage" affiche un graphique de l'utlisation du disque au cours du temps (voir Figure 13.5,Affichage de l'espace disque d'un projet au cours du temps ) qui donne un bon aperu de la vitesse laquelle votre projet consomme l'espace disque, ou au contraire si l'espace utilis est stable au cours du temps.

  • 364

    Figure 13.5. Affichage de l'espace disque d'un projet au cours du temps

    13.2.2. Disk Usage et les projets Jenkins de type Apache Maven

    Si vous utilisez les tches de build Maven, il y a des dtails supplmentaires que vous devriez connatre.Dans Jenkins, les tches de build Maven archivent automatiquement, par dfaut, les artefacts du build.Cela peut tre diffrent de vos attentes.

    Le problme est que ces artefacts SNAPSHOT prennent de la place, beaucoup mme. Sur un projetactif, Jenkins est susceptible de raliser plusieurs builds par heure. Stocker de faon permanente chacundes fichiers JAR gnrs pour chaque build peut tre vraiment couteux. Le problme s'amplifie si vousavez des projets multimodules. En effet, Jenkins archive les artefacts gnrs pour chaque module.

    En fait, si vous avez besoin d'archiver vos artefacts SNAPSHOT Maven, il est probablement plusavis de les dployer directement dans votre gestionnaire de dpt local. Nexus Pro, par exemple,peut tre configur pour faire cela. Artifactory peut tre configur pour supprimer les vieux artefactsSNAPSHOT.

    Heuresement, vous pouvez configurer Jenkins pour raliser cela. Allez dans la section "Buid" de l'crande configuration de votre tche et cliquez sur le bouton "Avanc...". Des champs supplmentaires sontalors affichs, comme montr dans Figure 13.6, Tches de build Mavenoptions avances .

    Figure 13.6. Tches de build Mavenoptions avances

  • 365

    Si vous cochez l'option Dsactive l'archivage automatique des artefacts, Jenkins ne stockera pasles fichiers Jar gnr par les builds de votre projet. C'est une bonne faon de rendre heureux votreadministrateur systme.

    Notez que parfois vous avez vraiment besoin d'archiver les artefacts Maven. Par exemple, cela s'avresouvent utiles quand vous implmentez un squenceur de build (voir Section 10.7, Pipelines de buildet promotions ). Dans ce cas, vous pouvez toujours choisir, manuellement, les artefacts ncessaires, etalors utiliser l'option "Supprimer les anciens builds" pour dfinir la dure de conservation.

    13.3. Surveiller la charge serveur

    Jenkins inclut une surveillance des activits serveur. Sur l'cran "Administrer Jenkins", cliquez surl'icne "Statistiques d'utilisation". Cela affiche un graphique de la charge serveur au cours du tempspour le noeud matre (voir Figure 13.7, Statistiques de charge Jenkins ). Ce graphique contient troismtriques: nombre total d'excuteurs, nombre d'excuteurs occups et longueur de la queue.

    Le nombre total d'excuteurs (la ligne bleue) inclut les excuteurs sur les noeuds matre etesclaves. Ce chiffre peut varier quand les esclaves sont mis allums ou teints, et est un indicateur utilepour dterminer si la gestion dynamique des esclaves fonctionnent.

    Le nombre d'excuteurs occups (la ligne rouge) indique le nombre d'excuteurs en train deraliser des buids. Vous devriez vous assurer que vous avez une capacit suffisante en rserve afin desupporter les pics de builds. Si tous vos excuteurs sont occups de faon permanente, vous devriezajouter plus d'excuteurs et/ou de noeuds esclaves.

    La longueur de la queue (la ligne grise) est le nombre de tches de build attendant d'tre excutes.Les tches de build sont mises en attente lorsque tous les excuteurs sont occups. Cette mtrique n'inclutpas les tches en attente qu'un build en amont soit fini. Ainsi, elle donne une ide raisonnable du momento votre serveur pourrait bnficier de plus de capacits.

  • 366

    Figure 13.7. Statistiques de charge Jenkins

    Vous pouvez obtenir un graphique similaire pour les noeuds esclaves, en utilisant le bouton "Statistiquesd'utilisation" dans la page de dtails du noeud esclave.

    Une autre possibilit est d'installer le plugin Monitoring. Ce plugin utilise JavaMelody afin de raliserdes rapports HTML complets sur l'tat de votre serveur de build. Les rapports incluent la charge systmeet processeur, les temps moyen de rponse et l'utilisation de la mmoire (voir Figure 13.8, Le pluginJenkins Monitoring ). Une fois ce plugin install, vous pouvez accder aux graphiques JavaMelodydepuis la page "Administrer Jenkins", en utilisant les entres du menu "Monitoring of Hudson/Jenkinsmaster" ou "Hudson/Jenkins nodes".

  • 367

    Figure 13.8. Le plugin Jenkins Monitoring

    13.4. Sauvegarde de votre configuration

    Sauvegarder vos donnes est une pratique universellement recommande, et vos serveurs Jenkinsne devraient pas y faire exception. Par chance, sauvergarder Jenkins est relativement ais. Dans cettesection nous allons regarder plusieurs faons de raliser cela.

    13.4.1. Fondamentaux de la sauvegarde Jenkins

    Dans la plus simple des configurations, il suffit de sauvegarder priodiquement votre dossierJENKINS_HOME . Il contient la configuration de toutes vos tches de build, les configurations de vosnoeuds esclaves et l'historique des builds. La sauvegarde peut se faire pendant que Jenkins tourne. Il n'ya pas besoin de couper votre serveur pendant la sauvegarde.

    L'inconvnient de cette approche est que le dossier JENKINS_HOME peut contenir un volume trsimportant de donnes (voir Section 3.13, Whats in the Jenkins Home Directory ). Si cela devient unproblme, vous pouvez en gagner un peu en ne sauvegardant pas les dossiers suivants, qui contiennentdes donnes aisment recres la demande par Jenkins :

    $JENKINS_HOME/war

    Le fichier WAR eclat

  • 368

    $JENKINS_HOME/cache

    Outils tlchargs

    $JENKINS_HOME/tools

    Outils dcompresss

    Vous pouvez aussi tre slectif concernant ce que vous sauvegarder dans vos tches de build. Le dossier$JENKINS_HOME/jobs contient la configuration de la tche, l'historique des builds et les fichiersarchivs pour chacun de vos builds. La structure d'un dossier de tche de build est prsente dansFigure 13.9, Le dossier des builds .

    Figure 13.9. Le dossier des builds

    Pour savoir comment optimiser vos sauvegardes Jenkins, vous devez comprendre comment sontorganiss les dossiers de tche de build. Au sein du dossier jobs , il y a un dossier pour chaque tche debuild. Ce dossier contient deux dossiers : builds et workspace . Il n'y a pas besoin de sauvegarder ledossier workspace , vu qu'il sera simplement restaur via une simple rcupration si Jenkins constateson absence.

    Au contraire, le dossier builds requiert plus d'attention. Il contient l'historique de vos rsultats de buildet de vos artefacts gnrs prcdement, avec un dossier horodat pour chaque build prcdent. Si vous

  • 369

    n'tes pas intresss par la restauration de votre historique des builds ou d'anciens artefacts, vous n'avezpas besoin de sauver ce dossier. Si vous l'tes, continuez lire! Dans chacun de ces dossiers, voustrouverez l'historique des builds (stocks sous la forme de fichiers XML, par exemple les rsultats destests JUnit) et les artefacts archivs. Jenkins utilise les fichiers texte et XML pour raliser les graphiquesaffichs sur le tableau de bord des tche de build. Le dossier archive contient les fichiers binaires ayantt gnrs et stocks par les builds prcdents. Les binaires peuvent vous tre importants ou non, maisils peuvent prendre beaucoup de place. Aussi, si vous les excluez de vos sauvegardes, vous pourriezconomiser beaucoup d'espace.

    De mme qu'il est sage de raliser des sauvegardes frquentes, il est galement sage de tester votreprocdure de sauvegarde. Avec Jenkins, cela est facile faire. Les rpertoires racine de Jenkins sonttotalement portables, pour tester votre sauvegarde, il suffit donc de l'extraire dans un dossier temporaireet de lancer une instance Jenkins. Par exemple, imaginons que vous ayez extrait votre sauvegarde dans undossier temporaire nomm /tmp/jenkins-backup . Pour tester cette sauvegarde, assigner le chemindu dossier temporaire la variable JENKINS_HOME :

    $ export JENKINS_HOME=/tmp/jenkins-backup

    Puis dmarrer Jenkins sur un port diffrent et regardez s'il fonctionne :

    $ java -jar jenkins.war --httpPort=8888

    Vous pouvez maintenant voir Jenkins tourner sur ce port et vrifier que votre sauvegarde fonctionnecorrectement.

    13.4.2. Utilisation du Backup Plugin

    L'approche dcrite dans la section prcdente est suffisamment simple pour s'intgrer dans vosprocdures normales de sauvegardes, mais vous pourriez prfrer quelque chose de plus spcifique Jenkins. Le plugin Backup (voir Figure 13.10, Le plugin Jenkins Backup Manager ) fournit uneinterface utilisateur simple que vous pouvez utiliser pour sauvegarder et restaurer vos configurationset donnes Jenkins.

  • 370

    Figure 13.10. Le plugin Jenkins Backup Manager

    Ce plugin vous permet de configurer et de lancer des sauvegardes tant des configurations de vostches de build que de votre historique des builds. L'cran "Configuration" vous donne un importantcontrle sur les lments sauvegarder (voir Figure 13.11, Configurer Jenkins Backup Manager ).Vous pouvez choisir de seulement sauvegarder les fichiers XML de configuration, ou de sauvegarderavec l'historique des builds. Vous pouvez aussi choisir de sauvegarder (ou non) les artefacts Mavenautomatiquement gnrs (dans de nombreux processus de build, ces artefacts sont disponibles dansvotre Entreprise Repository Manager local). Vous pouvez aussi sauvegarder les espaces de travaildes tches (gnralement non ncessaire, comme discut plus haut) et toutes empreintes numriquesgnres.

    Figure 13.11. Configurer Jenkins Backup Manager

  • 371

    Vous pouvez dclencher une sauvegarde manuellement, depuis l'cran "Gestionnaire debackup" (accessible depuis l'cran "Administrer Jenkins"). La sauvegarde prend du temps et stoppeJenkins durant cette priode ( moins de dsactiver cette option dans la configuration de la sauvegarde).

    A l'heure o ces lignes sont crites, il n'est pas possible de planifier cette opration depuis Jenkins,mais vous pouvez dmarrer la sauvegarde en invoquant l'adresse correspondante (par exemple http://localhost:8080/backup/backup si votre instance Jenkins tourne localment sur le port 8080). Dans unenvironnement unix, par exemple, cela serait gnralement fait via une tche cron en utilisant un outiltel que wget ou curl pour dmarrer la sauvegarde.

    13.4.3. Des sauvegardes automatises plus lgres

    Si tout ce que vous voulez sauvegarder est votre configuration des tches de build, le plugin BackupManager peut tre considr excessif. Une autre option est d'utiliser le plugin "Thin Backup", qui permetde planifier des sauvegardes compltes et incrmentales de vos fichiers de configuration. Vu qu'ils nesauvegardent pas votre historique des builds ou vos artefacts, ces sauvegardes sont trs rapides et peuventainsi tre ralises sans stopper le serveur pour les raliser.

    Tout comme le plugin Backup, ce plugin ajoute une icne dans la page "Administrer Jenkins". De l,vous pouvez configurer et planifier les sauvegardes de votre configuration, dclencher une sauvegardeimmdiate ou restaurer une sauvegarde prcdente. La configuration est sans dtours (voir Figure 13.12,Configurer le plugin Thin Backup ). Elle implique simplement de configurer des sauvegardescompltes et incrmentales en utilisant une syntaxe similaire celle de cron et de fournir un dossier ostocker les sauvegardes.

    Figure 13.12. Configurer le plugin Thin Backup

    Pour restaurer une configuration prcdente, aller simplement la page "Restore" et choisissez la datede la configuration que vous voulez rappliquer (voir Figure 13.13, Restaurer une configiuratiopnprcdente ). Une fois la configuration prcdente restaure, vous devez recharger la configurationJenkins depuis le disque ou redmarrer Jenkins.

    http://localhost:8080/backup/backuphttp://localhost:8080/backup/backup

  • 372

    Figure 13.13. Restaurer une configiuratiopn prcdente

    13.5. Archiver les tches de buildUne autre faon d'aborder la problmatique de l'espace disque est de supprimer ou d'archiver lesprojets qui ne sont plus actifs. Archiver un projet vous permet de le restaurer aisment ultrieurementafin de consulter ses donnes ou artefacts. Archiver un projet est facile : il suffit de dplacer le rpertoirede celui-ci en dehors du rpertoire des tches. Bien sr, gnralement, le rpertoire de la tche est enpremier lieu compress dans un fichier ZIP ou une tarball.

    Dans l'exemple qui suit, nous voulons archiver le project tweeter-default . En premier lieu, nous nousrendons dans le rpertoire jobs de Jenkins et y crons une "tarball" (archive compresse) du rpertoiretweeter-default se trouvant dans le rpertoire des tches.

    $ cd $JENKINS_HOME/jobs $ ls gameoflife-default tweeter-default $ tar czf tweeter-default.tgz tweeter-default $ ls gameoflife-default tweeter-default tweeter-default.tgz

    Si le projet n'est pas en cours de construction par Jenkins, vous pouvez alors le supprimer en toutescurit et dplacer l'archive vers son lieu de stockage :

    $ rm -Rf tweeter-default $ mv tweeter-default.tgz /data/archives/jenkins

    Une fois cela ralis, vous pouvez tout simplement recharger la configuration depuis le disque dansl'cran "Administrer Jenkins" (voir Figure 13.14, Recharger la configuration partir du disque ). Leprojet archiv va dispairaitre instantanment de votre tableau de bord.

  • 373

    Figure 13.14. Recharger la configuration partir du disque

    Sur une machine Windows, vous pouvez faire exactement la mme chose en crant un fichier ZIP du rpertoire du projet.

    13.6. Migrer les tches de buildIl arrive que vous ayez dplacer ou copier des tches de build Jenkins d'une instance Jenkins une autre sans copier toute la configuration de Jenkins. Par exemple, vous pourriez migrer vos tchesde build vers une instance Jenkins sur une machine flambant neuve, avec une configuration systmediffrente de celle de la machine initiale. Ou vous pourriez tre en train de restaurer une vieille archivede tche de build.

    Comme nous l'avons vu, Jenkins stocke toutes les donnes ncessaires pour un projet au sein d'unsous-rpertoire du rpertoire jobs dans votre rpertoire racine de Jenkins. Ce sous-rpertoire est ais identifier il a le mme nom que votre projet. D'ailleurs, cela explique pourquoi vos noms de projetsne doivent pas contenir d'espaces, spcialement si Jenkins tourne sous Unix ou Linux cela rend lamaintenance et les tches d'administrtions bien plus aises si les noms de projet sont galement desfichiers Unix correctement nomms.

    Vous pouvez copier ou dplacer des tches de build entre instances de projets assez simplement encopiant ou dplaant les rpertoires des tches de build dans la nouvelle instance Jenkins. Le rpertoirede la tche du projet est autonome il contient tant la configuration complte du projet que sonhistorique des builds. Il est galement possible de copier des rpertoires de tches de build dans uneinstance Jenkins en cours de fonctionnement. Toutefois, si vous effacez galement ces rpertoires duserveur originel, vous devriez en premier stopper ce dernier. Vous n'avez mme pas besoin de redmarrerla nouvelle instance Jenkins pour voir le rsultat de votre import, allez simplement l'cran "AdministrerJenkins" et cliquez sur "Recharger la configuration partir du disque". Cela chargera les nouvellestches de build et les rendra immdiatement visible sur le tableau de bord Jenkins.

    Il y a quelques prcautions prendre toutefois. Si vous migrez vos tches vers une installation toutefrache de Jenkins, souvenez vous d'installer ou de migrer les plugins de votre prcdent serveur. Lesplugins se trouvent dans le rpertoire plugins , il suffit donc de simplement copier tout le contenu dece rpertoire dans le rpertoire correspondant votre nouvelle instance.

  • 374

    Bien sr, vous pourriez tre en train de migrer les tches de build vers une nouvelle instance prsicmentparce que la configuration des plugins est problmatique. Certains plugins peuvent parfois tre un peubogus, et vous pourriez vouloir une installation propre avec des plugins bien prcis. Dans ce cas, vouspourriez avoir retravailler certaines configurations de projets une fois ceux-ci imports.

    L'explication de cela est simple. Quand vous utilisez un plugin dans un projet, le fichier config.xml duprojet est mis jour avec des champs de configuration spcifiques au plugin. Si, pour quelques raisonsque ce soit, vous devez migrer des projets vers une installation Jenkins sans ces plugins, Jenkins necomprendra pas les parties correspondantes de la configuration de ces projets. La mme chose peutgalement arriver si les versions des plugins sont trs diffrentes et que le format des donnes deconfiguration a chang.

    Si vous migrez des tches vers une instance Jenkins avec une configuration diffrente, il est galementintressant de garder un oeil sur les logs systmes. Les configurations de plugin invalides sontgnralement visibles via des alertes ou des exceptions. Bien que non fatal, ces messages d'erreursindiquent souvent que le plugin ne fonctionnera pas comme attendu, voir pas du tout.

    Jenkins offre des fonctionnalits utiles pour vous aider migrer les configurations de vos projets. SiJenkins trouve des donnes qu'il considre invalides, il vous le fera savoir. Sur l'cran "AdministrerJenkins", vous aurez des messages comme celui dans Figure 13.15, Jenkins vous informe si vos donnesne sont pas compatibles avec la version actuelle .

    Figure 13.15. Jenkins vous informe si vos donnes ne sont pas compatibles avec la version actuelle

    Plusieurs options s'offrent alors vous. Vous pouvez laisser la configuration en l'tat, par exemple sivous souhaitez revenir une version prcdente de votre instance Jenkins. Vous pouvez aussi laisserJenkins ignorer les champs qu'il ne peut lire. Si vous retenez cette option, Jenkins affichera un cranavec plus de dtails sur l'erreur et il pourra mme, si vous le souhaitez, vous aider nettoyer votre fichierde configuration (voir Figure 13.16, Gestion de configuration prime ).

  • 375

    Figure 13.16. Gestion de configuration prime

    Cet cran donne plus de dtails sur le projet contenant les donnes primes ainsi que le messaged'erreur obtenu. Cela offre plusieurs possibilits. Si vous tes sr de ne plus avoir besoin du pluginayant originellement cr ces donnes, vous pouvez supprimer les champs fautifs en toute scurit encliquant sur le bouton "Discard Unreadable Data". Il est aussi possible que ces donnes appartiennent un plugin qui n'a pas encore t install sur cette instance Jenkins. Dans ce cas, installez le pluginet tout devrait aller bien. Enfin, vous pouvez toujours choisir de laisser les donnes redondantes et devivre avec le message d'erreur, au moins jusqu' ce que vous soyez sr de ne plus avoir migrer cesdonnes vers l'ancien serveur.

    Cependant, Jenkins ne dtecte pas toujours toutes les erreurs et inconsistences. Il est toujours utile degarder un oeil sur les fichiers de log lorsque que vous migrez vos tches de build. Par exemple, ce quisuit est un exemple rel d'un fichier de log Jenkins montrant ce qu'il peut arriver pendant une migration :

    Mar 16, 2010 2:05:06 PM hudson.util.CopyOnWriteList$ConverterImpl unmarshal WARNING: Failed to resolve class com.thoughtworks.xstream.mapper.CannotResolveClassException: hudson.plugins.cigame.GamePublisher : hudson.plugins.cigame.GamePublisher at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:68) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38) at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:71) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)

    Cette erreur nous informe que Jenkins ne peut trouver une classe appelehudson.plugins.cigame.GamePublisher . En fait, l'installation cible n'a pas le plugin "CIGame". Et dans ce cas (comme cela arrive parfois), aucun message d'alerte n'est apparu sur la page

  • 376

    "Administrer Jenkins". Par consquent, Jenkins n'a pas t capable de corriger le fichier de configurationpar lui mme.

    La solution la plus simple, dans ce cas, serait d'installer le plugin "CI Game". Mais que faire si on ne veutpas installer ce plugin? Nous pourrions laisser les fichiers de configuration en l'tat, mais cela pourraitcacher des erreurs plus importantes ultrieurement. Il serait mieux de les nettoyer.

    Dans ce cas, il faut inspecter et modifier les fichiers de configuration du projet la main. Sur cettemachine Unix, j'ai juste utilis grep pour trouver tous les fichiers de configuration contenant "cigame" :

    $ cd $JENKINS_HOME/jobs $ grep cigame */config.xml project-a/config.xml: project-b/config.xml: project-c/config.xml:

    Dans ces fichiers config.xml , j'ai trouv une rfrence au plugin CI Game dans la section , l o se trouve gnralement les configurations des plugins ralisant des rapports :

    ... ...

    Pour rsoudre le problme, il suffit de supprimer la ligne incrimine:

    ...

    ...

    L'emplacement prcis des donnes de configuration du plugin varie en fonction du plugin, mais engnral les fichiers config.xml sont relativement lisibles. Les mettre jour manuellement n'est pastrop compliqu.

    Au final, migrer des tches de build entre des instances Jenkins n'est pas si dur. Vous avez juste besoinde connaitre quelques astuces pour les cas particuliers, et, si vous savez o regarder, Jenkins fournit debeaux outils pour rendre le processus ais.

  • 377

    13.7. ConclusionDans ce chapitre, nous avons abord certains lments connaitre afin d'administrer votre serveurJenkins, notamment la surveillance de l'espace disque et de la charge du serveur, comment sauvegardervos tches de build et les fichiers de configuration, ainsi que comment migrer vos tches de build entoute scurit.

  • Appendix A. Automatiser vos testsunitaires et dintgrationA.1. Automatiser vos tests avec MavenMaven est un outil de build open source populaire dans le monde Java, qui fait usage de pratiques tellesque les dclarations de dpendances, les rpertoires et cycles de vie de build standards, et la conventionprfre la dclaration pour encourager des scripts de build propres, maintenables et de bonne qualit.Lautomatisation des tests est fortement prise en charge par Maven. Les projets Maven utilisent unestructure de dossiers standard : les tests unitaires seront automatiquement recherchs dans un dossiernomm (par dfaut) src/test/java. Il y a quelques petits rglages supplmentaires : en ajoutant justeune dpendance un (ou plusieurs) framework(s) de test utilis(s) par vos tests, Maven dtectera etexcutera automatiquement les tests JUnit, TestNG, ou mme Plain Old Java Objects (POJO) contenusdans cette structure de dossiers.

    Avec Maven, vous lancez vos tests unitaires en invocant la phase test du cycle de vie, comme prsentici :

    $ mvn test[INFO] Scanning for projects...[INFO] ------------------------------------------------------------------------[INFO] Building Tweeter domain model[INFO] task-segment: [test][INFO] ------------------------------------------------------------------------...------------------------------------------------------- T E S T S-------------------------------------------------------Running com.wakaleo.training.tweeter.domain.TagTestTests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.093 secRunning com.wakaleo.training.tweeter.domain.TweeterTestTests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 secRunning com.wakaleo.training.tweeter.domain.TweeterUserTestTests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 secRunning com.wakaleo.training.tweeter.domain.TweetFeeRangeTestTests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.051 secRunning com.wakaleo.training.tweeter.domain.HamcrestTestTests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec

    Results :

    Tests run: 38, Failures: 0, Errors: 0, Skipped: 0

    En plus dexcuter vos tests, et de mettre le build en chec ds quun test choue, Maven va produire unensemble de rapports de tests (encore, par dfaut) dans le dossier target/surefire-reports, dansles formats XML et texte. Pour nos objectifs dintgration continue, ce sont les fichiers XML qui nous

  • 380

    intressent puisque Jenkins est en mesure de comprendre et danalyser ces fichiers pour ses rapportsdintgration :

    $ ls target/surefire-reports/*.xmltarget/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.HamcrestTest.xmltarget/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TagTest.xmltarget/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweetFeeRangeTest.xmtarget/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterTest.xmltarget/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterUserTest.xml

    Maven dfinit deux phases de tests distinctes : les tests unitaires et les tests dintgration. Les testsunitaires doivent tre rapides et lger, en fournissant une quantit importante de retours de test enun minimum de temps. Les tests dintgration sont plus lents et lourds, et requirent souvent quelapplication soit construite et dploye sur un serveur (potentiellement embarqu) pour supporter destests plus complets. Ces deux types de tests sont importants, et pour un environnement dIntgrationContinue bien conu, il est ncessaire de bien les distinguer. Le build doit assurer que tous les testsunitaires sont lancs en premier - si un test unitaire choue, les dveloppeurs devraient en tre notifistrs rapidement. Le lancement des tests dintgration, lents et plus lourds, ne vaut le coup que si tousles tests unitaires passent.

    Avec Maven, les tests dintgration sont excuts pendant la phase integration-test du cycle de vie,que vous pouvez invoquer en lanant mvn integration-test ou (plus simplement) mvn verify.Pendant cette phase, il est facile de configurer Maven pour dmarrer votre application web sur un serveurJetty embarqu, ou pour packager et dployer votre application sur un serveur de test, par exemple.Vos tests dintgration peuvent ensuite tre excuts sur lapplication en marche. Cependant, la partiedlicate, est de dire Maven comment distinguer les tests unitaires des tests dintgration, afin quilsne soient excuts que si une version fonctionnelle de lapplication est disponible.

    Il y a plusieurs manires dy parvenir, mais au moment de lcriture il nexiste pas dapproche standardofficielle utilise travers tous les projets Maven. Une stratgie simple est dutiliser les conventions denommage : tous les tests dintgration peuvent se terminer par IntegrationTest, ou tre placs dans unpackage particulier. La classe suivante utilise une convention de la sorte :

    public class AccountIntegrationTest { @Test public void cashWithdrawalShouldDeductSumFromBalance() throws Exception { Account account = new Account(); account.makeDeposit(100); account.makeCashWithdraw(60); assertThat(account.getBalance(), is(40)); }}

    Avec Maven, les tests sont configurs via le plugin maven-surefire-plugin. Pour assurer queMaven lance ces tests seulement pendant la phase integration-test, vous pouvez configurer ceplugin comme prsent ici :

  • 381

    ... maven-surefire-plugin

    true

    unit-tests test test false **/*IntegrationTest.java

    integration-tests integration-test test false **/*IntegrationTest.java ...

    Saute tous les tests par dfaut ceci dsactive la configuration par dfaut des tests pour Maven. Pendant la phase des tests unitaires, lance les tests en excluant les tests dintgration. Pendant la phase des tests dintgration, lance les tests mais en incluant seulement les tests

    dintgration.

    Ceci assure que les tests dintgration seront ignors pendant la phase des tests unitaires, et excutsseulement pendant la phase des tests dintgration.

    Si vous ne voulez pas ajouter de contrainte non souhaite sur les noms de vos classes de test, vous pouvezutiliser les noms de package plutt. Dans le projet illustr dans Figure A.1, Un projet contenant desclasses de tests nommes librement, tous les tests fonctionnels ont t placs dans un package nommwebtests. Il ny a aucune contrainte sur les noms des tests, mais nous utilisons des Page Objects pour

  • 382

    modliser linterface de notre application, donc nous nous assurons aussi quaucune classe du packagepages ( lintrieur du package webtests) ne soit considr comme un test.

    Figure A.1. Un projet contenant des classes de tests nommes librement

    Avec Maven, nous pouvons faire cela avec la configuration suivante : maven-surefire-plugin true unit-tests test test false **/webtests/*.java integration-tests integration-test test

  • 383

    false **/webtests/*.java **/pages/*.java

    TestNG a actuellement un support plus flexible des groupes de test que JUnit. Si vous utilisez TestNG,vous pouvez identifier vos tests dintgration en utilisant les TestNG Groups. Avec TestNG, les classeset les mthodes de test peuvent tre tiquetes en utilisant lattribut groups de lannotation @Test,comme prsent ici :

    @Test(groups = { "integration-test" })public void cashWithdrawalShouldDeductSumFromBalance() throws Exception { Account account = new Account(); account.makeDeposit(100); account.makeCashWithdraw(60); assertThat(account.getBalance(), is(40));}

    En utilisant Maven, vous pouvez vous assurer que ces tests sont seulement lancs pendant la phase destests dintgration avec la configuration suivante :

    ... maven-surefire-plugin true unit-tests test test false

    integration-tests integration-tests integration-test

  • 384

    test false

    integration-tests ...

    Ne lance pas le groupe integration-tests pendant la phase test. Lance seulement les tests du groupe integration-tests pendant la phase integration-test.

    Il est souvent intressant de lancer les tests en parallle ds que possible, puisque cela peut acclrervos tests de faon significative (voir Section 6.9, A l'aide ! Mes tests sont trop lents !). Les tests enparallle sont particulirement efficaces avec des tests lents qui utilisent beaucoup daccs E/S, disqueou rseau (comme les tests web), ce qui est pratique, puisque ce sont prcisment les types de tests quenous voulons gnralement acclrer.

    TestNG propose un bon support des tests en parallle. Par exemple, avec TestNG, vous pouvezconfigurer vos mthodes de tests pour quelles se lancent en parallle sur dix threads concurrents commececi :

    org.apache.maven.plugins maven-surefire-plugin 2.5 methods 10

    Depuis JUnit 4.7, vous pouvez aussi lancer vos tests JUnit en parallle en utilisant une configurationsimilaire. En fait, la configuration prsente ci-dessus fonctionnera pour JUnit 4.7 et suivant.

    Vous pouvez aussi rgler le paramtre de configuration la valeur classes au lieu demethods, ce qui tentera de lancer les classes de test en parallle, plutt que pour chaque mthode. Celapeut tre plus ou moins rapide, en fonction du nombre de classes de test que vous avez, mais peut treplus sr pour certains cas de test non conus avec la concurrence lesprit.

    Les rsultats peuvent varier, donc vous feriez bien dexprimenter les nombres pour obtenir les meilleursrsultats.

    A.2. Automatiser vos tests avec AntMettre en place des tests automatiss avec Ant est aussi relativement facile, bien que cela requiert unpeu plus de plomberie quavec Maven. En particulier, Ant ne fournit pas directement les librairies JUnit

  • 385

    et les tches Ant adaptes, donc il faut les installer soi-mme quelque part. Lapproche la plus portableest dutiliser un outil de Gestion de dpendances tel quIvy, ou de placer les fichiers JAR correspondantsdans un rpertoire lintrieur de la structure de votre projet.

    Pour lancer les tests avec Ant, vous appelez la tche . Une configuration typique adapte Jenkins est prsente dans cet exemple :

    Nous devons mettre en place un classpath contenant les fichiers JAR junit et junit-ant, sansoublier les classes de lapplication et toute autre dpendance de lapplication pour la compilationet le lancement.

    Les tests en eux-mmes sont lancs ici. Loption haltonfailure est utilise pour faire chouerle build immdiatement ds quun test choue. Dans un environnement dIntgration Continue, cenest pas exactement ce quon veux, puisque nous devons galement avoir les rsultats des testssuivants. Nous avons donc positionn cette valeur no et utilis loption failureproperty pourforcer lchec du build ds que tous les tests sont termins.

    Le classpath doit contenir les librairies JUnit, les classes de votre application et leurs dpendances,et vos classes de test compiles.

    La tche Junit de Ant peut produire des rapports aux formats texte et XML, mais pour Jenkins,nous avons seulement besoin de ceux en XML.

    Loption fork lance vos test dans une JVM spare. Cest gnralement une bonne ide, puisquecela peut viter les problmes de type classloader lis des conflits avec les librairies propres

  • 386

    Ant. Nanmoins, le comportement par dfaut de la tche Junit de Ant est de crer une nouvelleJVM pour chaque test, ce qui ralentit significativement les tests. Loption perBatch est plusintressante, puisquelle cre une seule nouvelle JVM pour chaque batch de tests.

    Vous dfinissez les tests que vous voulez lancer au sein dun lment fileset. Cela permet unegrande souplesse, et rend simple la dfinition dautres objectifs pour diffrents sous-ensembles detests (intgration, web, et autres).

    Force lchec du build aprs la fin des tests, si lun dentre eux a chou.

    Si vous prfrez TestNG, Ant est videmment bien support galement. En utilisant TestNG pourlexemple prcdent, vous pourriez faire quelque chose comme ceci :

    TestNG est une librairie de test trs flexible, et la tche TestNG a beaucoup plus doptions que a. Parexemple, pour lancer seulement les tests dfinis comme faisant partie du groupe integration-test quenous avons vu prcdemment, nous pourrions faire a :

  • 387

    Ou pour lancer les tests en parallle, en utilisant quatre threads concurrents, vous pourriez faire a :

  • IndexAActive Directory, Microsoft, comme domaine descurit, 186administrateur

    pour la base de donnes utilisateurs interne deJenkins, 181pour la scurit base sur une matrice, 192

    agents de buildsurveillance, 332

    agents de constructionsconfigurer de multiples versions du JDK, 76

    agrger rsultats tests, 313-314Amazon EC2 plugin, 335Amazon Machine Image (AMI), 334Amazon Web Services (AWS), 334AMI (Amazon Machine Image), 334analyse (see mtriques de couverture de code;mtriques de qualit de code; tests)annuaire LDAP, comme domaine de scurit, 185-186Ant, 78-79

    automatiser les tests, 384-387code quality metrics

    with Checkstyle, 240configurer, 78-79dans les tapes de build Freestyle, 111-111installer, 79les variables d'environnement, accdesdepuis, 114mesures de qualit de code

    avec CodeNarc, 248avec FindBugs, 247avec PMD et CPD, 243

    mtriques de couverture de code avecCobertura, 156-158

    ANT_OPTS environment variable, 58Apache Maven

    versions SNAPSHOT, 90appareils mobiles, notifications vers , 229

    application autonomeexcuter Jenkins comme, 52-56

    application serverdeploying Jenkins to, 57-58upgrading Jenkins on, 68

    applications base de scripts, dployer vers unserveur d'application, 356-358applications Java

    dployer depuis un dpt Maven, 353-356dployer vers un serveur d'application, 346-356rapports de test de, 146redployer depuis un build prcdent, 349-353Redployer une version spcifique, 349

    applications JEE (see applications Java)applications PHP, dployer vers un serveurd'application, 356-358applications Ruby, 139-140, 356-358architecture matre/esclave pour les buildsdistribus, 319archiver les binaires d'artefact

    dployer vers un gestionnaire de dptd'entreprise, 127-131

    archiver les tches de build, 372-373archives d'artefact de binaire

    dsactiver, 125archives of binary artifacts, 27artefacts binaires

    rutiliser dans des pipelines de build, 301-305Artifactory

    Gestionnaire de dpt d'entreprise, 129, 130support de Jenkins pour, 5

    Artifactory plugin, 291artifacts (see artefacts binaires)Atlassian Crowd, en tant que domaine de scurit,188-189auditer les actions utilisateurs, 201-204autorisation, 179, 179

    (see also scurit)pas de restrictions sur, 180-181scurit base sur le projet, 196-198scurit base sur les rles, 198-200scurit base sur une matrice, 192-196

    AWS (Amazon Web Services), 334

  • 390

    BBackup plugin, 369backups, 67base de donnes, 180

    (see also scurit, domaines de scurit)base de donnes utilisateurs, 180, 181-184mettre jour avec le dploiement automatis,342-345revenir sur des changements pour, 346

    base de donnes utilisateurs, 180, 181-184BDD (Behavior-Driven Development), 143BDD (Behaviour Driven Development), 164binaire d'artefacts

    archiverdsactiver, 125dans les tches de build Freestyle, 118-121

    binaire d'artfactsarchiver

    dployer vers un gestionnaire de dptd'entreprise, 127-131

    binary artifactsarchiving, 27

    build historyin builds directory, 65-67details regarding, 31-33results summary for, 28, 31

    build jobsbinary artifacts from (see binary artifacts)build instable depuis

    notifications pour, 122code coverage metrics in (see code coveragemetrics)creating, 22-27failed

    example of, 29-33indicator for, 29, 31

    history of (see build history)Javadocs generation in, 34-35naming, 23reports resulting from (see reporting)scheduling (see build triggers)source code location for, 24

    status of, while running, 27steps in, adding, 26-27, 34, 37success of, indicator for, 29triggering manually, 27, 28types of, 23unstable build from

    indicator for, 38build triggers

    configuring, 25-26manual, 27, 28

    builds directory, 65-67builds distribus, 47, 319-320

    architecture matre/esclave pour, 319avec une ferme de build base sur le cloud, 333-337noeuds esclaves pour

    associer avec des tches de build, 330-332crer, 320dmarrer en mode headless, 329dmarrer en tant que service distant, 329dmarrer en utilisant SSH, 321-325installer comme service Windows, 328-328lancs avec Java Web Start, 325-328surveillance, 332

    builds instables, 147critre de, 256critre pour, 120, 161dclencher d'autre build aprs, 122dclencher une autre tche de build la suitede, 104notifications pour, 122, 205, 208

    builds quotidiens (see builds quotidiensautomatiss)builds quotidiens automatiss, 6

    CCAS (Central Authentication Service), 190Checkstyle, 239-242, 255clefs SSH, 12cls SSH, 92cloud computing, pour les builds, 176, 333-337cloud Eucalyptus, 334CloudBees (sponsor), xxix

  • 391

    Clover, 162-163Cobertura, 36-42, 153-162

    avec Ant, 156-158configuration dans vos tches de build, 158-161avec Maven, 153-156rapports de, 161-162

    code coverage metricswith Cobertura, 36-42

    CodeNarc, 248-249complexit du code, 258-259config.xml file, 65configuration, 18-22, 69-72

    Console de script, 71CVS, 80cran Configurer le systme, 72-73cran configurer systme, 70cran de configuration du rechargement partirdu disque, 70cran de gestion des plugins, 71cran Grer les nuds, 71cran Information Systme, 71cran Log systme, 71cran Prparer la fermeture, 72cran Statistiques d'utilisation, 71Git, 21-22JDK, 20, 74-76Maven, 19-20message systme sur la page d'accueil, 73notifications, 21outils de build, 77-79priode d'attente avant que le build ne dmarre,73proprits globales, 73-74proxy, 81-82serveur de messagerie, 80-81Subversion, 80systmes de gestion de version, 79-80

    configurerAnt, 78-79Maven, 77-78

    Console Jenkins, 16conteneur de Servlet

    en tant que domaine de scurit, 187

    conteneur de Servlet GlassFish, 187conteneur de Servlet Tomcat, 187conteneur de servlets

    excuter Jenkins de faon autonome enutilisant, 52

    contributeurs pour ce livre, xxviiconventions utilises dans ce livre, xxviCoverage Complexity Scatter Plot plugin, 258CPD, 243-246CppUnit, 144CPUs, les besoins d'un serveur de build en, 46Crowd, Atlassian, en tant que domaine de scurit,188CVS

    configurer, 80Jenkins supporting, 21retarder la construction d'un job, 86retarder les tches de build, 73scruter avec, 106

    Ddclencheurs de build

    pour les tches de build free-style, 103-108manuel, 108paramtrs, 276-278quand un autre build se termine, 104scruter le SCM pour des changements dans lecontrle de version, 105

    dclencheurs de buildsdclencher distance depuis le systme degestion de version, 106-108 intervalles rgulires, 104-105

    dclencheurs paramtrs, 276-278dpendances SNAPSHOT, 109, 124-124dploiement (see dploiement automatis;dploiement continu)dploiement automatis, 341-346

    vers un serveur d'application, 346-358mises jour de base de dones avec, 342-345revenir sur des changements dans, 345script de dploiement pour, 342tests fumigatoires pour, 345

    dploiement continu, 2, 7, 341-346

  • 392

    vers un serveur d'application, 346-358mises jour de base de dones avec, 342-345revenir sur des changements dans, 345script de dploiement pour, 342tests fumigatoires pour, 345

    dptcloner une copie locale de , 12

    dpt GitHubcompte, configuration, 11forker, 12-13

    Dpt GitHub, 98, 102dveloppement pilot par les tests, 6dveloppment pilot par les tests d'acceptance, 6disk space

    for build directory, 66documentation (see Javadocs)

    EEclipse

    mesures de qualit de code avec PMD, 243mtriques de la qualit du code avecCheckstyle, 240notificateurs de bureau avec, 223

    cran Administrer Jenkins, 69-72cran Configurer le systme, 72-73cran configurer systme, 70cran Console de script, 71cran de configuration du rechargement partir dudisque, 70cran de gestion des plugins, 71cran Grer les nuds, 71cran Information Systme, 71cran Log systme, 71cran Prparer la fermeture, 72cran Statistiques d'utilisation, 71EDI, mesures de qualit de code avec, 238email notifications, 21

    (see also notifications)espace disque

    surveillance, 361-365exemples de code, utilisation, xxxExtended Read Permission plugin, 198

    Ffichier WAR, installer Jenkins partir de , 17FindBugs, 246-248, 255fingerprints, 309, 314fingerprints directory, 63flux RSS, des rsultats de build, 211-212freestyle build jobs, 23

    build steps inMaven build steps, 26

    creating, 23-27Git used with

    post-build merging and pushing actions,100-102

    GGame of Life example application, 23-40Gerrit Trigger plugin, 99gestionnaire de dpt d'artefact, 127-131Git, 9

    adresse du dpt, 92auteur du commit, inclure dans le changelog, 96branches construire, 93, 97cls SSH, 92dclencheurs de build, 98-100espace de travail, effacer avant le build, 97exclure certaines rgions du dclenchement debuilds, 94exclure des utilisateurs du dclenchement debuilds, 95avec des tches de build free-style, 91-103fusionner avant le build, 96installation, 11localisation de l'espace de travail, ecraser, 96mise jour rcursive des sous-modules, 96navigateurs de code source pour, 98nettoyer aprs rcupration, 96post-build merging and pushing actions, 100-102rcuprer sur une branche locale, 95tags, excuter sur, 274-274tailler les branches distantes avant le build, 96

    Git plugin, 21-22

  • 393

    GitHub repository, 9Gmail, configurer, 81Goldin, Evgeny (contributeur), xxviiGradle

    code quality metricswith Checkstyle, 242

    construit dans, dmarrer avec Jenkins, 134-137mesures de qualit de code

    avec CodeNarc, 249support de Jenkins pour, 5

    Grailsconstruit dans, dmarrer dans Jenkins, 133-134mesures de qualit de code avec CodeNarc, 249

    Groeschke, Rene (contributeur), xxviiiGroovy scripts

    mesures de qualit de code avec CodeNarc,248-249script d'authentification, 191-191

    groupesActive Directory, 187Atlassian Crowd, 189LDAP, 186Unix, 187

    groupsActive Directory, 186

    HHibernate, mises jour de base de dones avec,343historique de build

    nombre de builds conserver, 85paramtr, 275permissions pour, 194

    historique des buildsutilisation disque de, 361-365

    home directory for Jenkins, 63-67hot-deploy, 346, 348Hudson, xxv, 3, 3, 5

    (see also Jenkins)

    IIC (Intgration Continue), 1-3, 5-7

    IM (see messagerie instantane)informations de contact pour ce livre, xxxiinstallation

    Ant, 79Git, 11JDK, 75Jenkins, 43-45

    from binary distribution, 44sur un serveur de build, 46-47sur CentOS, 50-51sur Debian, 49-50sur Fedora, 50-51with Java Web start, 14-16sur Linux, 44sur OpenSUSE, 51-52sur Redhat, 50-51sur SUSE, 51-52sur Ubuntu, 49-50sur Unix, 44 partir du fichier WAR, 17, 43Windows, 43, 44as Windows service, 59-62

    JRE, 10Maven, 19-20, 77plugins, 36, 36

    (see also specific plugins)upgrading, 67-68

    Intgration Continue (see IC)IRC (Internet Relay Chat), 219-222

    JJava Development Kit (see JDK)Java Runtime Environment (JRE), installation, 10Java Web Start

    installer et dmarrer Jenkins en utilisant, 14-16lancer des noeuds esclaves avec, 325-328

    JAVA_OPTS environment variable, 58Javadocs, 34-35JDK (Java Development Kit), 9

    configurer de multiples versions du, 74-76configuring, 20installer, 75pr-requis, 43

  • 394

    versions du, pour tches de buildmulticonfiguration, 281

    Jenkins, 3-4arrter, 16communaut de, 4configurer (see configuration)CVS supported by, 21cycle de livraisons rapide de, 5disponible sur le port, 45environment, requirements for, 9-13excuter

    dans un serveur d'application, 17depuis la ligne de commande, 17avec Java Web Start, 14comme une application autonome, 52-56

    excutionligne de commande, 45

    help icons in, 19historique, 3-4historique de, xxvhome directory for, 63-67installer (see installation)maintenance de, 361-376

    archiver les tches de build, 372-373migrer les tches de build, 373-376sauvegardes, 367-371Surveillance de l'espace disque, 361-365surveiller la charge serveur, 365-366

    maintenance ofbackups, 67

    mmoire requise pour, 46memory requirements for, 58-58comme un projet Open Source, 4page d'accueil pour, 17, 73port d'coute, 44pr-requis, 43raisons pour utiliser, 4rpertoire de travail de, 73rpertoire de travail pour, 48-49running

    on Apache server, 56-57on application server, 57-58

    systmes de gestion de version supports par,88upgrading, 67-68utilisateur ddi pour, 47version control systems supported by, 21, 24

    Jenkins M2 Extra Steps plugin, 132JMeter, 167-174jobs directory, 63-67jobs externes, contrler, 84joins, in build jobs, 295-296JRE (Java Runtime Environment), installation, 10JUnit reports

    configuring in freestyle build job, 27format for, 26

    KKawaguchi, Kohsuke (dveloppeur d'Hudson), 3

    Lla variable d'environnement BUILD_ID, 113la variable d'environnement BUILD_NUMBER,113la variable d'environnement BUILD_TAG, 113la variable d'environnement BUILD_URL, 114la variable d'environnement CVS_BRANCH, 114la variable d'environnementEXECUTOR_NUMBER, 113la variable d'environnement HUDSON_URL, 114la variable d'environnement JAVA_HOME, 113la variable d'environnement JOB_NAME, 113la variable d'environnement JOB_URL, 114la variable d'environnement NODE_LABELS,113la variable d'environnement NODE_NAME, 113la variable d'environnement SVN_REVISION,114la variable d'environnement WORKSPACE, 113LDAP/Active Directory, 5le plugin Checkstyle, 256le plugin FindBugs, 256le plugin Parameterized Build, 267le plugin Parameterized Trigger, 276

  • 395

    le plugin PMD, 256les archives de binaire d'artefacts

    dans les tches de build Freestyle, 118-121les builds instables

    critre pour, 253les projets Ruby on Rails, 343les scripts batch, 111-113Les scripts de build NAnt, 138les scripts Groovy

    dmarrer dans des tches de build, 115-117les variables d'environnement dans, 115

    les scripts shell, 111-113les tches de build

    build instablecritre pour, 120

    les mesures de qualit de code dans (see lesmesures de qualit de code)

    les tches de build free-stylemesures de qualit de code dans, avecViolations, 250-253

    les tches de build FreestyleActions la suite du build, 117-122

    les tches de build Mavenmesures de qualit de code intgrs, avecViolations, 253-255

    les variables d'environnement, 113(see also les variables d'environnementspcifiques)utilises dans les tapes de build, 113-115

    Linux, 49(see also plates-formes Linux spcifiques)upgrading Jenkins on, 67

    Liquibase, 343-345livraison continue, 2livraisons LTS (Long-Term Support), 3lmachine esclave

    pour les builds distribus, 319

    MM2Eclipse, 5machine virtuelle, pour serveur de build, 46, 176machines esclaves

    pour builds distribus , 47

    pour tches de build multiconfiguration, 280-281

    maintenance, 361-376archiver les tches de build, 372-373backups, 67migrer les tches de build, 373-376sauvegardes, 367-371Surveillance de l'espace disque, 361-365surveiller la charge serveur, 365-366

    Manage Jenkins screen, 18Maven, 9

    automatiser les tests, 379-384build steps in freestyle build jobs, 26, 109-111Cobertura avec, 153-156code quality metrics

    with Checkstyle, 241configurer, 77-78configuring, 19-20dpendances SNAPSHOT, 109, 124-124installer, 77installing, 19-20les variables d'environnement dans, 114mesures de qualit de code

    avec CodeNarc, 248avec FindBugs, 247

    mtriques de la qualit du codeavec PMD et CPD, 245

    numro de version pour, 298-301support d'Hudson pour, 5

    Maven build jobs, 23Maven Jenkins plugin, 286, 293Maven Release plugin, 298MAVEN_OPTS environment variable, 58McCullough, Matthew (contributeur), xxviimmoire, requise pour, 46memory, requirements for, 58-58messagerie instantane (IM), 214-219

    IRC pour, 219-222protocole Jabber pour, 214-219

    messages de commit, exclure du dclenchement detches de build, 90messages SMS, notifications via, 230-231mesures de qualit de code, 237-239, 258-259

  • 396

    avec Checkstyle, 239-242avec CodeNarc, 248-249avec CPD, 243-246avec FindBugs, 246-248, 255logiciel pour, 239avec PMD, 242-246avec Sonar, 238tches ouvertes, 259-260avec le plugin Violations, 249-255

    mesures de qualit du codedans les tches de build, 238avec Checkstyle, 255avec l'EDI, 238plugins pour, 238avec PMD, 255with Sonar, 261-264

    mtriques (see rapports)mtriques de couverture de code, 6, 152-163

    avec Clover, 162-163avec Cobertura, 153-162logiciels pour, 153

    mtriques de qualit de code, 6Microsoft Active Directory, comme domaine descurit, 186-187migrer les tches de build, 373-376mode headless, dmarrer des noeuds esclaves en,329MSTest plugin, 138

    NNAnt plugin, 139navigateurs de code source

    avec Git, 98avec Subversion, 89

    projets .NET, 137-138NetBeans, 224Nexus

    Gestionnaire de dpt d'entreprise, 130Gestionnaire de Dpts d'Entreprise, 301support d'Hudson pour, 5

    normes de codage, 237notificateurs de bureau, 223-229notifications, 205

    configuring, 21email, 183, 205-210flux RSS, 211-212depuis une tche de build Freestyle, 122-122messagerie instantane, 214-219messages SMS, 230-231vers les appareils mobiles, 229utilisant Nabaztag, 235notificateurs de bureau, 223-229notifications actives (push), 205parles, 234passive (pull), 205radars de build, 212-213vers les smartphones, 227-230sons dans, 232

    notifications actives (push), 205notifications email, 205-210notifications par email, 183, 210notifications passives (pull), 205Notifo, 227-229NTLM proxy authentication, 82numros de version, Maven, 298-301NUnit, 144

    OOdd-e (sponsor), xxxoutils de build, configurer, 77-79outils Sonatype, 4, 5

    Ppage d'accueil, 17, 73page de dmarrage (see page d'accueil)paramtre JAVA_ARGS, 50paramtre JENKINS_JAVA_CMD, 51paramtre JENKINS_JAVA_OPTIONS, 51paramtre JENKINS_PORT, 51paramtres Boolen, 271paramtres chanes, 268paramtres Fichier, 272paramtres Mot de passe, 271paramtres Run, 271performance

  • 397

    de l'analyse de la couverture de code, 152des applications, 167-174des tests, 149-150, 175-177

    priode d'attente avant que le build ne dmarre, 73priode d'attente avant que le build ne soit lanc,86permissions (see autorisation)permissions de niveau projet, dans la scuritbase sur les rles, 199PHPUnit, 144pipelines (see pipelines de build)pipelines de build, 298-317

    agrger les rsultats de tests d'un, 313-314numros de versions Maven pour, 298-301pipelines de dploiement, 314-317promotions dans, 298, 305-313rutiliser des artefacts dans, 301-305

    pipelines de dploiement, 314-317plugin Audit Trail, 201-202plugin Build Pipeline, 314plugin Build Promotion, 347plugin Clover, 163plugin Cobertura, 158plugin Copy Artifact, 302, 347, 349plugin Dependency Graph View, 294plugin Deploy, 346, 347-349, 349plugin Deploy Websphere, 346, 347plugin Disk Usage, 362-363plugin DocLinks, 166plugin Eclipse, 223plugin Email-ext, 207-210plugin Git, 91-92Plugin GitHub, 102plugin HTML Publisher, 165-166plugin Instant Messaging, 214plugin IRC, 219, 220plugin Jabber Notifier, 214plugin JobConfigHistory, 202-204plugin Locks and Latches, 297plugin MSBuild, 137plugin Nabaztag, 235plugin Parameterized Trigger, 290, 349plugin Promoted Builds, 305

    plugin Role Strategy, 198plugin Script Security Realm, 190-191plugin Sounds, 232plugin Speaks, 234plugin Thin Backup, 371plugin Tray Application, 226-227plugin Violations , 249-255plugin xUnit, 146plugins

    Active Directory, 186Amazon EC2, 335architecture de, Jenkins compar Hudson, 5Artifactory, 129, 291Audit Trail, 201-202Backup, 369Build Pipeline, 314Build Promotion, 347CAS, 190Checkstyle, 256Clover, 163Cobertura, 158Copy Artifact, 302, 347, 349Coverage Complexity Scatter Plot, 258Crowd, pour Atlassian Crowd, 188Dependency Graph View, 294Deploy, 346, 347-349, 349Deploy Websphere, 346, 347Disk Usage, 362-363DocLinks, 166Eclipse, 223Email-ext, 207-210Extended Read Permission, 198FindBugs, 256Gerrit Trigger, 99gestion, 71Git, 21-22, 91-92GitHub, 102HTML Publisher, 165-166installing, 36-37IRC, 219, 220Jabber Notifier, 214Jenkins M2 Extra Steps, 132JobConfigHistory, 202-204

  • 398

    Locks and Latches, 297Maven Jenkins, 286, 293Maven Release, 298messagerie instantane, 214MSBuild, 137MSTest, 138Nabaztag, 235NAnt, 139Parameterized Build, 267Parameterized Trigger, 276, 290, 349plugin Tray Application, 226-227PMD, 256Promoted Builds, 305Publish Over, 357Role Strategy, 198Script Security Realm, 190SFEE, 190Sounds, 232Speaks, 234Task Scanners, 259Thin Backup, 371upgrading, 68Violations, 249-255xUnit, 146

    plugins directory, 63plugins Publish Over, 357PMD, 242-246, 255polices utilises dans ce livre, xxviprocesseurs, les besoins d'un serveur de build en,46projet Github, 4projets Ruby on Rails, 139-140promotions, 298, 305-313proprits

    globales, 73-74paramtres de build comme, 270

    proprits globales, 73-74protocole Jabber, 214-219proxy, configurer, 81-82

    Rradars d'informations, 212-213radars de build, 212-213

    radars, informations, 212-213rapport

    les rsultats de testles rapports JUnit, 117-118

    mesures de qualit de codeavec Checkstyle, 255tches ouvertes, 259-260

    rapportermtriques de couverture de code

    de Cobertura, 161-162rsultats de test

    afficher, 147-150configurer, 145-146dans les flux RSS, 211-212

    rapportsmesures de qualit de code

    avec PMD, 255mesures de qualit du code

    avec FindBugs, 255mtriques de couverture de code, 6

    de Clover, 163mtriques de qualit de code, 6rsultats de test d'acceptation, 164-166rsultats de test de performance, 172-174

    rapports JUnit, 144pour tests d'acceptation, 164configurer dans une tache de build free-style,146

    rpertoire de travail de Jenkins, 73rpertoire de travail pour Jenkins, 48-49reporting

    code coverage metrics, 36-42Javadocs API documentation, 34-35mesures de qualit de code

    plugin Violations pour , 249-255rsultats de test

    agrger, 313-314test results, 31-33

    JUnit reports, 26revendiquer des builds chous, 210

    Ssauvegardes, 367-371

  • 399

    sauvegardes plus lgres, 371SCM (Gestion du Code Source), 88-103SCM (Source Code Management), 24

    (see also version control systems)script de dploiement, 342scripts, 111

    (see also Ant; Maven)les langages supportes, 117les scripts batch, 111-113les scripts Groovy, 115-117les scripts shell, 111-113paramtrs, 269-270script de dploiement, 342scripts batch, 79scripts d'authentification personnaliss, 190scripts shell, 79

    scripts batch, 79scripts de build (see scripts)scripts Groovy

    fonctionnant dans la console de script, 71scripts shell, 79securit, 179-181

    activer, 179autorisation, 179

    pas de restrictions sur, 180-181domaine de scurit, 179

    scuritautorisation

    scurit base sur le projet, 196-198scurit base sur les rles, 198-200scurit base sur une matrice, 192-196

    domaine de scuritAtlassian Crowd, 188-189

    domaines de scuritactiver l'enregistrement utilisateur, 183activer les connexions, 180annuaire LDAP, 185-186base de donnes utilisateurs interne Jenkins, 180, 181-184CAS, 190conteneur de Servlet, 187Microsoft Active Directory, 186-187personnaliser, 190-191

    SFEE, 190utilisateurs et groupes Unix, 187

    scurit base sur le projet, 196-198scurit base sur les rles, 198-200scurit base sur une matrice, 192-196serveur d'application

    dploiement automatis vers, 346-358applications base de scripts, 356-358applications Java, 346-356

    dployer Jenkins dans, 17serveur d'application GlassFish, dployer desapplications Java vers, 346-356serveur d'application JBoss, dployer desapplications Java vers, 346-356serveur d'application Tomcat

    dployer des applications Java vers, 346-356dployer Jenkins en utilisant, 17

    serveur de build, 5besoins en processeur pour, 46installation de Jenkins sur, 46-47machine virtuelle pour, 46, 176mmoire requise pour, 46mise jour, 175multiples, excution des builds sur (see buildsdistribus)surveiller la charge du, 365-366

    serveur de messagerie lectronique, configurer,80-81, 80-81serveur proxy HTTP, 81service de cloud computing Amazon EC2, 333-337service distant, dmarrer des noeuds esclaves entant que, 329services services

    dmarrer des noeuds esclaves en tant que, 329services Windows

    installer des noeuds esclaves comme, 328-328SFEE (Source Forge Enterprise Edition), 190smartphones, notifications vers, 227-229Sonar

    frquence des builds, 104les mesures de qualit de code avec, 261-264mesures de qualit de code avec, 238

  • 400

    sons, dans les notifications, 232Source Code Management (see SCM; versioncontrol systems)Source Forge Enterprise Edition (see SFEE)sponsors pour ce livre, xxixSSH, dmarrer un noeud esclave en utilisant, 321-325stand-alone application

    upgrading Jenkins as, 67Subversion

    configurer, 80exclure des messages de commit dudclenchement de builds, 90exclure des rgions du dclenchement debuilds, 90exclure des utilisateurs du dclenchement debuilds, 90avec les tches de build free-style, 88-91Jenkins supporting, 21navigateurs de code source pour, 89tags, build partir de, 273-273

    systmes de contrle de versiondclencher des builds distance depuis, 106-108scruter les changements pour dclencher unbuild, 105

    systmes de gestion de version, 79(see also CVS; Git; Subversion)configurer, 79-80support par Jenkins, 88supports par Jenkins, 79-80

    Ttche de build

    build instable denotifications pour, 208

    build instable depuisdclencher d'autre build aprs, 122

    tche de build free-styledescription de, pour la page de dmarrage duprojet, 85

    tche de build multiconfiguration, 279-285tches cron (see jobs externes)

    tches de buidbuild instable de, 147

    tches de build, 83, 83(see also tches de build free-style; tches debuild Apache Maven)archiver, 372-373axe JDK pour, 281build instable de

    critre pour, 161dclencher un autre build la suite de, 104notifications pour, 205

    build instable depuiscritre de, 256critre pour, 253

    copier, 84crer, 83-84dclencher manuellement, 108dpendances entre, 294distribues parmi des serveurs de build, 319-320

    crer des noeuds esclaves, 320dmarrer des noeuds esclaves, 321

    distribues sur des serveurs de buildferme de build base sur le cloud pour, 333-337

    distribues sur les serveurs de buildassocier les noeuds esclaves aux tches,330-332

    distribus sur les serveurs de buildsurveillance de noeuds esclaves, 332

    chouesdtails propos de, 147-149notifications pour, 205, 208revendiquer, 210

    excution en parallle, 293-297externe, contrler, 84jonctions dans, 295-296migrer, 373-376multiconfiguration, 279-285

    axe esclave pour, 280-281axe JDK pour, 281axe personnalis pour, 282crer, 279-280

  • 401

    excuter, 282-285filtre de combinaison pour, 283matrice de configuration, 283

    numro d'excution pour, en tant queparamtres, 271parametr

    types de paramtres, 268paramtres, 267-275

    crer, 267dmarres distance, 275-275excutes sur un tag Git, 274-274excutes sur un tag subversion, 273-273historique de, 275tches de build paramtres, 269-270types des paramtres, 271-272

    proprits globales pour, 73-74retarder le dmarrage, 73serveurs de build distribu parmi

    architecture matre/esclave pour, 319tests dans (see tests)types de, 83verrouiller les ressources pour, 297-297

    tches de build Apache Maven, 83tches de build free-style, 83, 84-88

    Actions la suite du build, 145bloquer pour un projet en amont, 86dclencheurs de build pour, 103-108dsactiver, 86choues, 148espace de travail pour, surcharger, 87Git utilis avec, 91-103

    adresse du dpt, 92auteur du commit, inclure dans le changelog,96branches construire, 93, 97cls SSH, 92dclencheurs de build, 98-100espace de travail, effacer avant le build, 97exclure certaines rgions du dclenchement,94exclure des utilisateurs du dclenchement,95excutable Git, spcifier, 97

    fusionner avant le build, 96localisation de l'espace de travail, ecraser, 96mise jour rcursive des sous-modules, 96navigateurs de code source pour, 98nettoyer aprs rcupration, 96rcuprer sur une branche locale, 95tailler les branches distantes avant le build,96

    historique de build pour, nombre de builds conserver, 85nommage, 85priode d'attente, 86rapport sur des rsultats de test, 145Subversion utilis avec, 88-91

    exclure des messages de commit dudclenchement, 90exclure des rgions du dclenchement, 90exclure des utilisateurs du dclenchement,90navigateurs de code source pour, 89

    tches de build FreestyleArchiver les binaires d'artefacts, 118-121dmarrer, 123dmarrer d'autres tches de build depuis, 122les tapes de build dans, 108-117

    Les tapes de build Maven, 109-111les scripts batch, 111-113Les scripts de build Ant, 111-111les scripts Groovy, 115-117les scripts shell, 111-113les variables d'environnement dans, 113-115

    Les scripts de build NAnt dans, 138projets .NET dans, 137-138notifications envoyes aprs, 122-122projets Gradle dans, 134-137projets Grails dans, 133-134projets Ruby et Ruby on Rails dans, 139-140rapport sur les rsultats de test, 117-118

    tches de build freestylegnrer automatiquement, 293

    tches de build matrix (see tches de build multi-configuration)tches de build Maven, 123-132

  • 402

    Actions la suite du build, 126archiver les binaires d'artefact, dsactiver, 125builds incrmentals, 125crer, 123dmarrer des modules en parralle, 126dployer les artefacts vers un gestionnaire dedpt d'artefact, 127-131dpt priv pour, 126gnrer automatiquement, 285-293

    configurer, 286-288les tapes de build dans, 124, 132modules for, managing, 131rapport sur des rsultats de test, 145rsultats de test de, 147utilisation du disque des, 364-365

    Tches de build Mavengnrer automatiquement

    Artifactory plugin avec, 291hritage de configuration, 288-290plugin Parameterized Trigger avec, 290

    tches de build multi-configuration, 84tches de build multiconfiguration

    axe esclave pour, 280-281axe personnalis, 282crer, 279-280excuter, 282-285filtre de combinaison pour, 283matrice de configuration, 283

    tches de build paramtr, 279(see also tches de build multiconfiguration)

    tches de build paramtres, 267-275crer, 267dmarrage distance, 275-275excutes sur un tag Git, 274-274excutes sur un tag Subversion, 273-273historique de, 275scripts de build pour, 269-270types de paramtres, 268types des paramtres, 271-272

    tches ouvertes, rapport sur , 259-260Task Scanners plugin, 259TDD (Test Driven Development), 143Test Result Trend graph, 32

    Test::Unit, 144TestNG, 144, 146, 151tests

    automatisation, 6automatiser, 6

    avec Ant, 384-387avec Maven, 379-384

    automatiss, 143-145dveloppement pilot par les tests, 6dans des tches de build free-style, 145ignorer, 150-152dans des tches de build Maven, 145performance de, 149-150, 175-177rapport de

    agrgation, 313-314rapports de

    afficher, 147-150configurer, 145-146

    rapports depuisles rapports JUnit, 117-118

    reports from, 31-33JUnit reports, 26

    tests d'acceptance, 6tests d'acceptation, 143, 164-166tests d'intgration, 143, 144tests de performance, 167-174tests fonctionnels (rgression), 144tests fonctionnels (regression), 144tests fumigatoires, 345tests unitaires, 143, 144tests web, 144, 144

    tests automatiss (see tests)tests d'acceptance tests, automatiss, 6tests d'acceptation, automatis, 143tests d'acceptation, automatiss, 164-166tests d'intgration, 143, 144

    nombre de, 176performance de, 175

    tests de rgression (see tests fonctionnels(rgression))tests fonctionnels (rgression), 144

    excution en parallle, 176nombre de, 176

  • 403

    performance de, 175tests fonctionnels (regression), 144tests fumigatoires, 345tests unitaires, 143, 144tests web, 144, 144

    UUbuntu Enterprise Cloud, 335Unix, 44

    (see also plates-formes Unix spcifiques)utilisateurs et groupes, en tant que domaine descurit, 187

    unstable buildsindicator for, 38

    updates directory, 63upgrades, 67-68userContent directory, 63users directory, 64utilisateurs

    administrateurpour la base de donnes utilisateurs internede Jenkins, 181pour la scurit base sur une matrice, 192

    auditer les actions des, 201-204autorisation pour (see autorisation)exclure du dclenchement de builds, 95exclure pour le dclenchement de build, 90pour Jenkins, sur un serveur de build, 47revendiquer des builds chous, 210

    Vvariable d'environnement HUDSON_HOME, 48variable d'environnement JAVA_HOME, 75variable d'environnement JENKINS_HOME, 48-49, 73variable d'environnement P, 190variable d'environnement U, 190variables d'environnement

    paramtres de build comme, 269verrouiller des ressources pour des tches de build,297-297version control systems, 9

    configuring, 24versions SNAPSHOT, 90Visual Studio MSBuild, 137-138votre version de Java , 43

    WWakaleo Consulting (sponsor), xxixwar directory, 64WebSphere Application Server, 346, 347Windows

    package d'installation de Jenkins , 43Windows services

    installing Jenkins as, 59-62WMI (Windows Management Instrumentation),329workspace directory, 65

    XXML format for test reports (see JUnit reports)Xu, Juven (contributeur), xxviiixUnit, 144, 146

  • ColophonLanimal sur la couverture de Jenkins : Le guide complet est une grenouille faux-grillon orne(Pseudacris ornata). On peut trouver ces petits amphibiens, de seulement 2,5 3,5 centimtres de long,sur les plaines ctires dAmrique du Nord de la Caroline du Nord jusquau milieu de la Floride etdans lest de la Louisiane. Ils prfrent les zones deau peu profonde sans vgtation dense, telles queles mares, les fosss de bord de route, et les prs inonds.

    La couleur des grenouilles faux-grillons ornes varie en fonction des endroits, et les individus peuventtre principalement noir, blanc, marron, rouge, vert, ou toute autre variation proche. Quand bien mme,tous les spcimens, possdent une bande sombre ou un ensemble de taches allant des narines jusquenhaut du dos en passant par loeil, et la plupart possdent aussi dautres taches ou bandes. Les espcesse reproduisent de novembre mars, et lappel des mles peut tre entendu dans ou proximit deszones deau peu profondes.

    Les grenouilles faux-grillons ornes doivent galement leur nom au son de leur champ nuptial :Pseudacris vient du grec ancien signifiant faux grillon. Ce nom fut donn en 1836 par le naturalisteamricain John Edwards Holbrook aprs quil ait observ que le son aigu ressemblait celui produitpar ce non moins clbre insecte.

    Limage de couverture est tire de louvrage Cassells Natural History. La police dcriture dela couverture est Adobe ITC Garamond. La police utilise pour le texte est Linotype Birka ; lapolice des titres est Adobe Myriad Condensed ; et la police utilise pour le code est LucasFontsTheSansMonoCondensed.

  • Jenkins : Le guide completTable of ContentsCopyrightAvant-proposPrface1.Audience2.Organisation du livre3.Jenkins ou Hudson?4.Conventions sur les polices5.Conventions de ligne de commande6.Contributeurs6.1.Les traducteurs du prsent livre en franais

    7.L'quipe de revue8.Sponsors du livre8.1.Wakaleo Consulting8.2.CloudBees8.3.Odd-e

    9.Utilisation des exemples de code10.Safari Books Online11.Comment nous contacter12.Remerciements

    Chapter1.Introduction Jenkins1.1.Introduction1.2.Les fondamentaux de l'Intgration Continue1.3.Introduction Jenkins (n Hudson)1.4.De Hudson Jenkins Un rapide historique1.5.Dois-je utiliser Jenkins ou Hudson?1.6.Mettre en place l'Intgration Continue au sein de votre organisation1.6.1.Phase 1 Pas de serveur de build1.6.2.Phase 2 Builds quotidiens1.6.3.Phase 3 Builds quotidiens et tests automatiss basiques1.6.4.Phase 4 Arrive des mtriques1.6.5.Phase 5 Prendre les tests au srieux1.6.6.Phase 6 Tests d'acceptance automatiss et un dploiement plus automatis1.6.7.Phase 7 Dploiement Continu

    1.7.Et maintenant ?

    Chapter2.Vos premiers pas avec Jenkins2.1.Introduction2.2.Prparation de votre environnement2.2.1.Installation de Java2.2.2.Installation de Git2.2.3.Configurer un compte GitHub2.2.4.Configurer les clefs SSH2.2.5.Forker le dpt des exemples

    2.3.Dmarrer Jenkins2.4.Configuring the Tools2.4.1.Configuring Your Maven Setup2.4.2.Configuring the JDK2.4.3.Notification2.4.4.Setting Up Git

    2.5.Your First Jenkins Build Job2.6.Your First Build Job in Action2.7.More ReportingDisplaying Javadocs2.8.Adding Code Coverage and Other Metrics2.9.Conclusion

    Chapter3.Installer Jenkins3.1.Introduction3.2.Tlcharger et installer Jenkins3.3.Prparation d'un serveur de build pour Jenkins3.4.Le rpertoire de travail de Jenkins3.5.Installer Jenkins sur Debian ou Ubuntu3.6.Installer Jenkins sur Redhat, Fedora ou CentOS3.7.Installer Jenkins sur SUSE ou OpenSUSE3.8.Excuter Jenkins comme une application autonome3.9.Running Jenkins Behind an Apache Server3.10.Running Jenkins on an Application Server3.11.Memory Considerations3.12.Installing Jenkins as a Windows Service3.13.Whats in the Jenkins Home Directory3.14.Backing Up Your Jenkins Data3.15.Upgrading Your Jenkins Installation3.16.Conclusion

    Chapter4.Configurer votre serveur Jenkins4.1.Introduction4.2.Le tableau de bord de configuration L'cran Administrer Jenkins4.3.Configurer l'environnement systme4.4.Configurer les proprits globales4.5.Configurer vos JDKs4.6.Configurer vos outils de build4.6.1.Maven4.6.2.Ant4.6.3.Langage de scripts Shell

    4.7.Configurer vos outils de gestion de version4.7.1.Configurer Subversion4.7.2.Configurer CVS

    4.8.Configurer le serveur de messagerie lectronique4.9.Configurer un Proxy4.10.Conclusion

    Chapter5.Configurer vos tches de Build5.1.Introduction5.2.Tches de Build Jenkins5.3.Crer une tche de build free-style5.3.1.Options Gnrales5.3.2.Options avances du projet

    5.4.Configurer la Gestion du Code Source5.4.1.Travailler avec Subversion5.4.2.Travailler avec Git5.4.2.1.Installation du plugin5.4.2.1.1.Configuration systme du plugin5.4.2.1.2.Configuration de la cl SSH

    5.4.2.2.Utilisation du plugin5.4.2.2.1.Configuration avance par projet de la gestion du code source5.4.2.2.2.Branches construire5.4.2.2.3.Rgions exclues5.4.2.2.4.Utilisateurs Exclus5.4.2.2.5.Rcuprer/fusionner sur une branche locale5.4.2.2.6.Dpt dans un sous-rpertoire local5.4.2.2.7.Fusionner avant le build5.4.2.2.8.Tailler les branches distantes avant le build5.4.2.2.9.Nettoyer aprs rcupration5.4.2.2.10.Mise jour rcursive des sous-modules5.4.2.2.11.Utiliser l'auteur du commit dans changelog5.4.2.2.12.Effacer l'espace de travail5.4.2.2.13.Choix de la stratgie5.4.2.2.14.Excutable Git5.4.2.2.15.Navigateur de dpt

    5.4.2.3.Dclencheurs de build5.4.2.3.1.Dclenchement par Gerrit

    5.4.2.4.Actions post-build5.4.2.4.1.Pousser seulement si le build est russi5.4.2.4.2.Fusionner les rsultats5.4.2.4.3.tiquettes5.4.2.4.4.Branches

    5.4.2.5.Plugin GitHub

    5.5.Dclencheurs de build5.5.1.Dclencher une tche de build lorsqu'une autre tche de build se termine5.5.2.Tches de build priodiques5.5.3.Scruter le SCM5.5.4.Dclencher des builds distance5.5.5.Construction manuelle de tches

    5.6.Les tapes de builds5.6.1.Les tapes de build Maven5.6.2.Les tapes de build Ant5.6.3.Excuter une commande Batch Shell ou Windows5.6.4.Utiliser les variables denvironnement Jenkins dans vos builds5.6.5.Excuter des scripts Groovy5.6.6.Construire des projets dans dautres langages

    5.7.Les actions la suite du build5.7.1.Rapport sur les rsultats de tests5.7.2.Archiver les rsultats de build5.7.3.Notifications5.7.4.Construire dautres projets

    5.8.Dmarrer votre nouvelle tche de build5.9.Travailler avec des tches de build Maven5.9.1.Construire ds lors quune dpendance SNAPSHOT est construite5.9.2.Configurer un build Maven5.9.3.Les actions la suite du build5.9.4.Dployer vers un gestionnaire de dpt dentreprise5.9.5.Dployer vers des gestionnaires de dpt dentreprise commerciales5.9.6.Grer les modules5.9.7.Les tapes de build supplmentaires dans votre tche de build Maven

    5.10.Utiliser Jenkins avec dautres langages5.10.1.Construire des projets avec Grails5.10.2.Construire des projets avec Gradle5.10.2.1.Le plugin Gradle de Jenkins5.10.2.2.Les builds incrmentaux

    5.10.3.Construire des projets avec Visual Studio MSBuild5.10.4.Construire des projets avec NAnt5.10.5.Construire des projets avec Ruby et Ruby on Rails

    5.11.Conclusion

    Chapter6.Tests automatiss6.1.Introduction6.2.Automatisez vos tests unitaires et d'intgration6.3.Configuration des rapports de test dans Jenkins6.4.Afficher les rsultats de test6.5.Ignorer des tests6.6.Couverture de code6.6.1.Mesurer la couverture de code avec Cobertura6.6.1.1.Intgrer Cobertura avec Maven6.6.1.2.Intgrer Cobertura avec Ant6.6.1.3.Installer le plugin de couverture de code Cobertura6.6.1.4.Les rapports de couverture de code dans votre build6.6.1.5.Interprter les mtriques de couverture de code

    6.6.2.Mesurer la couverture de code avec Clover

    6.7.Tests d'acceptation automatiss6.8.Tests de performance automatiss avec JMeter6.9.A l'aide ! Mes tests sont trop lents !6.9.1.Ajouter plus de matriel6.9.2.Lancer moins de tests d'intgration/fonctionnels6.9.3.Excutez vos tests en parallle

    6.10.Conclusion

    Chapter7.Scuriser Jenkins7.1.Introduction7.2.Activer la scurit dans Jenkins7.3.Scurit simple dans Jenkins7.4.Domaines de scurit Identifier les utilisateurs Jenkins7.4.1.Utiliser la base de donnes intgre Jenkins7.4.2.Utiliser un annuaire LDAP7.4.3.Utiliser Microsoft Active Directory7.4.4.Utiliser les utilisateurs et les groupes Unix7.4.5.Dlguer au conteneur de Servlet7.4.6.Utiliser Atlassian Crowd7.4.7.S'intgrer avec d'autres systmes

    7.5.Autorisation Qui peut faire quoi7.5.1.Scurit base sur une matrice7.5.1.1.Mettre en place la scurit base sur une matrice7.5.1.2.Configurer plus finement les permissions utilisateurs7.5.1.3.A l'aide ! Je me suis verrouill tout seul !

    7.5.2.Scurit base sur le projet7.5.3.Scurit base sur les rles

    7.6.Audit Garder la trace des actions utilisateurs7.7.Conclusion

    Chapter8.Notification8.1.Introduction8.2.Notification par email8.3.Notification par email avance8.4.Revendiquer des builds8.5.Flux RSS8.6.Radars de build8.7.Messagerie instantane8.7.1.Notification par IM avec Jabber8.7.2.Notification avec IRC

    8.8.Notification par IRC8.9.Notificateurs de bureau8.10.Notifications via Notifo8.11.Notifications vers mobiles8.12.Notifications via SMS8.13.Faire du bruit8.14.Appareils de retour extrmes8.15.Conclusion

    Chapter9.Qualit du Code9.1.Introduction9.2.La qualit du code dans votre processus de build9.3.Les outils danalyse de qualit du code populaires pour Java et Groovy9.3.1.Checkstyle9.3.2.PMD/CPD9.3.3.FindBugs9.3.4.CodeNarc

    9.4.Rapports de problmes de qualit de code avec le plugin Violations9.4.1.Travailler avec des tches de build free-style9.4.2.Travailler avec des tches de build Maven

    9.5.Utiliser les rapports Checkstyle, PMD, et FindBugs9.6.Les rapports sur la complexit du code9.7.Les rapports sur les tches ouvertes9.8.Intgration avec Sonar9.9.Conclusion

    Chapter10.Builds avancs10.1.Introduction10.2.Tches de build paramtres10.2.1.Crer des tches de build paramtres10.2.2.Adapter vos build pour travailler avec des scripts de builds paramtrs10.2.3.Types de paramtres plus avancs10.2.4.Construire partir d'un tag Subversion10.2.5.Raliser un build partir d'un tag Git10.2.6.Dmarrer une tche de build paramtre distance10.2.7.Historique des tches de build paramtres

    10.3.Dclencheurs paramtrs10.4.Tches de build multiconfiguration10.4.1.Configurer un build multiconfiguration10.4.2.Configurer un axe Esclave10.4.3.Configurer un axe JDK10.4.4.Axe personnalis10.4.5.Excuter un Build Multiconfiguration

    10.5.Gnrer vos tches de build Maven automatiquement10.5.1.Configurer une tche10.5.2.Rutiliser une configuration de tche par hritage10.5.3.Le support des plugins10.5.4.Les tches Freestyle

    10.6.Coordonner vos builds10.6.1.Les builds parallles dans Jenkins10.6.2.Graphes de dpendance10.6.3.Jonctions10.6.4.Plugin Locks and Latches

    10.7.Pipelines de build et promotions10.7.1.Gestion des releases Maven avec le plugin M2Release10.7.2.Copier des artefacts10.7.3.Promotions de build10.7.4.Agrger des rsultats de tests10.7.5.Pipelines de Build

    10.8.Conclusion

    Chapter11.Builds distribus11.1.Introduction11.2.L'Architecture de build distribue de Jenkins11.3.Stratgies Matre/Esclave dans Jenkins11.3.1.Le matre dmarre l'agent esclave en utilisant SSH11.3.2.Dmarrer l'agent esclave manuellement via Java Web Start11.3.3.Installer un esclave Jenkins en tant que service Windows11.3.4.Dmarrer le noeud esclave en mode Headless11.3.5.Dmarrer un esclave Windows en tant que service distant

    11.4.Associer une tche de build avec un esclave ou un groupe d'esclaves11.5.Surveillance des noeuds11.6.Cloud computing11.6.1.Utiliser Amazon EC211.6.1.1.Mettre en place votre ferme de build Amazon EC211.6.1.2.Utiliser des instances EC2 comme partie de votre ferme de build11.6.1.3.Utiliser des instances dynamiques

    11.7.Utiliser le service CloudBees DEV@cloud11.8.Conclusion

    Chapter12.Dploiement automatis et livraison continue12.1.Introduction12.2.Mise en oeuvre du dploiement automatis et continu12.2.1.Le script de dploiement12.2.2.Mises jour de base de donnes12.2.3.Tests fumigatoires12.2.4.Revenir sur des changements

    12.3.Dployer vers un serveur d'application12.3.1.Dployer une application Java12.3.1.1.Utiliser le plugin Deploy12.3.1.2.Redployer une version spcifique12.3.1.3.Dployer une version depuis un build Jenkins prcdent12.3.1.4.Dployer une version depuis un dpt Maven

    12.3.2.Dployer des applications base de scripts telles Ruby et PHP

    12.4.Conclusion

    Chapter13.Maintenir Jenkins13.1.Introduction13.2.Surveillance de l'espace disque13.2.1.Utiliser le plugin "Disk Usage"13.2.2.Disk Usage et les projets Jenkins de type Apache Maven

    13.3.Surveiller la charge serveur13.4.Sauvegarde de votre configuration13.4.1.Fondamentaux de la sauvegarde Jenkins13.4.2.Utilisation du Backup Plugin13.4.3.Des sauvegardes automatises plus lgres

    13.5.Archiver les tches de build13.6.Migrer les tches de build13.7.Conclusion

    AppendixA.Automatiser vos tests unitaires et dintgrationA.1.Automatiser vos tests avec MavenA.2.Automatiser vos tests avec Ant

    Index