Temps de lecture : 5 minutes

Article coécrit avec Jérémy Monnier

L’onboarding dans une nouvelle équipe client est un exercice classique mais parfois périlleux. Fort heureusement, on peut souvent bénéficier de l’aide d’un collègue déjà présent sur le projet. Jusqu’au moment où l’on s’aperçoit qu’on ne partage pas forcément les mêmes valeurs, notamment en termes de pipeline…

Quand j’ai entendu « Nous avons du Jenkins », ma première réaction a été de juger, et la seconde de m’interroger. Mais pourquoi pas du GitLab CI ou Github Actions ? Et voilà comment nous nous sommes embarqués dans un débat philosophique autour des outils de CI/CD !

Cet article est donc une manière pour Jérémy et moi de résumer nos échanges, et de partager avec vous nos points de vue sur ces outils de mise en place de pipeline Jenkins, GitHub Actions et GitLab CI.

Quelques définitions de base avant de commencer

GitFlow

L’intégration dans nouvelle équipe demande de s’habituer à de nouvelles pratiques et habitudes. L’une des plus importantes et fréquentes est la gestion de Git. Afin de répondre à ce besoin nous avons le GitFlow. C’est une méthode de gestion du développement logiciel avec Git. Il propose un ensemble de règles et de conventions pour organiser le workflow des équipes. En gros, c’est une façon de structurer les branches Git pour gérer les fonctionnalités, les correctifs de bug et les versions de manière efficace et organisée. Il permet de définir l’exécution de pipelines dans une chaîne CI/CD

CI/CD

C’est l’acronyme de Continuous Integration / Continuous Deployment. Il s’agit d’une pratique logicielle visant à automatiser et à rationaliser le cycle de vie du développement, de la création au déploiement.

Continuous Integration (CI)

La CI se concentre sur l’intégration fréquente et automatisée des modifications de code dans un référentiel centralisé. Cela permet de détecter et de corriger les erreurs plus tôt, et de garantir une bonne qualité de code.

Continuous Deployment (CD)

La CD automatise le processus de création, de test et de déploiement de versions de codes. Cela permet de livrer plus rapidement et plus fréquemment aux utilisateurs finaux. Cela permet de réduire le risque d’erreurs humaines et de garantir un déploiement rapide et fiable.

Différences entre CI et CD

La principale différence entre CI et CD réside dans leur objectif. La CI vise à garantir que le code est toujours intégré et testable, tandis que la CD vise à automatiser le processus de livraison et de déploiement.

CI

• Objectif : Intégration fréquente et automatisée du code
• Focus : Détection et correction des erreurs
• Résultat : bonne couverture de code

CD

• Objectif : Automatisation du processus de livraison et de déploiement
• Focus : Livraison rapide et fréquente
• Résultat : Nouvelles versions disponibles sur les différents environnements

Interface Utilisateur et Facilité d’utilisation

Jenkins

Jenkins est souvent critiqué pour son interface utilisateur, qui peut sembler dépassée et peu conviviale pour les débutants. Cependant, il offre une grande flexibilité grâce à ses plugins.

GitLab CI

Avec son interface graphique intuitive, GitLab CI est souvent plébiscité pour sa facilité d’utilisation. La création de pipelines via des fichiers YAML est simple et bien documentée.

GitHub Actions

GitHub Actions se distingue par son intégration directe avec GitHub, offrant ainsi une expérience utilisateur fluide et cohérente. La création de workflows est conviviale grâce à son éditeur visuel.

Fonctionnalités et Intégrations

Jenkins

Jenkins est réputé pour ses innombrables plugins, qui permettent d’intégrer une variété d’outils et de technologies. Cependant, la configuration peut être complexe et nécessiter une expertise approfondie.

GitLab CI

Outre son intégration transparente avec GitLab, GitLab CI offre des fonctionnalités telles que la gestion des secrets, l’intégration avec des applications externes et la prise en charge des états Terraform.

GitHub Actions

GitHub Actions propose une intégration native avec GitHub, permettant une automatisation complète des workflows de développement. Bien qu’il soit principalement axé sur Git, il offre une gamme d’actions pré-construites et prend en charge diverses intégrations tierces.

Flexibilité et Personnalisation

Jenkins

Avec sa grande flexibilité, Jenkins permet de créer des pipelines personnalisés pour répondre à des besoins spécifiques. Cependant, cela peut nécessiter une expertise en Groovy pour la configuration avancée.

GitLab CI

Grâce à ses pipelines définis en YAML, GitLab CI offre une flexibilité accrue pour personnaliser les processus d’intégration et de déploiement. De plus, sa prise en charge des runners permet une exécution distribuée des tâches.

GitHub Actions

On a une large offre de plugins disponibles sur le marketplace qui permettent une personnalisation assez facile et flexible.

Communauté et Support

Jenkins

Jenkins bénéficie d’une vaste communauté d’utilisateurs et de développeurs, offrant un support et des ressources variées. Cependant, la qualité de la documentation peut varier en fonction des plugins utilisés et il peut être fastidieux de trouver directement les informations attendues.

GitLab CI

Avec sa documentation exhaustive et sa communauté active, GitLab CI offre un support solide pour les utilisateurs. De plus, la version Enterprise propose un support commercial pour les entreprises.

GitHub Actions

En tant que produit GitHub, GitHub Actions bénéficie du soutien de la communauté GitHub et de la documentation complète disponible sur la plateforme. Cependant, le support peut être limité pour les cas spécifiques nécessitant une assistance approfondie. Vous aurez potentiellement besoin de payer pour un support entreprise pour vos besoins de production.

Infrastructure & Runners

Jenkins

Infrastructure : Jenkins est un outil open source installable sur n’importe quel serveur. Cela signifie que vous avez le contrôle total de l’infrastructure, mais vous devez également la gérer et la maintenir.

Runners : Jenkins utilise des agents pour exécuter les builds et les tests. Les agents sont hébergés sur des instances ou des conteneurs, et ils peuvent être installés on-prem ou dans le cloud.

GitHub Actions & GitLab CI

Pour l’infrastructure et les runners, il existe 3 modes principaux :

• Hybride : Infrastructure gérée par la plateforme et runners hostés en interne (cloud, on-prem)
• Full managé : infrastructure et runners gérés par la plateforme
• Full self-hosted : infrastructure et runners en interne (cloud, on-prem)

Chaque mode a ses avantages et ses inconvénients, dépendamment des équipes et des budgets.

Conclusion

Le choix de l’outil de CI/CD au sein de chaque équipe reste assez subjectif. Il est souvent lié à la connaissance de la techno des membres de l’équipe, l’écosystème autour de l’application, les licences disponibles, etc.

Chaque outil a ses forces et faiblesses mais répond clairement au besoin premier qui est de faire une chaîne CI/CD. Nous n’avons malheureusement pas de réponse définitive à ce débat, aucune plateforme ne se démarque de loin au bout du compte pour nous, et nous vous laissons la latitude de vous faire un avis en testant ces outils le mieux possible.

Enfin pour aller plus loin dans notre compréhension, avec l’aide de Clovis Menegain, nous avons mis en place un HandsOn Labs pour les collaborateurs et clients de Devoteam Revolve, afin de tester dans un premier temps de façon basique les spécificités de chaque plateforme et ensuite d’aller plus dans le détail.

Teaser : pour les plus demandeurs, une série d’articles nous permettra d’explorer plus en profondeur chaque outil et d’atteindre leurs limites.

A lire également sur le sujet : Allowing a Gitlab project pipeline to pull another project