Ce que votre outil CI/CD fait réellement : une décomposition fonctionnelle

Vous avez un pipeline qui construit, teste et déploie votre application. Mais quand quelque chose casse, vous réalisez que vous n'êtes pas sûr de quel outil est responsable de quoi. Le serveur CI est tombé, mais le déploiement a quand même eu lieu. Le registre d'artefacts contient trois versions de la même build, et personne ne sait laquelle est correcte. La migration de base de données a été exécutée deux fois, et maintenant le schéma est dans un état inconnu.

Cette confusion survient lorsque les équipes choisissent des outils par nom ou popularité au lieu de comprendre ce que chaque outil est censé faire. Un serveur CI ne peut pas remplacer un outil de déploiement. Un système de feature flags n'est pas un gestionnaire de secrets. Une plateforme d'observabilité ne fait pas de gestion des changements.

Voici une décomposition fonctionnelle des neuf catégories d'outils qui composent un pipeline de livraison moderne. Chaque catégorie a un travail spécifique qu'aucune autre catégorie ne peut faire à votre place.

Serveur CI : le cerveau du pipeline

Le serveur CI est le moteur qui surveille votre dépôt et exécute votre pipeline automatiquement. Quand un développeur pousse du code, le serveur CI détecte le changement, lance les étapes de construction, exécute les tests et produit un artefact.

Sans serveur CI, chaque changement de code nécessite qu'un développeur récupère manuellement le code, lance la construction et vérifie les résultats. Cela ne passe pas à l'échelle au-delà d'une personne travaillant sur une fonctionnalité.

Le serveur CI coordonne l'ensemble du pipeline. Il décide ce qui s'exécute, dans quel ordre, et ce qui se passe quand une étape échoue. C'est le système nerveux central de votre processus de livraison.

Le diagramme ci-dessous montre comment les neuf catégories d'outils s'articulent dans un pipeline de livraison typique :

Registre d'artefacts : la couche de stockage

Une fois que le serveur CI a terminé la construction, il produit un artefact. Cet artefact a besoin d'un emplacement permanent où les outils de déploiement pourront le retrouver plus tard.

Un registre d'artefacts stocke chaque version de votre build avec des métadonnées : numéro de version, hash de build, dépendances, et parfois les résultats de scans de sécurité. Son travail est simple mais critique : garantir que l'artefact qui a passé tous les tests est le même que celui qui est déployé.

Sans registre, les équipes finissent par reconstruire à partir des sources au moment du déploiement, ce qui introduit des risques. La build qui a été exécutée il y a une heure pourrait produire un résultat différent si les dépendances ont changé ou si l'environnement de construction n'est pas identique.

Outil de déploiement : le moteur de placement

Un outil de déploiement prend un artefact depuis le registre et le place dans un environnement cible. Il lit la configuration de l'environnement, récupère le bon artefact et exécute le processus de déploiement.

Les outils de déploiement gèrent des stratégies comme le blue-green, le canary ou les mises à jour progressives. Ils gèrent la transition de l'ancienne version vers la nouvelle avec un minimum de perturbation.

La distinction clé : les outils de déploiement ne construisent pas d'infrastructure. Ils placent des applications dans une infrastructure qui existe déjà. Si vous devez créer des serveurs, des réseaux ou des ressources cloud d'abord, c'est le travail d'un autre outil.

Outil IaC : le constructeur d'infrastructure

Les outils Infrastructure as Code créent et gèrent votre infrastructure de manière programmatique. Ils définissent les serveurs, bases de données, réseaux, équilibreurs de charge et ressources cloud sous forme de code qui peut être versionné, revu et appliqué de manière cohérente.

Les outils IaC et les outils de déploiement travaillent souvent en séquence. L'outil IaC prépare l'environnement. L'outil de déploiement remplit cet environnement avec l'application. Mélanger ces deux responsabilités conduit à des pipelines fragiles où les changements d'infrastructure sont entremêlés avec les déploiements d'application.

Outil de migration de base de données : le gestionnaire de schéma

Les migrations de base de données sont un type de changement particulier. Elles modifient le schéma dont dépend votre application, et elles doivent s'exécuter dans l'ordre. Exécuter des scripts de migration dans le désordre ou en sauter un peut corrompre vos données.

Un outil de migration suit quelle version du schéma est actuellement appliquée. Il exécute uniquement les migrations qui n'ont pas encore été effectuées. Il sait comment avancer et, dans de nombreux cas, comment revenir en arrière.

Sans outil de migration, les équipes exécutent des scripts SQL manuellement ou intègrent les changements de schéma dans le code de l'application. Les deux approches sont fragiles et sujettes aux erreurs, surtout lorsque plusieurs développeurs travaillent sur la même base de données.

Système de feature flags : le découpleur de release

Les feature flags séparent le déploiement de la mise en production. Vous pouvez déployer du code avec une fonctionnalité désactivée, puis l'activer plus tard pour des utilisateurs, régions ou conditions spécifiques.

Cela vous donne un contrôle granulaire. Une nouvelle fonctionnalité peut d'abord être testée par un petit groupe. Si elle pose problème, vous la désactivez sans annuler tout le déploiement. Si elle fonctionne, vous augmentez progressivement l'audience.

Les feature flags ne sont pas des fichiers de configuration. Ce sont des systèmes de contrôle à l'exécution qui vous permettent de modifier le comportement de l'application sans redéployer.

Gestion des secrets : le coffre-fort d'identifiants

Les secrets sont des mots de passe, clés API, certificats et jetons. Ils doivent être stockés de manière sécurisée et rendus disponibles uniquement aux services qui en ont besoin, au moment où ils en ont besoin.

Un outil de gestion des secrets chiffre les secrets au repos et en transit. Il contrôle l'accès en fonction de l'identité et du contexte. Il fait tourner les identifiants automatiquement et enregistre chaque tentative d'accès.

Codifier en dur des secrets dans des fichiers de configuration ou des variables d'environnement n'est pas de la gestion des secrets. C'est un incident de sécurité qui n'attend que de se produire.

Plateforme d'observabilité : la couche de visibilité

L'observabilité collecte les logs, métriques et traces des systèmes en cours d'exécution. Elle vous donne la capacité de comprendre ce que fait votre application en production.

C'est différent de la surveillance traditionnelle. La surveillance vous dit si un système est opérationnel ou non. L'observabilité vous dit pourquoi un système se comporte comme il le fait. Elle vous aide à déboguer les problèmes, comprendre les performances et détecter les anomalies avant qu'elles ne deviennent des incidents.

Outil de gestion des changements : la piste d'audit

Chaque changement qui passe par votre pipeline laisse une trace. Un outil de gestion des changements enregistre qui a fait le changement, ce qui a été changé, quand cela s'est produit et pourquoi.

C'est essentiel pour la gouvernance et la conformité. Quand quelque chose tourne mal, vous devez savoir exactement ce qui a changé et qui l'a approuvé. Sans outil de gestion des changements, vous comptez sur la mémoire, les logs de chat ou les feuilles de calcul.

Liste de vérification pratique

Avant d'ajouter un nouvel outil à votre pipeline, posez-vous ces questions :

• À quelle catégorie cet outil appartient-il ?
• Ai-je déjà un outil dans cette catégorie ?
• Le nouvel outil chevauche-t-il une fonction d'un outil existant ?
• Si oui, lequel devrait posséder cette fonction ?

L'essentiel à retenir

Les outils ne sont pas interchangeables. Un serveur CI ne peut pas faire de déploiement. Un outil de déploiement ne peut pas gérer les secrets. Un registre d'artefacts ne peut pas exécuter de migrations. Quand vous comprenez la fonction, pas seulement le nom, vous arrêtez de deviner quel outil fait quoi. Vous construisez des pipelines qui sont clairs, maintenables et qui fonctionnent réellement quand quelque chose tourne mal.