Jenkins 2 : pipeline as code
En temps que développeur je suis convaincu depuis très longtemps de l’utilisation de jenkins dans un projet de développement.
Pour ceux qui ont pas suivit jenkins semble s’imposer très souvent comme l’outil essentiel d’une bonne usine logiciel. Je l’utilise principalement pour que mon build de mon projet java/maven se passe toujours de la même façon.
Il y a quelques temps un changement de SCM (passage de SVN à GIT), et l’utilisation des features branchs, nous a fait repenser comment se servir de jenkins. C’est la que nous nous sommes intéresser à la dernière option quand nous créons un projet.
Le multibranch pipeline permet de déporter la configuration de jenkins dans un fichier qui est déposé directement dans le projet. Et le gros plus, c’est que jenkins auto découvre les branchs, donc toutes les nouvelles branchs sont builder sans action spécifique à prévoir.
Ce qui a pas mal d’avantage :
- La configuration est historisée dans le SCM
- La configuration est indépendante de l’installation de jenkins
- Toutes les branchs sont buildées
- Tous se fait via du code
Mais aussi quelques désavantage :
- Tous se fait via du code (et oui il va falloir coder)
D’un point de vue purement jenkins la configuration est donc très simple, ça ressemble à ça :
Une fois ces éléments pris en compte c’est le moment de commencer à faire son pipeline, et de lire la doc. Il y a 2 mode de pipeline aujourd’hui dans jenkins, l’ancienne façon et la nouvelle (nommé declarative pipeline).
J’ai beaucoup utilisé declarative pipeline, les débuts ne sont pas forcement très évident, Jenkins valide le format du script et au début on fait beaucoup d’erreur en faisant des copier/coller un peu trop rapide de ce qu’on trouve dans le document sur la syntaxe. Et on passe aussi beaucoup de temps a push des nouvelles version de notre jenkinsfile sur le SCM, mais une fois la prise en mains faite c’est très facile d’ajouter de la fonctionnalité.
Comme on peut le voir dans la copie d’écran plus haut, nous sommes aller un peu plus loin dans l’utilisation de jenkins et nous arrivons maintenant a faire de la validation de fichier (xmllint est mon ami), mais nous allons jusqu’a déposer notre version chez AWS puis lancer une usine de Continuous deployment (qui elle est géré dans gitlab par l’infogérance).
Vous pouvez voir ci-dessous un exemple simple d’un Jenkinsfile qui lance maven et qui ensuite appel sonar :
