Ce que nous avons construit ensemble : une compréhension pratique du CI/CD

Tout a commencé par une question simple : comment amener les modifications de votre application, de votre base de données et de votre infrastructure là où les utilisateurs les utilisent réellement, sans casser leur expérience ?

Cette question est plus difficile qu'il n'y paraît. Chaque équipe avec laquelle j'ai travaillé a ressenti la tension entre livrer vite et livrer en toute sécurité. Certaines équipes la résolvent avec des cérémonies élaborées. D'autres avec des scripts qu'une seule personne comprend. Aucune des deux approches ne passe à l'échelle, et toutes deux génèrent de l'anxiété à chaque déploiement.

Cet article parcourt les fondations que nous avons construites ensemble dans le livre. Ce n'est pas un résumé de chapitres. C'est une carte de la façon dont les pièces s'assemblent lorsque vous cessez de traiter le CI/CD comme un outil et commencez à le traiter comme une capacité.

Commencez par le déploiement, pas par le pipeline

Avant de pouvoir automatiser quoi que ce soit, vous devez comprendre ce que signifie réellement le déploiement. Le déploiement est l'action de placer une nouvelle version de quelque chose dans un environnement où les utilisateurs peuvent y accéder. Cela semble évident, mais les implications ne le sont pas.

Si vous déployez une mauvaise version d'une application, vous pouvez la remplacer entièrement. Si vous déployez une mauvaise migration de base de données, les données sont toujours là, et le retour en arrière est plus complexe. Si vous déployez des modifications d'infrastructure qui cassent le réseau, rien d'autre ne fonctionne.

Ces trois éléments — applications, bases de données et infrastructure — ne peuvent pas être traités de la même manière. Chacun a sa propre stratégie de déploiement. Les applications fonctionnent bien avec le déploiement blue-green, où vous basculez le trafic entre deux environnements identiques. Les bases de données nécessitent une migration progressive, où les modifications sont appliquées par petites étapes réversibles. L'infrastructure bénéficie d'une approche immuable, où vous remplacez des environnements entiers au lieu de les corriger.

Le diagramme ci-dessous montre les trois pistes parallèles et leurs stratégies recommandées :

Le but n'est pas de mémoriser ces stratégies. Le but est de reconnaître que le déploiement n'est pas une action unique. C'est un ensemble de décisions sur la façon de déplacer les modifications en toute sécurité, et ces décisions dépendent de ce que vous déplacez.

Le pipeline comme contrat, pas comme script

Une fois que vous comprenez le déploiement, vous pouvez construire un pipeline. Mais un pipeline n'est pas un script qui exécute des commandes. Un pipeline est un contrat que chaque modification doit passer par les mêmes vérifications, dans le même ordre, dans un environnement cohérent, avant d'atteindre la production.

Cette distinction est importante car les équipes traitent souvent les pipelines comme une automatisation de leur processus manuel existant. Si le processus manuel a des lacunes, le pipeline automatisera également ces lacunes. Un bon pipeline part de la question : que doit être vrai à propos d'une modification avant qu'elle n'atteigne les utilisateurs ?

Pour les modifications d'application, la réponse peut inclure la réussite des tests unitaires, des tests d'intégration et des scans de sécurité. Pour les modifications de base de données, cela peut inclure la vérification que les migrations sont réversibles et que les scripts de rollback existent. Pour les modifications d'infrastructure, cela peut inclure l'exécution d'une validation sur un environnement de staging en direct.

Construire un pipeline pour les trois types de modifications simultanément est le véritable défi. La plupart des équipes commencent par un et ajoutent les autres plus tard. C'est très bien, tant que vous savez lequel vous manquez et pourquoi.

Déployer n'est pas mettre à disposition

L'une des distinctions les plus utiles dans le livre est la séparation entre déployer et mettre à disposition.

Déployer, c'est mettre une nouvelle version sur le serveur. Mettre à disposition, c'est faire en sorte que cette version soit réellement utilisée par les utilisateurs. Lorsque vous séparez ces deux actions, vous gagnez le contrôle sur le risque. Vous pouvez déployer une version, la tester en production avec des utilisateurs internes, et ne la mettre à disposition de tout le monde que lorsque vous êtes confiant.

Cette séparation est ce qui permet des stratégies comme les feature flags, les canary releases et la livraison progressive. Les feature flags vous permettent d'activer ou de désactiver des fonctionnalités sans redéployer. Les canary releases envoient d'abord un petit pourcentage de trafic vers la nouvelle version. La livraison progressive augmente ce pourcentage progressivement à mesure que vous observez les métriques.

Aucune de ces stratégies ne nécessite un outil spécifique. Elles nécessitent un état d'esprit qui traite le déploiement et la mise à disposition comme des décisions distinctes, chacune avec son propre profil de risque.

L'ingénierie de plateforme comme accélérateur

Lorsque vous avez plusieurs équipes qui livrent des modifications via des pipelines, vous commencez à voir des schémas. Chaque équipe a besoin des mêmes choses de base : un moyen de construire, tester et déployer ses modifications ; des environnements cohérents pour exécuter ces tests ; et un accès en libre-service à l'infrastructure.

L'ingénierie de plateforme est la pratique qui consiste à construire ces capacités en tant que produits internes. Une plateforme n'est pas un grand projet qui doit être terminé avant que quiconque ne l'utilise. Une plateforme part d'un besoin réel qu'une équipe a, le résout bien, puis s'étend à mesure que d'autres besoins émergent.

La clé ici est que l'ingénierie de plateforme ne consiste pas à construire l'abstraction parfaite. Il s'agit de réduire la charge cognitive des équipes afin qu'elles puissent se concentrer sur la livraison de valeur. Si une équipe passe deux jours à configurer un pipeline, la plateforme ne fonctionne pas. Si elle peut créer un nouveau service avec une seule pull request, la plateforme fonctionne.

La gouvernance comme garde-fous, pas comme barrières

La gouvernance est souvent mal comprise comme une couche qui ralentit les choses. En pratique, la gouvernance dans le CI/CD consiste à définir des limites qui permettent aux équipes d'aller vite sans casser les choses.

Les politiques de revue pour les modifications de production, les pistes d'audit automatisées et les règles de déploiement basées sur le risque servent toutes le même objectif : elles créent un chemin clair pour que les modifications suivent, afin que les équipes n'aient pas à deviner ce qui est autorisé ou à attendre une approbation manuelle à chaque fois.

La différence entre la gouvernance comme barrière et la gouvernance comme garde-fou est subtile mais importante. Une barrière bloque les modifications jusqu'à ce que quelqu'un les approuve. Un garde-fou définit le chemin sûr et laisse les équipes se déplacer librement à l'intérieur. La première crée des goulots d'étranglement. La seconde crée de l'autonomie.

Une liste de vérification pratique

Si vous construisez une capacité CI/CD dans votre organisation, voici une courte liste de vérification pour guider vos décisions :

• Pouvez-vous déployer une modification en production sans étapes manuelles ?
• Pouvez-vous annuler un déploiement en moins de cinq minutes ?
• Connaissez-vous la différence entre votre stratégie de déploiement et votre stratégie de mise à disposition ?
• Chaque modification passe-t-elle par les mêmes vérifications, quel que soit son auteur ?
• Un nouveau membre de l'équipe peut-il déployer sa première modification le premier jour sans demander d'autorisations ?
• Avez-vous un moyen de tester les migrations de base de données avant qu'elles n'atteignent la production ?
• Votre infrastructure est-elle traitée comme du code, et non comme un serveur unique et fragile ?

Si vous avez répondu non à l'une de ces questions, vous savez sur quoi vous concentrer ensuite.

Le CI/CD est une capacité que vous entretenez

La leçon la plus importante de ce voyage est que le CI/CD n'est pas un projet que vous terminez. C'est une capacité que vous entretenez. Les outils changent. Les équipes grandissent. Les exigences évoluent. Les pratiques qui fonctionnent aujourd'hui peuvent ne pas fonctionner l'année prochaine.

Ce qui reste constant, c'est la compréhension que livrer des modifications en toute sécurité est une compétence, pas un script. Elle se construit à partir de petites décisions prises chaque jour : comment vous structurez vos tests, comment vous gérez les échecs, comment vous équilibrez vitesse et sécurité. Ces décisions s'accumulent avec le temps, et elles déterminent si votre équipe livre avec confiance ou avec peur.

Commencez par une modification. Rendez-la sûre. Puis rendez-la reproductible. Puis rendez-la rapide. Le reste suivra.