CI/CD : définition et mise en place simple d'un pipeline

CI/CD : la définition en clair

Concrètement, il s'agit d'un ensemble de pratiques qui automatise le trajet entre le code tapé par un développeur et sa publication. L'origine est anglaise : « continuous integration (CI) and continuous delivery », parfois complété par « and deployment ». Et en français ? On dit intégration continue et livraison continue, ou plus simplement chaîne CI/CD.

Une phrase suffit pour le principe. À chaque changement, une machine récupère le code, le compile, exécute des tests automatisés et, si tout est vert, prépare ou réalise la mise en production. Peu importe la langue dans laquelle vous cherchez : en espagnol comme en français, le sigle désigne cette automatisation de la software delivery, autrement dit la livraison du logiciel.

Intégration continue : la partie CI

Fusionner souvent : voilà le cœur de la continuous integration. Les apports de chaque développeur rejoignent un dépôt commun, géré la plupart du temps avec Git, et chaque fusion déclenche d'office builds et tests. L'objectif ? Attraper une erreur quelques minutes après son écriture, pas trois semaines plus tard.

Livraison et déploiement continus : la partie CD

Attention, le CD a deux sens. Avec le continuous delivery, le code validé attend sur le quai : quelqu'un clique encore sur le bouton de publication. Le continuous deployment supprime ce clic, et tout ce qui franchit les tests part directement to production.

À quoi sert une chaîne CI/CD pour une PME

Un dirigeant n'a aucune raison de connaître la commande qui lance un build. Les effets d'une absence d'automatisation, il les repère en revanche très bien : un formulaire de contact cassé après une mise à jour, une page panier qui ne charge plus, un correctif bloqué parce que « personne n'ose déployer ». Le pipeline réduit ces risques, car tout changement subit les mêmes contrôles, sans compter sur la mémoire de qui que ce soit.

• Des publications plus fréquentes et plus petites, donc simples à vérifier comme à annuler.
• Moins de manual work : fini la copie de fichiers par FTP et les manipulations hasardeuses sur le serveur.
• Un process reliable et reproductible, identique d'une release à l'autre.
• Une collaboration plus fluide entre développeurs, qui partent toujours d'une base de code propre.
• Des contrôles de security intégrés, comme la détection de dépendances vulnérables.

Votre site doit rapporter ? L'intérêt devient alors très concret : une boutique ou un outil métier qui reste disponible pendant qu'on le fait évoluer. C'est aussi la condition pour pousser la méthode agile jusqu'au bout, avec de petites améliorations livrées au fil de l'eau plutôt qu'une grosse version tous les six mois.

Comment fonctionne un pipeline CI/CD

Un ci/cd pipeline, c'est une suite d'étapes automatisées, décrite dans un fichier rangé à côté du code. Aucune ne démarre tant que la précédente n'a pas réussi. L'une échoue ? Tout s'arrête, l'équipe reçoit une alerte, et rien de cassé n'arrive en ligne.

Les étapes classiques

• Le déclencheur : un développeur pousse des changes sur le dépôt, ou ouvre une demande de fusion.
• Le build : assemblage du code, installation des dépendances, compilation des fichiers CSS et JavaScript.
• Les tests : unitaires, d'intégration, parfois de bout en bout pour simuler un vrai visiteur.
• Les contrôles qualité et sécurité : analyse du code, recherche de failles connues dans les bibliothèques.
• Le déploiement de test : publication sur un environnement de préproduction pour un dernier coup d'œil.
• La mise en production : automatique ou après validation humaine, selon le niveau de CD retenu.

En anglais, ce workflow se résume souvent par « build, testing, and deployment ». L'ordre est ce qui compte vraiment : on ne déploie jamais un élément qui n'a pas été construit et testé dans les mêmes conditions.

Continuous delivery ou continuous deployment : lequel choisir ?

Pour la plupart des PME, je recommande sans hésiter de commencer par la livraison continue. Le code reste prêt à partir, mais quelqu'un décide du moment de la publication (bien utile pour éviter un déploiement en pleine campagne publicitaire). Le déploiement continu, lui, exige des tests très solides, puisque plus personne ne relit avant la production.

Mise en place simple : outils et exemple concret

Inutile de viser une usine logicielle dès le premier jour ! Un pipeline ci minimal, qui lance les tests et bloque la fusion en cas d'erreur, apporte déjà l'essentiel des bénéfices. Viennent ensuite le déploiement automatique, puis les contrôles de sécurité.

Les principaux outils du marché

• GitHub Actions : intégré à GitHub, il se configure via un fichier placé dans le dépôt. Pratique quand votre code est déjà hébergé là.
• GitLab CI/CD : intégré à GitLab, très complet, avec des runners que l'on peut héberger soi-même.
• Jenkins : serveur d'automatisation open source, très souple, mais qu'il faut installer et entretenir.
• Des services spécialisés comme CircleCI, ou les pipelines proposés par les hébergeurs modernes pour les sites statiques.

Opposer CI/CD et Jenkins n'a donc pas grand sens. L'un est la méthode, l'autre un outil parmi d'autres pour l'appliquer. Où se trouve déjà votre code, et qui assurera la maintenance ? Ce sont ces questions qui tranchent.

Nous mettons en place ce type de chaîne lors d'une création de logiciel : elle fait partie du livrable, au même titre que le code. Autre avantage, elle simplifie la maintenance du site web, puisque chaque correctif de sécurité emprunte le même chemin contrôlé.

CI/CD, DevOps, GitOps, SDLC : ne pas tout mélanger

Ces termes voyagent souvent ensemble, et c'est logique : tous parlent de la façon de produire du logiciel. Ils ne jouent pourtant pas dans la même catégorie.

DevOps et CI/CD

Plus qu'un outil, DevOps est une culture d'organisation, née du rapprochement entre « development and operations » : ceux qui écrivent le code d'un côté, ceux qui l'exploitent de l'autre. Le pipeline en est la traduction technique la plus visible. Mais DevOps couvre aussi la surveillance, la gestion des incidents et le partage des responsabilités.

SDLC et CI/CD

Le SDLC, pour Software Development Life Cycle, décrit tout le cycle de vie d'un logiciel : analyse des besoins, conception, développement, tests, mise en ligne, maintenance. Le CI/CD n'en automatise qu'un tronçon, de l'écriture du code jusqu'à la production. Il ne remplace ni le cahier des charges, ni la conception.

GitOps et CI/CD

GitOps va plus loin. L'état souhaité de l'infrastructure est décrit dans Git, et un outil comme Argo CD ou Flux aligne en permanence les serveurs sur le contenu du dépôt ; la CI, elle, reste en amont pour tester le code. Une approche surtout utile pour des infrastructures conteneurisées, rarement pour un site vitrine.

Les erreurs courantes à éviter

Mal pensé, un pipeline donne une fausse impression de sécurité. Voici les pièges que l'on croise le plus souvent sur des projets repris en cours de route.

• Automatiser le déploiement sans tests : on livre simplement les bugs plus vite.
• Tolérer des tests en échec « temporairement » : l'équipe finit par ignorer les alertes.
• Laisser mots de passe et clés d'API en clair dans le fichier du pipeline, au lieu des secrets prévus par l'outil.
• Sauter la préproduction pour gagner du temps, puis découvrir le problème en ligne.
• Oublier le retour arrière : toute release doit pouvoir être annulée rapidement.
• Ne rien surveiller après la publication, alors qu'un monitoring du site web repère en quelques minutes ce que les tests ont raté.

Questions fréquentes