Pipeline as Code, comment le faire accepter aux admins?

Hier soir, j’étais au YaJUG pour parler de Jenkins 2 et de Pipeline-as-code. Après la conférence, on m’a demandé: “Comment peut-on faire accepter Pipeline-as-code à nos admins Jenkins?“. La question n’est pas si simple.

Il faut comprendre qu’avec Pipeline, les devs écrivent la configuration que Jenkins doit exécuter pour construire le projet. Pour moi, c’est déjà un gros avantage: les devs sont les mieux placés pour savoir comment le projet doit être construit. Mais on peut aussi lui faire faire un peu n’importe quoi. Alors comment faire confiance aux projets? Je pense que la question est là.

Sandbox

Premier point, c’est le bac-à-sable. Tous les Pipeline sont interprétés dans un bac-à-sable, limitant les actions des développeurs sur l’instance Jenkins elle-même. Impossible de changer la sécurité de Jenkins avec

Jenkins.instance.disableSecurity();

(ce qui fonctionne dans la console de script de Jenkins ($JENKINS_URL/script)).

Les scripts

Par contre, on peut toujours appeler des scripts potentiellement dangereux:

rm -rf /

Rien ne nous protège contre ça. Mais pas plus les jobs de type Freestyle ou Maven ou autre. Contre ça, la seule sécurité qui compte se trouve au niveau de l’OS: ne lancez pas Jenkins en root et faites des backups.

Maintenance des jobs

C’est fini de faire des copies de job pour pouvoir construire une nouvelle branche: Pipeline-as-Code le fait pour vous! Ce qui veut dire, moins d’interaction Jenkins - Utilisateur. Donc moins d’erreur.

De plus, comme la configuration se trouve dans un Jenkinsfile avec le code source du projet, il est facile de voir (sans plugin) ce qui a changer dans la configuration, mais aussi qui l’a fait.

Qui n’a jamais eu à faire une passe sur tous les jobs d’une instance pour trouver celui/ceux qui n’a/ont pas été construit depuis x mois? Lorsque l’on fait du développement en branche (type git-flow), on se retrouve vite avec plein de job, mais sont-ils encore tous nécessaire? Qui doit les nettoyer? Si vous ne pouvez pas créer des jobs, potentiellement vous ne pourrez pas les supprimer.

Mais avec Pipeline-as-Code, aussi bien la création que la suppression est faite automatiquement.

Conclusion

Je pense avoir fait le tour des arguments qui me plairait en tant qu’admins de Jenkins pour mettre en place et laisser les devs utiliser Pipeline-as-Code. Évidemment, il s’agit de mon avis, biaisé mais surtout, je ne connais pas votre contexte d’entreprise. Si vous avez des points à rajouter, des remarques, n’hésitez pas me le dire dans un commentaire.

Comments