• Save
What’s Next Replay! Lyon 2011 - G. Darmont
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

What’s Next Replay! Lyon 2011 - G. Darmont

on

  • 1,160 views

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

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

Statistics

Views

Total Views
1,160
Views on SlideShare
874
Embed Views
286

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 286

http://blog.zenika.com 286

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

What’s Next Replay! Lyon 2011 - G. Darmont Presentation Transcript

  • 1. Allez plus loin dans linté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 motsUn cabinet de conseil et de réalisationUn organisme de formation agrééExpert en Open Source et méthodes AgilesSpécialisé dans les technologies Java EECréé en 2006 par 4 associés  Expertise technique  Partage des connaissances Notre site web : www.zenika.com Notre blog technique : http://blog.zenika.comNos 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 linté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 dinté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 ?