Expertise - CI/CD : des pipelines qui testent et déploient votre code à chaque commit

Qu'est-ce que la CI/CD ?

CI/CD désigne deux pratiques qui s'enchaînent. Elles sont une des briques de notre démarche DevOps.

L'intégration continue (CI, Continuous Integration) : chaque fois qu'un développeur pousse du code, un serveur le récupère, vérifie qu'il respecte les règles du projet et lance les tests. Si quelque chose casse, l'équipe le voit quelques minutes plus tard sur la merge request, avant que le code arrive sur la branche principale.

Le CD automatise la suite : une fois le code validé, l'application est construite, déployée en recette, puis en production. Il recouvre deux variantes. En livraison continue (Continuous Delivery), la mise en production attend qu'une personne la valide d'un clic. En déploiement continu (Continuous Deployment), elle part toute seule.

Sans CI/CD, ces étapes se font à la main, dans un ordre que chacun connaît plus ou moins bien, et on finit par repousser les mises en production parce qu'elles font peur. Avec un pipeline, chaque changement suit le même chemin et une mise en production devient une opération ordinaire.

Un pipeline, étape par étape

Un pipeline, c'est la suite d'étapes que la CI lance sur chaque commit. Voici celui que nous mettons en place le plus souvent pour une application web. Le principe : une étape ne démarre que si la précédente a réussi, donc un test qui échoue arrête le pipeline et le code ne part nulle part.

1. Le lint

C'est le contrôle le plus rapide. Il vérifie le formatage et les règles de style du projet, et repère les erreurs visibles sans lancer le code, comme une variable inutilisée ou un import manquant. Il tourne en quelques secondes, et la personne qui relit la merge request n'a pas à commenter une indentation.

2. Les tests unitaires, puis les tests end-to-end

Les tests unitaires vérifient chaque fonction séparément. Ils sont rapides, donc ils passent en premier. Les tests end-to-end viennent ensuite : ils démarrent l'application avec sa base de données et la pilotent dans un navigateur, comme le ferait un utilisateur. Ils prennent plus de temps, mais ce sont eux qui attrapent ce qui casse entre deux parties de l'application.

3. Le build de l'image

Quand les tests sont verts, la CI construit l'image Docker de l'application à partir du Dockerfile versionné avec le code, et la pousse dans un registre avec un tag qui la relie au commit. C'est ce tag que l'étape suivante déploie.

4. Le déploiement en recette

L'image est déployée sur un environnement de recette, souvent un cluster Kubernetes. L'équipe et le client y vérifient la fonctionnalité dans des conditions proches de la production. En GitOps, la CI ne touche pas au cluster : elle écrit la nouvelle version de l'image dans un dépôt Git, et le cluster s'aligne dessus.

5. La mise en production

La production est déployée par la CI de la même façon, à partir du même Dockerfile, automatiquement ou après validation selon ce que vous préférez. Si la nouvelle version pose problème, on redéploie la précédente, dont l'image est toujours dans le registre. Ça ne marche que si les migrations de base de données lancées par la nouvelle version restent compatibles avec l'ancienne, et c'est à prévoir avant la mise en production.

Quand elle est décrite en Infrastructure as Code, l'infrastructure suit le même chemin. La CI lance le plan Terraform sur chaque merge request, et l'équipe relit les changements d'infrastructure avant qu'ils soient appliqués.

GitLab CI et GitHub Actions

Nous travaillons avec les deux. GitLab CI est intégré à GitLab : le pipeline se décrit dans un fichier .gitlab-ci.yml à la racine du dépôt, et les jobs tournent sur des runners, ceux de GitLab ou les vôtres. GitHub Actions fait la même chose côté GitHub, avec des workflows rangés dans .github/workflows/ et un large catalogue d'actions toutes prêtes. On choisit en général l'outil de la forge où se trouve déjà votre code. Nous reprenons aussi des CI existantes sous Jenkins.

Sur Kazaplan, le logiciel de plan 3D du groupe Adeo, nous avons d'abord mis en place un nouveau process de CI/CD sur GitLab, qui déployait sur Google Cloud. Dans une seconde phase, nous avons construit un nouveau process sur GitHub.

---

Ce que Naeka peut faire pour vous

Mettre en place une CI/CD

Vous déployez encore à la main, ou votre CI se contente de lancer quelques tests ? Nous écrivons le pipeline complet avec vous, du lint à la production, en décidant ensemble des tests qui bloquent, de qui valide la mise en production et de la façon de revenir en arrière. Quand nous évaluons la maturité de production d'une application, la CI/CD fait partie des fondations que nous regardons en premier.

Réparer une CI lente ou instable

Si la CI met trop longtemps à répondre, ou s'il faut la relancer plusieurs fois avant qu'elle passe, les développeurs finissent par ne plus l'attendre. Nous cherchons où part le temps et d'où viennent les échecs :

• un cache pour les dépendances et les couches Docker, pour ne pas tout retélécharger à chaque pipeline
• les jobs indépendants lancés en parallèle, et les tests répartis sur plusieurs runners
• les tests qui échouent au hasard (flaky tests) : nous cherchons leur cause, une attente mal placée, un ordre d'exécution, une donnée partagée entre deux tests, plutôt que de les relancer jusqu'à ce qu'ils passent

Migrer de GitLab vers GitHub, ou l'inverse

Un changement de forge touche la syntaxe du pipeline, mais aussi les runners, les secrets, les registres d'images et les droits, qui ne marchent pas de la même façon d'une plateforme à l'autre. Nous réécrivons le pipeline pour la nouvelle plateforme, nous vérifions qu'il produit le même résultat que l'ancien, puis nous basculons.

Sécuriser la chaîne

Une CI a accès à votre code, à vos registres d'images et souvent à vos environnements de production. Quelqu'un qui en prend le contrôle peut donc faire beaucoup de dégâts. Quand nous mettons en place ou reprenons une CI, nous vérifions trois points :

• les secrets restent hors du dépôt, dans les variables protégées de la forge ou dans un gestionnaire de secrets, et chaque job n'accède qu'à ceux dont il a besoin
• les images et les actions GitHub sont épinglées par leur empreinte (le digest de l'image, le SHA du commit de l'action) plutôt que par un tag. Un tag peut être déplacé vers une autre version par celui qui contrôle le registre ou le dépôt, une empreinte ne bouge pas : une version compromise n'entre pas dans le pipeline sans que quelqu'un l'ait décidé
• les mises à jour de dépendances sont proposées automatiquement par un outil comme Renovate ou Dependabot, sous forme de merge requests que la CI teste et qu'un développeur relit avant de les fusionner

Brancher un agent de relecture IA dans la CI

Claude Code peut tourner sans interface dans une CI. Nous le branchons sur GitLab CI ou GitHub Actions pour qu'il relise chaque merge request selon les règles de votre projet, écrites dans un fichier REVIEW.md, avant la relecture par un développeur.

Déployer en GitOps

La CI construit et teste, et un outil comme ArgoCD déploie à partir de ce qui est écrit dans Git. Nous mettons en place ce découpage, avec les dépôts d'infrastructure qui vont avec. Votre CI n'a alors plus besoin d'accès direct à vos clusters.

Vous voulez fiabiliser vos déploiements ?

Le plus simple est de partir d'un vrai déploiement : nous lisons vos pipelines, nous en suivons un de bout en bout avec vous, et nous vous montrons où il perd du temps ou prend des risques. Contactez-nous, même si vous déployez encore à la main.