Que faire après un déploiement : Promouvoir, Suspendre, Revenir en arrière, Avancer, Mettre en pause ou Désactiver

Le déploiement vient de se terminer. Votre nouvelle version est en production, elle sert du trafic réel. Le pipeline est vert, les logs s'écoulent, et vos tableaux de bord de monitoring s'animent avec des données fraîches. Et maintenant ?

Ce moment entre le déploiement et la déclaration de succès est celui où la plupart des équipes se retrouvent bloquées. Certaines se précipitent pour déclarer la tâche terminée et passer à autre chose. D'autres se figent, incertaines de savoir si ce qu'elles observent est une fluctuation normale ou le début d'un désastre. La réalité est qu'un déploiement terminé n'est pas une décision, c'est le début d'une décision.

Une fois que les signaux d'observabilité commencent à arriver, vous avez six chemins possibles. Chacun correspond à une situation différente et a des conséquences différentes. Savoir lequel choisir, et quand, distingue les équipes qui gèrent les déploiements avec confiance de celles qui espèrent simplement que tout se passe bien.

Promouvoir : la version est bonne

Promouvoir signifie que vous déclarez la nouvelle version comme la version de production officielle. Tout le trafic reste sur celle-ci, et l'ancienne version peut être archivée ou supprimée. C'est le résultat que tout le monde souhaite, mais il ne faut jamais se précipiter simplement parce que le pipeline est passé.

Vous promouvez lorsque tous les signaux d'observabilité restent dans les limites de vos SLO. Les taux d'erreur sont normaux, la latence n'a pas grimpé, le budget d'erreur est toujours sain, et vos tests de fumée ont réussi en production. Les données confirment ce que le pipeline suggérait : cette version est sûre.

Le piège ici est de promouvoir trop tôt. Un pipeline vert signifie que la construction et les tests ont réussi, mais cela ne signifie pas que le comportement en production est vérifié. Laissez à la nouvelle version suffisamment de temps pour accumuler des données significatives avant de la déclarer terminée. Ce qui semble stable après deux minutes peut révéler des problèmes après dix minutes.

Suspendre : pas encore confiant

Suspendre signifie que la nouvelle version continue de tourner, mais vous ne la déclarez pas encore comme version officielle. Vous attendez plus de données. Peut-être que le trafic monte encore en charge, ou vous voyez une petite anomalie qui pourrait être du bruit ou le début de quelque chose de plus grave.

Suspendre est le juste milieu sécurisé. Vous ne paniquez pas, mais vous ne célébrez pas non plus. La version continue de servir du trafic pendant que vous observez les tendances. La conséquence principale est que vous ne pouvez pas lancer le prochain déploiement tant que celui-ci n'est pas résolu. Suspendre bloque le pipeline, et c'est intentionnel : cela force l'équipe à enquêter avant d'empiler d'autres changements sur une incertitude.

Cette option fonctionne bien lorsque vous avez l'intuition que quelque chose cloche, mais sans preuve solide encore. Faites confiance à cette intuition. Si les données ne disent pas clairement « promouvoir », ne forcez pas.

Revenir en arrière : retourner à ce qui fonctionnait

Revenir en arrière signifie revenir à la version stable précédente. Vous retirez la nouvelle version et remettez l'ancienne aux commandes. Cela ressemble à un échec, mais ce n'en est pas un. C'est une retraite contrôlée face à une mauvaise situation.

Vous revenez en arrière lorsque les taux d'erreur dépassent vos SLO, que le budget d'erreur se consume plus vite que prévu, ou qu'une défaillance critique est détectée. Les critères sont clairs et objectifs. Si les chiffres disent que la nouvelle version est pire que l'ancienne, n'hésitez pas.

Le hic, c'est que revenir en arrière ne fonctionne que si vous vous y êtes préparé. Le mécanisme doit être testé avant l'urgence, pas conçu pendant celle-ci. Des changements de base de données qui ne sont pas rétrocompatibles peuvent rendre le retour en arrière impossible, c'est pourquoi l'option d'avancer existe comme alternative.

Avancer : corriger vers l'avant plutôt que de revenir en arrière

Avancer signifie que vous gardez la version actuelle en cours d'exécution, mais vous commencez immédiatement à construire une nouvelle version qui corrige le problème. Au lieu de revenir en arrière, vous poussez un correctif par-dessus la version défectueuse.

Cette option a du sens lorsque le problème est mineur et que votre équipe peut produire un correctif rapidement. C'est aussi le seul choix lorsque le retour en arrière est impossible - par exemple, lorsqu'une migration de base de données a modifié le schéma d'une manière que l'ancien code ne peut pas gérer.

Avancer nécessite d'avoir confiance que le correctif fonctionnera réellement. Si vous devinez, vous pourriez empirer les choses. Cela met également la pression sur l'équipe pour livrer rapidement, ce qui peut conduire à des décisions précipitées. Utilisez l'option d'avancer lorsque la voie est claire, pas lorsque vous espérez le meilleur.

Mettre en pause : arrêter et enquêter

Mettre en pause signifie que vous arrêtez le processus de déploiement sans modifier ce qui est actuellement en cours d'exécution. La nouvelle version reste en place, mais aucun autre déploiement ne peut avoir lieu tant que l'enquête n'est pas terminée.

Utilisez la pause lorsque vous voyez quelque chose d'étrange mais pas assez grave pour justifier un retour en arrière. La latence augmente légèrement dans une région. Les taux d'erreur grimpent mais restent dans les SLO. Un seul point d'accès montre un comportement inhabituel alors que tout le reste semble normal.

La pause vous donne du temps pour comprendre ce qui se passe avant de prendre une décision plus importante. Elle empêche l'équipe de faire un retour en arrière précipité qui pourrait ne pas être nécessaire, ou une promotion précipitée qui pourrait être prématurée. Le coût est que le pipeline est bloqué, mais c'est un petit prix à payer comparé à une mauvaise décision.

Désactiver : éteindre la partie défaillante

Désactiver signifie que vous désactivez une fonctionnalité ou une capacité spécifique sans revenir sur l'ensemble de la version. Cela nécessite des feature flags ou un autre mécanisme pour activer/désactiver des capacités individuelles de manière indépendante.

C'est l'intervention la plus légère. Si une seule fonctionnalité pose problème - un nouvel algorithme de recherche, un flux de paiement redessiné, un point d'accès API modifié - vous pouvez désactiver cette fonctionnalité tout en gardant tout le reste en fonctionnement. Les utilisateurs perdent l'accès à cette fonctionnalité, mais le reste de l'application continue normalement.

Désactiver est plus rapide et plus sûr qu'un retour en arrière lorsque le problème est isolé. Cela donne également à l'équipe le temps de corriger la fonctionnalité spécifique sans perturber l'ensemble du déploiement. La condition préalable est que votre architecture prenne en charge des bascules granulaires, ce qui vaut la peine d'investir si vous déployez fréquemment.

Comment choisir

La bonne décision dépend de trois choses : la gravité du problème, le budget d'erreur qu'il vous reste, et la rapidité avec laquelle votre équipe peut réagir. Les équipes qui ont défini des SLO et qui suivent le budget d'erreur disposent d'une base objective pour ces décisions. Si le budget d'erreur est presque épuisé, même une petite anomalie peut justifier un retour en arrière. Si le budget d'erreur est abondant, vous pouvez choisir de suspendre ou de mettre en pause pour enquêter davantage.

L'arbre de décision suivant fait correspondre vos signaux d'observabilité à l'action appropriée :

flowchart TD A[Déploiement terminé, données de monitoring disponibles ?] -->|Oui| B{Tous les signaux dans les SLO ?} A -->|Non| C[Attendre les données, puis réévaluer] B -->|Oui| D{Budget d'erreur presque épuisé ?} B -->|Non| E{Problème isolé à une fonctionnalité ?} D -->|Non| F[Promouvoir] D -->|Oui| G{Suspendre ou Revenir en arrière ?} G -->|Suspendre| H[Suspendre] G -->|Revenir en arrière| I[Revenir en arrière] E -->|Oui| J[Désactiver] E -->|Non| K{Peut-on revenir en arrière en sécurité ?} K -->|Oui| I K -->|Non| L{Correctif prêt pour avancer ?} L -->|Oui| M[Avancer] L -->|Non| N[Mettre en pause]

Ce que vous voulez éviter, c'est de prendre ces décisions uniquement sur la base de votre intuition. Quand les données sont claires, la voie est claire. Quand les données ne sont pas claires, suspendez ou mettez en pause jusqu'à ce qu'elles le deviennent.

Liste de contrôle pratique pour les décisions de déploiement

  • Avez-vous attendu suffisamment longtemps pour que des données d'observabilité significatives s'accumulent ?
  • Tous les signaux sont-ils dans les limites des SLO, ou y a-t-il une anomalie qui nécessite une enquête ?
  • Disposez-vous d'un mécanisme de retour en arrière testé et prêt, ou êtes-vous bloqué par des changements de base de données ?
  • Le problème est-il isolé à une fonctionnalité qui peut être désactivée indépendamment ?
  • Votre équipe a-t-elle la capacité de construire un correctif rapidement si vous choisissez d'avancer ?
  • Le pipeline est-il bloqué par une suspension ou une pause, et tout le monde sait-il pourquoi ?

L'essentiel à retenir

Un déploiement n'est pas terminé lorsque le code est en cours d'exécution. Il est terminé lorsque vous avez suffisamment de données pour prendre une décision confiante sur la suite. Les six options - promouvoir, suspendre, revenir en arrière, avancer, mettre en pause et désactiver - vous donnent un vocabulaire pour cette décision. Utilisez-les délibérément, en vous basant sur des signaux, pas sur des suppositions. La version que vous déployez n'est pas la réponse finale. La décision que vous prenez après l'avoir vue fonctionner l'est.