Intégration continue, jenkins zenika

1. Allez plus loin dans l'intégration
continue avec Jenkins
Sébastien Brousse (Zenika)
-
D’après Kohsuke Kawaguchi
(Jenkins / CloudBees)

2. Sébastien Brousse
• Consultant Zenika Ouest
• Formateur
• Contribution OSS
Jenkins Automatisation
• Conférences, JUG
Continuous Delivery
TDD Tests
Intégration continue
Maven Forge logicielle

3. Auteur de la présentation
• Kohsuke Kawaguchi
• Créateur / Project lead Jenkins
• Architecte @ CloudBees
• Mais aussi :
– RELAX
– JAXB, JAX-WS, JAXP, etc.@ Sun
– Une partie de GlassFish V3

4. L’intégration continue ?
• « Intégration » ?
Différents processus : compilation, exécution des tests,
opérations sur base de données, packaging, déploiements, etc.
• « Continue » ?
L’effort d’intégration augmente avec le temps écoulé depuis la
dernière intégration. La régularité diminue les risques.

5. Composantes de l’IC
• Éléments composants l'intégration continue :
• Mécanismes de surveillance du changement (on surveille un
environnement)
• Gestionnaire de versions
– Indispensable même sans intégration continue
• Ensemble de scripts pour implémenter les processus
d'intégration
• Mécanismes de notifications
• L’IC n’est pas un concept récent

6. L’IC à l'heure actuelle
• Une méthode reconnue
• Des outils matures :
• Gestionnaire de versions : SVN
• Build : Maven, Ant/Ivy, Gradle
• Analyseurs : Checkstyle, PMD, Sonar
• Gestion de documentation : Wiki
• Test : Junit, Cobertura, Selenium
• Des bonnes pratiques malgré tout encore partiellement adoptées
et restreintes surtout aux développeurs

7. « L’intégration continue c’est pour les
développeurs »

8. L’IC : les idées reçues
• Des outils développés pour les développeurs
• Quel opérationnel utilise Maven pour déployer en
production ?
• Quel fonctionnel regarde les rapports de couverture de
tests ?
• Quel DBA code des scripts de migration avec Ant ?
• Chaque monde a ses propres outils, son langage, sa vision
• La barrière technique empêche la communication et la
compréhension

9. La promesse de l’IC
• L’intégration continue comme chaînon manquant entre les
équipes
• Abstraire les concepts techniques au travers d’un
langage commun
• « livrer la dernière version aux exploitants »
• « installer la v2.3 en qualification »
• « valider la fonctionnalité »
• Toutes ces actions en 1 clic !
• Des retours visuels et simples : Vert = OK !
• Le tout de manière automatisé

10. L’objectif de l’IC
• Objectifs
• Mettre en œuvre un ensemble de moyens pour que les
processus d’intégration d’un projet deviennent un « non
événement »
• Moyens
• Avoir un processus rapide, répétable et automatisable
• C’est tout ?

11. L’intégration continue
• Qu’est-ce qui est capable de :
• Analyser des rapports de tests ?
• Vérifier qu’il n’y a pas d’erreurs lors de l’exécution d’une
migration de base de données ?
• Transférer des archives d’un serveur à un autre ?
• Surveiller la correction d’un bug sur le gestionnaire de
sources ?
• Construire des projets à la fois en Java, .NET et C++ ?
• Ecrire un email pour vous rassurer ?
• Afficher la météo ?

12. Jenkins

13. Jenkins-ci.org
• Serveur d’Intégration Continue Open Source
• Ecrit en Java
• Existe depuis 7 ans
• Facile à installer et utiliser
• Extensible via 350+ plugins
• Largement utilisé
• 11K+ installations
• 26K+ si on tient compte de l’ancien nom (Hud…)

14. L'état de l'art de l'IC
6:publish metrics
2:update
4:deploy
1:commit
3:share
7:notify 5:install

15. What’s Next ?

16. Toujours plus d’automatisation

17. Du coté des outils de dév…
• Progrès constants au niveau des outils de développement
• Invocation non-interactive sous Windows
• Visual Studio  MSBuild
• Outils offrent une sortie pouvant être utilisée par une
machine
• CVS  Subversion
• Tests frameworks
• Demande de plus en plus forte des utilisateurs pour un
accès batch / CLI à leurs outils

18. Du coté des navigateurs…
• … la prochaine « grande bataille »

19. Du coté des navigateurs…
• Quid de Selenium ?
• Preuve que le besoin est là, mais la solution n’est pas
optimale
• Idéalement, il faudrait:
• Pas d’affichage nécessaire
• Possibilité d’embarquer le navigateur dans le processus, afin
d’offrir une meilleure délimitation des comportements
• Plus de proxy
• Accès direct aux logs consoles du navigateur
• Injection de comportements / d’erreurs

20. Intégration Continue, Cloud, VMs

21. Evolutions des processeurs

22. Le plein de puissance !
• De plus en plus de puissance de calcul
• De moins en moins cher
• Ratio Performance/Prix de la puissance de calcul meilleur
que jamais
• Ratio Performance/Prix des personnes évolue peu
•  Utiliser les ordinateurs efficacement est primordial !

23. Plus de Machines
Machines Physiques

24. Plus de VMs
Machines Physiques Machines Virtuelles

25. Plus de processus
Machines Physiques Machines Virtuelles Processus

26. Le plein de puissance !
• Plus de puissance mais plus de parallélisme !
• À tous les niveaux
• Des outils avec un mode « parallèle »
• Maven 3 : construction des modules
• Junit : lancement des tests
• Selenium Grid : exécution des tests fonctionnels

27. Apport du Cloud et des VMs
• Mise à disposition automatique et en temps réel de
machines virtuelles
• Permet de changer la donne :
• Cloner une machine virtuelle « fraîche » à chaque exécution
des tests
• Transformer une machine de tests « Quality Assurance » en
production sans redéployer
• Instantanés (Snapshots) des VMs
• Lors de tests en échecs

28. Cloud & SaaS
• SaaS = Software as a Service, hébergé dans le Cloud
• Sauce OnDemand : Selenium
• DeviceAnywhere : Tests d’applications mobiles
• Un autre moyen de simplifier et automatiser la mise à
disposition des éléments nécessaires
• Flexibilité grâce au Just-In-Time
• Tarifs au temps consommé (pour Cloudbees)
Nb Machines Nb Machines
Temps Temps

29. Automatiser, encore et encore !
• Automatiser à tous les niveaux :
• Machines, OS, middlewares, outils
• Automatiser grâce :
• Au Cloud, aux VMs, aux SaaS
• D’innombrables perspectives d’automatisation vous sont
ouvertes !
• Utilisation des serveurs d’Intégration Continue pour fédérer
toutes ces briques : Jenkins

30. Jenkins
• Exécution de builds distribués depuis 5 ans
• Permet de contrôler et gérer plus de 100 machines depuis
un seul endroit
• Offre un mécanisme de plugin permettant d’étendre
facilement ses possibilités

31. L’intégration continue en tant que
Fonction

32. Une Fonction ?
• Penser un build/test comme une fonction
• Par exemple : F(objet source) = métriques qualité
• Pas d’effets de bord
• L’évaluation de la fonction peut être coûteuse
• Faire de l’asynchrone
• L’« objet source » est créé en premier
• Calcul des métriques qualité viennent par la suite
• Calcul des métriques qualité découpé en plusieurs étapes

33. Une Fonction ?
• F(objet source) = métriques qualité
• En pratique, on a F(commit) = métriques qualité
• Pourquoi les commits :
• Déterminent sans ambiguïté une arborescence source
• Nombreux outils déjà disponibles
• Copie simple et rapide d’une machine vers une autre

34. Dilemme des commits SVN
• Imaginez un projet avec de nombreux tests
• Le développeur se concentre sur ce qu’il doit faire
• Le reste, comme par exemple l’exécution des tests, est
effectué par le serveur d’Intégration Continue
• Un commit est nécessaire pour l’Intégration Continue
• Mais vous ne voulez pas commiter sans valider via l’IC
• Donc, vous ne pouvez pas créer de commits 
•  Solution : Utilisation d’un gestionnaire de version
distribué (Distributed VCS comme Git, Mercurial, etc.)

35. Distributed VCS
• Permet de séparer la notion de commit de la notion de
partage
• Comme pour SVN, commit = arborescence source
• Mais possibilité de partager seulement une partie des
commits (avec SVN, pas de commit non partagé)
•  Partage sélectif

36. Partage sélectif
• Aussi appelé Revue de Code
• Vous partagez votre modification avec quelques personnes
• La modification est évaluée

37. Partage sélectif
• Aussi appelé Revue de Code
• Vous partagez votre modification avec quelques personnes
• La modification est évaluée
• Puis vous partagez de manière globale cette même
modification

38. IC en tant que Revue de Code
Développement Jenkins / Gerrit Central Repo

39. IC en tant que Revue de Code
Développement Jenkins / Gerrit Central Repo

40. IC en tant que Revue de Code
Développement Jenkins / Gerrit Central Repo

41. IC en tant que Revue de Code
Développement Jenkins / Gerrit Central Repo

42. IC en tant que Revue de Code
Développement Jenkins / Gerrit Central Repo

43. IC en tant que Revue de Code
• Plusieurs façons d’implémenter ce fonctionnement
• Surveiller les commits locaux
• Envoyer (push) certains commits pour demander à l’IC de
le tester
• Lors du push sur le repository central, le repo peut
consulter les résultats du serveur d’IC via le commit ID
• Rejet des changements non validés
• Réduction du temps entre le push et l’apparition dans le repo

44. IC en tant que Revue de Code
• « Liberal branching »
• Chaque développeur pousse ses commits sur sa branche
• Jenkins les récupère et les intègre dans le repo central
Branche Dev1
Branche Dev2
Central Repo

45. Fini les tests en local !
• Laisser travailler les serveurs d’IC
• Ne pas bloquer les développeurs est primordial
• Mieux vaut attendre pour avoir les résultats via l’IC, plutôt
que les lancer en local
•  Plusieurs réponses possibles
• Dépend des équipes, des workflows mis en œuvre
• Mais quelque soit l’implémentation choisie, l’Intégration
Continue en tant que Fonction est toujours là

46. Conclusion
• De plus en plus de puissance de calcul à disposition
• De plus en plus de parallélisme à exploiter
• Impacte l’ingénierie logicielle : comment bénéficier du
parallélisme ?
• De nombreuses tendances poussent à l’automatisation :
• Cloud, VM, DVCS, outils développeurs avec batch mode, …
• Laisser les ordinateurs faire le travail répétitif
• Laisser les décisions aux personnes
• « Auparavant, l’intégration continue était la noisette dans le
chocolat, maintenant c’est le chocolat  »

47. Questions ?