Tout d'abord, à partir d'aujourd'hui, GitLab Community Edition peut être totalement interopérable avec Jenkins. Pas de question.
Dans ce qui suit, je donne quelques commentaires sur une expérience réussie combinant à la fois Jenkins et GitLab CI. Je discuterai également si vous devez utiliser les deux ou un seul d'entre eux, et pour quelle raison.
J'espère que cela vous donnera des informations de qualité sur vos propres projets.
Points forts de GitLab CI et Jenkins
GitLab CI
GitLab CI est naturellement intégré dans GitLab SCM. Vous pouvez créer des pipelines à l'aide de gitlab-ci.yml
fichiers et les manipuler via une interface graphique.
Ces pipelines sous forme de code peuvent évidemment être stockés dans la base de code, en imposant la pratique «tout en tant que code» (accès, versionnage, reproductibilité, réutilisabilité, etc.).
GitLab CI est un excellent outil de gestion visuelle:
- tous les membres des équipes (y compris les non techniques) ont un accès rapide et facile à l'état du cycle de vie des applications.
- il peut donc être utilisé comme un tableau de bord interactif et opérationnel pour la gestion des versions.
Jenkins
Jenkins est un excellent outil de construction. Sa force réside dans ses nombreux plugins. Surtout, j'ai eu beaucoup de chance d'utiliser des plugins d'interface entre Jenkins et d'autres outils CI ou CD. C'est toujours une meilleure option que de redévelopper (peut-être mal) une interface de dialogue entre deux composants.
Pipeline en tant que code est également disponible à l'aide de groovy
scripts.
Utiliser GitLab CI et Jenkins ensemble
Cela peut sembler un peu redondant au début, mais combiner GitLab CI et Jenkins est assez puissant.
- GitLab CI orchestre (chaînes, exécute, surveille ...) des pipelines et on peut profiter de son interface graphique intégrée à GitLab
- Jenkins exécute le travail et facilite le dialogue avec des outils tiers.
Un autre avantage de cette conception est d'avoir un couplage lâche entre les outils:
- nous pourrions remplacer l'un des composants de l'usine de construction sans avoir à retravailler tout le processus CI / CD
- nous pourrions avoir un environnement de construction hétérogène, combinant (éventuellement plusieurs) Jenkins, TeamCity, vous l'appelez, et avoir toujours un seul outil de surveillance.
Le compromis
Bien sûr, il y a un prix à payer pour cette conception: la configuration initiale est lourde et vous devez avoir un niveau minimal de compréhension de nombreux outils.
Pour cette raison, je ne recommande pas une telle configuration sauf si
- vous avez de nombreux outils tiers à gérer. C'est alors que Jenkins est très pratique avec ses nombreux plugins.
- vous devez gérer des applications complexes avec des technologies hétérogènes, chacune ayant un environnement de construction différent, et vous devez toujours disposer d'une interface utilisateur unifiée de gestion du cycle de vie des applications.
Si vous n'êtes dans aucune de ces situations, vous êtes probablement mieux avec une seule des deux, mais pas les deux.
Si je devais en choisir un
GitLab CI et Jenkins ont tous deux des avantages et des inconvénients. Les deux sont des outils puissants. Alors lequel choisir?
Réponse 1
Choisissez celui dans lequel votre équipe (ou un proche) a déjà un certain niveau d'expertise.
Réponse 2
Si vous êtes tous de première année en technologies CI, choisissez-en une et lancez-vous.
- Si vous utilisez GitLab et avez un talent pour tout comme code, il est tout à fait sensé de choisir GitLab CI.
- Si vous devez dialoguer avec de nombreux autres outils CI / CD ou si vous avez absolument besoin de cette interface graphique pour créer vos travaux, optez pour Jenkins.
Ceux d'entre vous qui utilisent GitLab et qui ne sont pas sûrs de continuer à le faire doivent garder à l'esprit que, avoir choisi GitLab CI impliquerait de détruire tous vos pipelines CI / CD.
Le dernier mot est: l'équilibre penche un peu vers Jenkins en raison de ses nombreux plugins, mais il y a de fortes chances que GitLab CI comble rapidement le vide.