CI/CD

CI/CD signifie intégration continue et livraison continue (ou déploiement continu) : un ensemble de pratiques et de pipelines automatisés qui construisent, testent et livrent le code à chaque changement poussé par un développeur, au lieu de regrouper des mois de travail dans une seule mise en production risquée. L'intégration continue consiste à fusionner le code dans une branche partagée fréquemment et à lancer un build et une suite de tests automatisés à chaque fusion. La livraison continue va plus loin en préparant automatiquement chaque build validé pour la mise en production, et le déploiement continu va encore plus loin en la mettant en ligne sans étape de validation manuelle. Ensemble, ces pratiques permettent à une application web de livrer des changements chaque jour, voire plusieurs fois par jour, sans que chaque mise en production ne devienne un événement. Avant que le CI/CD ne devienne un standard, les équipes regroupaient souvent des semaines de travail dans une seule grosse livraison, testée manuellement juste avant le lancement, et le jour du déploiement était un événement stressant et risqué qui mobilisait toute l'équipe.

‍

Comment fonctionne un pipeline CI/CD

Un pipeline est une séquence d'étapes automatisées déclenchées par un changement de code : installer les dépendances, lancer la suite de tests, construire l'application, puis la déployer sur un environnement de préproduction ou de production si toutes les étapes précédentes ont réussi. Chaque étape s'exécute dans un environnement propre et isolé, donc un pipeline se comporte de la même façon quel que soit le développeur qui l'a déclenché ou ce qu'il y avait sur sa machine.

on: push sur main
jobs:
  test: npm ci && npm test
  build: npm run build
  deploy: déployer en production (seulement si test et build réussissent)

Si une étape échoue, le pipeline s'arrête et l'équipe est notifiée immédiatement, avant qu'un changement cassé n'atteigne les utilisateurs. L'objectif, c'est la rapidité du retour : un bug détecté dans un pipeline de deux minutes coûte bien moins cher à corriger que le même bug trouvé par un client en production. Les pipelines exécutent aussi généralement du linting et de l'analyse statique en parallèle des tests, ce qui détecte les problèmes de style et les bugs évidents avant même qu'un relecteur humain n'ouvre la pull request.

‍

CI, CD et déploiement continu

• Intégration continue (CI) : chaque changement de code est automatiquement construit et testé dès sa fusion, pour détecter les problèmes d'intégration tôt.
• Livraison continue : chaque changement qui passe la CI est automatiquement packagé et prêt à être mis en production, avec un clic manuel pour la publier réellement.
• Déploiement continu : chaque changement qui passe la CI est mis en production automatiquement, sans aucune étape de validation manuelle.

La plupart des équipes commencent par la CI seule, ajoutent la livraison continue une fois leur couverture de tests solide, et ne passent au déploiement continu complet que pour les applications où l'équipe fait suffisamment confiance au pipeline pour se passer entièrement d'un point de contrôle humain.

‍

CI/CD vs déploiement manuel

La différence pratique se voit surtout quand quelque chose doit être livré vite, ou quand ça casse :

‍

Bonnes pratiques et pièges courants

• Garder le pipeline rapide : une suite de tests qui prend 40 minutes finit par être sautée ou ignorée, une qui prend 3 minutes non.
• Exécuter exactement le même pipeline pour chaque branche, pas une version allégée pour les branches de fonctionnalité et une plus stricte pour main.
• Faire échouer le build sur des tests instables ou ignorés plutôt que de les ignorer silencieusement : un pipeline vert qui ment est pire qu'un pipeline rouge.
• Automatiser le rollback, pas seulement le déploiement, pour qu'une mauvaise mise en production puisse être annulée en minutes plutôt qu'en heures.
• Stocker les secrets et identifiants dans le gestionnaire de secrets de la plateforme CI, jamais commités dans le dépôt.
• Mettre en cache les dépendances entre les exécutions pour garder une durée de pipeline prévisible à mesure que le code grandit.

‍

Pourquoi le CI/CD compte pour la fiabilité d'une application web

Sans CI/CD, les mises en production sont rares, volumineuses et risquées, ce qui pousse les équipes à les repousser encore, créant des livraisons encore plus grosses et plus risquées ensuite. Avec le CI/CD, chaque changement est petit, testé isolément et facile à tracer en cas de problème, ce qui rend les mises en production fréquentes plus sûres plutôt que plus dangereuses. C'est pourquoi le CI/CD est aujourd'hui considéré comme une base minimale pour toute application web ou produit SaaS sérieux, et non comme une optimisation avancée réservée aux grandes équipes d'ingénierie. Cela change aussi la façon dont une équipe travaille ensemble : la revue de code, les tests et le déploiement cessent d'être des événements séparés et occasionnels pour devenir une partie normale du rythme de livraison d'une fonctionnalité.

‍

CI/CD chez BeBranded

Chez BeBranded, nous mettons en place des pipelines CI/CD pour les applications web que nous construisons, afin que chaque changement soit testé et déployé automatiquement plutôt que de dépendre d'un processus de mise en production manuel. Ce travail s'inscrit dans notre service Web apps.