Depuis quelques mois, je travaille sur la migration des jobs JENKINS vers des pipelines JENKINS . Les pipelines sont une nouveauté fournie par JENKINS 2. Ça permet de décrire le cycle de vie d’un build par un DSL GROOVY

Exemple :

#!/usr/bin/groovy
@Library('malibrairie')_

node {
echo 'Demarrage du Build'

final MAVEN = "MAVEN-3.2"
final JDK = "JDK8"

try {
/* Extraction GIT/SVN + Initialisation des proprietes */
stage('Clean & Init') {
scm checkout
}
stage('Build'){
withEnv(["PATH+MAVEN=${tool MAVEN}/bin", "PATH+JAVA=${tool JDK}/bin"]) {

sh "mvn -X clean deploy -Pjdk6 -Pdev -DenvClassifier=dev -Dmaven.test.skip=true

}
}
stage('Quality') {
// lancement sonar

}

} catch (exception) {
currentBuild.result = 'FAILURE'
throw exception
} finally {
//
}
}

Bon je ne vous ferai pas un cours sur les pipelines, il y a déjà plusieurs sites qui font ça mieux que moi . Je vais me concentrer sur mon retour d’expérience

Les sharedlib

Ca c’est la killing feature! On peut centraliser les comportements communs à tous les builds et fournir aux projets dans leurs fichiers Jenkinsfile toute une librairie de composants. Celle-ci permet de réellement factoriser le développement des fonctionnalités de l’usine logicielle. En plus, si on couple tout ça à un repo GIT, le cycle de vie est tout trouvé: On développe sur une branche, on peut également la tester dans JENKINS et une fois OK, on publie le tout dans la branche master. Une fois publié, l’ensemble des jobs reçoit la mise à jour. Quand vous avez plus de 50 jobs à administrer, ça représente un gain de temps considérable.

Personnellement j’ai choisi de tout centraliser le comportement dans la sharedlib. De ce fait, le pipeline configuré dans chaque projet à cette forme :

#!/usr/bin/groovy

mavenNode{
  mavenJee{
  deployment=false
  }
} 

Exemple d’invocation d’une librairie

#!/usr/bin/groovy
@Library('malibrairie')_

Exemple d’invocation d’une librairie sur une branche

#!/usr/bin/groovy
@Library('malibrairie@mabranche')_

Les plugins liés à GITHUB

Sur le papier, c’est génial. On a le plugin GITHUB Organization Plugin qui permet de mapper les repo GITHUB sur une instance JENKINS.

Cependant, en entreprise, c’est difficilement utilisable ( sauf si votre entreprise opte pour une appliance ), surtout si vous avez un proxy. En effet, le plugin GITHUB API ne supporte pas les proxy. Bref, je n’ai pas pu pleinement exploiter toutes les fonctionnalités d’un couplage GITHUB/JENKIINS.

La documentation

Même si l’équipe a refait toute la doc, je ne la trouve pas top. J’ai eu du mal à m’y faire au début. J’ai eu plus d’informations en naviguant sur quelques repo GITHUB que sur la documentation.Pour la référence de tous les steps, ça va, mais je ne la trouve pas didactique.

En résumé

Même si il y a quelques déconvenues, les pipelines sont une évolution majeure de JENKINS. Ca m’a permis de perdre du temps dans les écrans d’administration et de factoriser les différents build grâce à du code GROOVY.  Si vous avez encore des JOBS JENKINS « legacy », n’hésitez plus !

Pour aller plus loin

Si vous voulez plus d’exemples et de détails je vous conseille ces liens :

• Le site officiel
• Un repo GITHUB avec des librairies

Original post of Littlewing.Votez pour ce billet sur Planet Libre.