• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
What's Next Replay - IC / Jenkins
 

What's Next Replay - IC / Jenkins

on

  • 663 views

Intégration continue, jenkins zenika

Intégration continue, jenkins zenika

Statistics

Views

Total Views
663
Views on SlideShare
663
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

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 - IC / Jenkins What's Next Replay - IC / Jenkins Presentation Transcript

    • Allez plus loin dans lintégration continue avec Jenkins Sébastien Brousse (Zenika) - D’après Kohsuke Kawaguchi (Jenkins / CloudBees)
    • Sébastien Brousse• Consultant Zenika Ouest• Formateur• Contribution OSS Jenkins Automatisation• Conférences, JUG Continuous Delivery TDD Tests Intégration continue Maven Forge logicielle
    • 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
    • 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.
    • Composantes de l’IC• Élé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
    • L’IC à lheure 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
    • « L’intégration continue c’est pour les développeurs »
    • 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
    • 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é
    • 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 ?
    • 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 ?
    • Jenkins
    • 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…)
    • Létat de lart de lIC 6:publish metrics 2:update 4:deploy 1:commit 3:share 7:notify 5:install
    • What’s Next ?
    • Toujours plus d’automatisation
    • 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
    • Du coté des navigateurs…• … la prochaine « grande bataille »
    • 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
    • Intégration Continue, Cloud, VMs
    • Evolutions des processeurs
    • 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 !
    • Plus de MachinesMachines Physiques
    • Plus de VMsMachines Physiques Machines Virtuelles
    • Plus de processusMachines Physiques Machines Virtuelles Processus
    • 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
    • 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
    • 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
    • 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
    • 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
    • L’intégration continue en tant que Fonction
    • 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
    • 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
    • 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.)
    • 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
    • Partage sélectif• Aussi appelé Revue de Code• Vous partagez votre modification avec quelques personnes• La modification est évaluée
    • 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
    • IC en tant que Revue de Code Développement Jenkins / Gerrit Central Repo
    • IC en tant que Revue de Code Développement Jenkins / Gerrit Central Repo
    • IC en tant que Revue de Code Développement Jenkins / Gerrit Central Repo
    • IC en tant que Revue de Code Développement Jenkins / Gerrit Central Repo
    • IC en tant que Revue de Code Développement Jenkins / Gerrit Central Repo
    • 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
    • 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
    • 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à
    • 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  »
    • Questions ?