Pourquoi il ne faut pas essayer de tout construire en même temps
Lorsqu'une équipe commence à parler de CI/CD, l'image qui vient souvent à l'esprit est une transformation massive. Chaque application a besoin d'un pipeline. Les bases de données doivent être automatisées. L'infrastructure doit être déclarée comme du code. Tous les environnements doivent être identiques. Et tout doit être terminé en même temps.
Cette image est intimidante, et elle devrait l'être. Parce que quand on essaie de tout faire à la fois, le résultat le plus probable n'est pas une transformation. C'est le chaos.
Pensez à tout ce que vous devriez changer d'un seul coup : comment les développeurs envoient le code, comment l'équipe base de données gère les migrations de schéma, comment l'infrastructure provisionne les serveurs, comment le QA exécute les tests, comment les release managers approuvent les déploiements, et comment tout le monde suit ce qui a changé. Tout cela se produit pendant que votre application existante continue de servir les utilisateurs.
C'est ce qu'on appelle une transformation big bang. Le nom semble monumental, mais en pratique, cela se termine généralement par un échec retentissant. Trop de choses changent à la fois. Trop de variables échappent à tout contrôle. Et quand quelque chose casse, personne ne sait où chercher parce que tout est nouveau.
Une approche graduelle semble moins spectaculaire, mais elle est bien plus réaliste. Au lieu de tout changer à la fois, vous choisissez une partie qui a la plus grande chance de succès, vous la terminez, vous en tirez des leçons, et vous passez à la partie suivante.
La différence entre ces deux chemins est claire quand on les voit côte à côte :
Pourquoi le graduel fonctionne mieux que le big bang
Chaque équipe a un point de départ différent. Une équipe peut avoir une application en production mais déployer encore manuellement. Une autre peut avoir des pipelines pour son application mais gérer encore les bases de données en SSH directement sur les serveurs. Une troisième peut avoir une infrastructure automatisée mais n'avoir jamais écrit un seul test automatisé pour son application.
Il n'existe pas de plan unique qui convienne à toutes les équipes. Essayer de copier le plan de quelqu'un d'autre en bloc se termine généralement par des ajustements douloureux. L'approche graduelle respecte le point de départ réel de votre équipe. Elle vous permet de construire à partir de là où vous êtes, et non de là où quelqu'un d'autre pense que vous devriez être.
Une approche graduelle vous donne aussi la place pour apprendre. Chaque étape produit une expérience réelle : comment le pipeline se comporte avec le code de votre équipe, comment votre base de données réagit aux migrations automatisées, comment votre infrastructure répond aux changements de configuration. Cette expérience vaut plus que n'importe quelle documentation ou théorie sur les outils, car elle vient directement de votre propre contexte.
Le risque est une autre raison d'avancer pas à pas. Quand une seule partie change et que quelque chose tourne mal, vous savez exactement où chercher. Quand tout change à la fois, le problème peut venir de n'importe où. Votre équipe passe du temps à chercher la cause au lieu de corriger l'impact.
Enfin, le changement graduel est plus facile à accepter pour les gens. Les transformations massives créent des résistances parce que les gens sont à l'aise avec leurs habitudes. Mais quand le changement se fait par petites étapes, chaque étape semble plus légère. L'équipe voit les résultats, ressent les bénéfices, et devient plus ouverte à l'étape suivante.
Comment trouver votre première étape
La partie la plus difficile est de décider par où commencer. Beaucoup d'équipes restent bloquées ici parce qu'elles essaient de planifier l'ensemble de la feuille de route avant de passer à l'action. C'est une erreur. Vous n'avez pas besoin d'une carte complète. Vous avez besoin d'une étape claire qui apporte de la valeur.
Commencez par regarder votre processus de livraison actuel. Trouvez la partie qui cause le plus de douleur ou qui prend le plus de temps. C'est généralement un bon candidat pour votre première étape.
Voici quelques points de départ courants :
- Si le déploiement en production nécessite une checklist manuelle qui prend des heures, commencez par automatiser le déploiement d'un service non critique.
- Si les changements de base de données sont appliqués à la main et causent souvent des incidents en production, commencez par automatiser les migrations de schéma pour une base de données à faible risque.
- Si votre équipe passe des jours à tester manuellement chaque release, commencez par écrire des tests automatisés pour les flux utilisateur les plus critiques.
- Si les changements d'infrastructure passent par des tickets qui prennent des semaines, commencez par déclarer un élément d'infrastructure comme du code.
La clé est de choisir quelque chose d'assez petit pour être terminé dans un délai raisonnable, mais assez significatif pour que l'équipe ressente l'amélioration.
À quoi ressemble une feuille de route graduelle typique
Une feuille de route graduelle ne signifie pas que vous planifiez chaque étape à l'avance. Cela signifie que vous connaissez votre direction et que vous avancez une étape à la fois.
Une séquence typique pourrait ressembler à ceci :
- Automatiser la construction et le déploiement d'une application. Garder tout le reste manuel.
- Ajouter des tests automatisés pour les chemins les plus critiques de cette application.
- Étendre le pipeline pour inclure les migrations de base de données pour cette application.
- Appliquer le même schéma à une deuxième application, en ajustant en fonction de ce que vous avez appris.
- Déplacer progressivement le provisionnement de l'infrastructure dans le pipeline.
- Ajouter des capacités de surveillance et de rollback.
- Étendre aux applications restantes.
Remarquez que chaque étape s'appuie sur la précédente. Vous ne passez pas du déploiement manuel à l'automatisation complète de l'infrastructure en une seule fois. Vous laissez chaque étape informer la suivante.
Checklist pratique pour votre première étape
Avant de commencer, parcourez cette checklist rapide :
- Pouvez-vous identifier une application ou un service à faible risque et non critique ?
- Avez-vous une définition claire de ce à quoi ressemble "terminé" pour cette étape ?
- Y a-t-il quelqu'un dans l'équipe qui peut prendre en charge cette étape et la mener à bien ?
- Avez-vous communiqué à l'équipe qu'il s'agit d'une expérience, pas d'un changement de processus permanent ?
- Avez-vous un moyen de revenir en arrière si quelque chose tourne mal ?
Si vous pouvez répondre oui à ces questions, vous êtes prêt à commencer. Sinon, prenez le temps de clarifier ces points d'abord.
L'essentiel à retenir
Vous n'avez pas besoin de tout transformer à la fois. Vous avez besoin d'une étape fonctionnelle que votre équipe peut voir, toucher et dont elle peut apprendre. Commencez là. Laissez l'étape suivante émerger de ce que vous découvrez. L'équipe qui apprend progressivement construit des pratiques qui durent. L'équipe qui essaie de tout changer à la fois finit généralement par tout reconstruire depuis le début.