Tuto : intègre tes pipelines Jenkins à Buildkite
Tuto : intègre tes pipelines Jenkins à Buildkite
POV: tu viens de découvrir Buildkite et tu es tombé amoureux de son architecture hybride, de son incroyable vitesse, de sa sécurité et de sa souplesse. Mais tu rencontres pourtant un problème. Toutes tes pipelines CI/CD tournent sur Jenkins. Si c’est le cas, ce tuto est pour toi. Laisse moi t’expliquer comment intégrer tes pipelines de Jenkins à Buildkite.
Configurer Buildkite
Contrairement à Jenkins, démarrer avec Buildkite est très simple. Tu as juste à lancer la configuration en suivant les instructions fournies. Tu peux installer Buildkite localement ou bien dans le cloud, sur les principaux systèmes d’exploitation - tels que Ubuntu, Debian, Red Hat, FreeBSD, macOS, Windows, Linux, Docker, AWS et Google Cloud.
Grâce à son caractère hybride, une fois l‘agent installé, tu peux te laisser guider par l’expérience user-friendly offerte par Buildkite pour organiser tes pipelines. Par contre, tu devras exporter tes données existantes de Jenkins d’abord.
Exporter les pipelines de Jenkins à Buildkite
Maintenant que Buildkite est installé, le jeu démarre : la migration de tes données actuellement intégrées sur Jenkins.
Pour faire ceci, regardons d’abord comment fonctionne la pipeline Jenkins.
la pipeline : avec la programmation déclarative de Jenkins, il est essentiel de formuler la pipeline au pied de la lettre.
l’agent : tout comme pour la pipeline, la programmation déclarative de Jenkins requiert un certain agent pour lancer une pipeline ou une étape de la pipeline. Dans l’exemple ci-dessus, agent any signifie que n’importe quel agent peut lancer la pipeline.
D’un autre côté, avec Buildkite, toutes les explications ci-dessus ne sont pas utiles. En d’autres mots, ce qui suit est une pipeline Buildkite plus que correcte :
Avançons maintenant aux variables d’environnement. Sur Jenkins, leurs structures ressemblent à ceci :
Comment intégrer les stages et steps
Il est essentiel de comprendre les différences de fonctionnement entre Jenkins et Buildkite en matière de stages et steps.
stages : cet attribut est requis dans Jenkins pour indiquer le début d’un groupe de stages (même principe que quand on code, teste, fait de la prod, etc.)
stage : indique une étape spécifique de la pipeline. L’exemple ci-dessus utilise l’attribut de “Build”.
steps : Jenkins utilise l’attribut steps pour grouper des commandes, des actions, etc...
L’approche de Buildkite pour définir les différents stages et steps est différente de celle de Jenkins. Déjà, il n’est pas nécessaire de déclarer les différents stages séparément, puisque l’attribut des steps s’en charge. C’est possible car Buildkite utilise 6 types de steps :
command : comme son nom l’indique, l’attribut command permet d'exécuter n’importe quelle interface système.
wait : wait permet de mettre en pause la pipeline jusqu’à ce que toutes les steps précédentes soient accomplies.
block : block est comparable à wait, avec la différence notoire que la pipeline doit être bloquée manuellement.
input : comme pour block, input nécessite l’intervention de l’utilisateur pour compléter la pipeline. En revanche, ça n’a pas d’incidence sur les autres steps.
trigger : grâce au trigger, tu peux démarrer une nouvelle pipeline, ce qui peut être utile si tu as des cas complexes où tu dois séparer des tâches en fonction des pipelines.
group : comme son nom l’indique, group permet de regrouper plusieurs steps en une seule dans Buildkite.
En complément de ces informations, nous pouvons intégrer des fichiers Jenkins à la pipeline.yml de Buildkite, comme ci-dessous :
Le mot de la fin
Il y aurait encore plein de choses à dire sur les pipelines Buildkite, comme le fait que tu peux programmer des pipelines en utilisant des fichiers YAML ou directement via l’interface utilisateur de Buildkite. Plus encore : il y a une multitude de sujets intéressants à aborder, comme la migration des conditionals, comment faire sauter les erreurs sur build, et plus encore.
