Livrer souvent sans casser la production repose sur quatre décisions : comment l'équipe organise ses branches, comment une version en remplace une autre, comment on la cache ou la montre aux utilisateurs, et comment l'état voulu arrive sur les serveurs. Cette section consacre un guide à chacune. Elle s'adresse aux développeurs et aux équipes ops débutants ou intermédiaires qui ont déjà une pipeline d'intégration continue et veulent fiabiliser ce qui vient après.
Quelle question commune traitent ces quatre guides ?
Section intitulée « Quelle question commune traitent ces quatre guides ? »Les quatre répondent à « comment livrer sans casser ». Chacun réduit un risque différent, et c'est leur combinaison qui permet de déployer souvent. Un déploiement risqué ne devient anodin que lorsqu'il est petit, réversible et progressif.
Ces guides prennent la suite de la différence entre intégration continue, livraison continue et déploiement continu, posée dans CI, Continuous Delivery, Continuous Deployment : quel niveau choisir ?, et de la discipline de test décrite dans Stratégies de tests : le filet de sécurité du DevOps. Sans tests fiables, aucune des techniques ci-dessous ne vous protège.
Dans quel ordre les lire ?
Section intitulée « Dans quel ordre les lire ? »Le fil suit la vie d'un changement, du commit à la production. Trunk-Based Development et modèles de branches Git vient en premier, parce que la taille des changements se décide dans les branches : le guide compare le trunk based, GitFlow, GitHub Flow et GitLab Flow, puis explique comment adopter des branches éphémères et désamorcer les objections. Plus le changement est petit, plus il se livre sans risque.
Stratégies de déploiement : blue-green, canary, rolling répond ensuite à la question du remplacement. Il passe en revue le recreate, le rolling update, le blue-green, le canary, le shadow traffic et la progressive delivery, donne une matrice de décision et s'arrête sur le point dur : les migrations de base de données, qui compliquent le retour arrière.
Feature Flags : découpler déploiement et release pousse la logique plus loin : le code est déployé, mais la fonction n'est visible qu'une fois le flag activé, pour une cohorte ou pour tout le monde, et se coupe sans redéployer. Le guide distingue les quatre types de flags et leurs durées de vie, la dette de flags à nettoyer, et l'outillage autour du standard OpenFeature.
Reste à acheminer l'état voulu jusqu'aux serveurs. GitOps : principes, ArgoCD vs Flux et mise en œuvre fait de Git la source de vérité : une pull request modifie l'état déclaré, un opérateur l'applique et corrige les dérives. Le guide présente les quatre principes, la stratégie pull face au push, et le choix entre ArgoCD et Flux.
Que saurez-vous décider à la fin ?
Section intitulée « Que saurez-vous décider à la fin ? »Vous saurez choisir un modèle de branches adapté à la taille de votre équipe, une stratégie de déploiement selon votre tolérance à l'arrêt, votre budget et votre observabilité, et décider quand activer une fonction par feature flag plutôt que par un déploiement. Vous saurez aussi expliquer comment un déploiement piloté par Git se défait d'un git revert.
Les guides se renforcent sans se dupliquer : le trunk based s'appuie sur les flags, les stratégies progressives s'appuient sur la mesure, GitOps rend le tout traçable. Chacun reste lisible seul pour un lecteur qui cherche une réponse précise, mais le fil ci-dessus évite de découvrir une technique avant le problème qu'elle résout.