Jenkins et docker sont dans un bateau par Nicolas De Loof à JugSummerCamp

Je n'avais plus vu de présentation de Jenkins depuis plusieurs années et je voulais voir les dernières préconisations pour gérer le cycle de vie d'une application. Aujourd'hui la création logicielle se rapproche beaucoup de l'industrie où il est essentiel d'automatiser les tâches redondantes, sources d'erreur et apportant peu de valeur ajoutée.

On peut voir ces aspects au niveau management avec des méthodes comme Kanban qui vont aider à gérer le flux des demandes utilisateurs et aider à mettre en place une boucle d'amélioration continue. Au niveau technique le but est de passer au continuous delivery ou le travail du développeur s'arrête au commit. Tout le processus qui va jusqu'à la mise en production de l'application doit être industrialisé. Sur ce sujet vous pouvez voir la keynote de Quentin Adam à Devoxx France 2015. Tout comme pour Kanban le but est de construire un système simple que l'on peut facilement et continuellement améliorer.

Les différentes phases pour amener un logiciel en production peuvent être similaires

Chacune des étapes peut être automatisée ou non. Par exemple si la couverture par des tests fonctionnels automatiques n'est pas assez élevée, le passage entre l'environnement de tests et l'environnement de production peut être fait manuellement une fois que la QA donne son feu vert.

Jenkins fait partie des outils qui vont permettre de mettre en place cette automatisation.

La solution naïve

Vous pouvez découper vos différentes opérations en différents jobs. Par exemple build / smoke tests / acceptance tests / staging / prod. Si vous lancez les tâches une à une manuellement vous n'avez pas de problème, mais vous êtes loin d'avoir une usine logicielle bien huilée.

Une première solution consiste à lier les jobs et de les déclencher automatiquement les uns à la suite des autres. 

Si vous avez des tâches manuelles vous pouvez utiliser le plugin promotion qui ajoutera un déclencheur manuel avant de passer à une étape suivante.

Cette solution marche mais elle peut être longue si votre batterie de tests d’acceptance est élevée. Quand on développe, les "push" sont fréquents et si les tests sont lancés fréquemment nous allons vite avoir des goulots d'étranglement car les tests sont plus longs à être exécutés. Une solution est de découper un peu plus le travail et de répartir les tests sur différents esclaves Jenkins. Vous allez utiliser plusieurs plugins pour découper le travail et plusieurs autres pour ré-agréger les résultats. Au final vous pouvez avoir une solution qui marche mais vous aurez monté une véritable usine à gaz totalement immaintenable.

Un autre problème peut arriver. Si l'ensemble de vos tests prend plusieurs heures comment relancer le workflow à l'endroit où il est tombé en erreur sans avoir à repartir du début ?

Le plugin workflow

Pour répondre à cette problématique vous pouvez utiliser le plugin workflow qui aide à modéliser le pipeline. Au lieu d'avoir un ensemble de jobs que vous liez entre eux, vous utilisez un DSL pour définir toutes les phases et le cycle de vie de votre application. Un peu sur la logique de ce que l'on fait pour construire un rpm ou une image docker.

Comme le DSL n'est pas très intuitif il propose une aide pour générer les commandes


Si vous devez redémarrer la machine le job en cours finira son exécution et le workflow se relancera automatiquement une fois le redémarrage effectué.

Le futur

Le but dans les prochains mois est d'extraire ce fichier de Jenkins et de le mettre directement dans votre projet. Jenkins sera capable de le détecter automatiquement.

Le premier avantage est que le script sera versionné et directement lié à la version en cours de votre projet. Vous conserverez à chaque fois un historique des modifications. Ce fichier peut permettre à l'avenir de simplifier le travail des développeurs en générant automatiquement les jobs dans Jenkins. Nous allons passer de l'infrastcure as a service à l'infrastructure as the code.

Une des autres sources d'amélioration de Jenkins est d'essayer de proposer une interaction plus simple avec Docker. Il existe des plugins pour gérer le cycle de vie d'une instance mais le but est ici de proposer la création simple d'un ensemble d'instances pour reproduire ce que l'on retrouve en prod : un ou plusieurs serveurs pour l'application, d'autres pour les sources de données. Le but est double faciliter l'installation de votre application quelque soit sa topologie et faciliter la reproductibilité des builds dans le temps.

Pour cela Nicolas nous a présenté rapidement son plugin container-slaves-plugin. Je vous encourage à regarder la page du projet.

Au final j'ai bien aimé ce talk car je repars avec des idées concrètes pour améliorer ma manière de construire mes projets et une vision de ce que je vais bientôt pouvoir faire… Il ne manque plus qu'une belle interface responsive et ce sera génial... :-)