Retour et décryptage de la présentation de Kohsuke Kawaguchi (Jenkins/CloudBees) par Guillaume Darmont (Zenika)

1. Allez plus loin dans l'intégration
continue avec Jenkins
Guillaume Darmont (Zenika)
What’s Next Replay Lyon le 10/11/2011
-
D’après Kohsuke Kawaguchi
(Jenkins / CloudBees)

2. Zenika en quelques mots
Un cabinet de conseil et de réalisation
Un organisme de formation agréé
Expert en Open Source et méthodes Agiles
Spécialisé dans les technologies Java EE
Créé en 2006 par 4 associés
 Expertise technique
 Partage des connaissances
Notre site web : www.zenika.com
Notre blog technique : http://blog.zenika.com
Nos formations : http://www.zenika.com/catalogue-formation
Nous suivre sur Twitter : @ZenikaIT 2

3. Nos implantations
Paris
Lyon
Rennes
Nantes
Et aussi ...
Londres
Athènes
3

4. Zenika Paris
Nous suivre sur Twitter : @ZenikaIT
4

5. Zenika Lyon
Nous suivre sur Twitter : @ZenikaLyon
5

6. Zenika Rennes & Nantes
Nous suivre sur Twitter : @ZenikaOuest
6

7. 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

8. 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…)

9. 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.
• But : Mettre en œuvre un ensemble de moyens pour que les
processus d’intégration d’un projet deviennent un « non
événement »
 Avoir un processus rapide et répétable
• Lancement des tâches en mode « Pousse bouton »

10. Composantes de l’IC
• Elé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
• Que peut apporter l’utilisation conjointe de l’IC et des
dernières technologies ?

11. What’s Next ?

12. Intégration Continue, Cloud, VMs

13. Evolutions des processeurs

14. Architecture SPARC

15. 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 !

16. Le plein de puissance !
• Puissance de calcul offerte par un parallélisme accru, à
tous les niveaux :
• Davantage de thread
• Davantage de machines virtuelles
• Davantage de machines physiques
• Problème : Comment gérer cette multitude de machines ?
• Outils de gestion de parcs : Puppet, Chef, CFEngine
• Utilisation de Clouds privés (PaaS) : RightScale, etc…

17. 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

18. 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

19. Toujours plus d’automatisation

20. 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

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

22. 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

23. 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

24. 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
• Cette profusion de plugins nous permet d’envisager
l’Intégration Continue sous un autre angle…

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

26. 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

27. 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

28. 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.)

29. 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

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

31. 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

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

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

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

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

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

37. 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

38. 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

39. 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à

40. 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  »

41. Questions ?