Déployer en production à chaque modification peut faire peur, mais ne pas déployer directement en production est encore plus effrayant.
C'est le processus que j'ai mis en œuvre chez Amazon, où je dirigeais une équipe qui déployait pour des centaines de millions de clients. Grâce à mon activité de conseil, j'ai accompagné des équipes d'ingénieurs qui sont passées de déploiements planifiés toutes les deux semaines à un déploiement à chaque merge.
Commençons par l'évidence :
Vous provoquerez un incident. Ce n'est pas une question de « si », mais de « quand ».
Aucune quantité de tests unitaires, de tests d'intégration, de dogfooding, de tests de bout en bout, ou de sacrifices aux dieux du déploiement ne permettra de détecter tous les bugs.
Les tests effectués sur votre fonctionnalité il y a une semaine n'ont pas été réalisés avec les derniers changements de votre collègue.
Vos tests ont été exécutés contre la version pré-production du service de vos collègues, qui a depuis changé et contient désormais une modification incompatible avec les versions précédentes.
Plus vous attendez, plus les changements s'accumulent dans une release. Si vous devez faire un rollback, vous devez alors revenir sur deux semaines de changements plutôt que sur une à deux heures de travail.
Si l'on accepte le postulat qu'un incident est inévitable, il devient beaucoup moins pertinent de consacrer des ressources massives au QA d'une release. Mieux vaut concentrer nos ressources sur la surveillance et l'observation d'une release, et être prêts à gérer un incident lorsqu'il survient.
Passons maintenant à la mise en œuvre :
Prérequis :
CI/CD
Les tests comptent beaucoup moins que ce que l'on pourrait croire. Les tests ne peuvent pas prouver que votre changement est sûr en production. Rien ne le peut. Ce que les tests font, c'est rendre l'échec peu coûteux. Un bug détecté dans la CI coûte quelques minutes. Un bug détecté en production vous coûte votre soirée à faire un rollback.
Exécutez donc toute la suite de tests à chaque merge, ou au moins dans le cadre du pipeline : tests unitaires, d'intégration, de bout en bout. Plus le bug descend loin dans le pipeline, plus il coûte cher à résoudre.
Surveillance / Observabilité
Le but du jeu est de détecter une régression le plus rapidement possible. Pour y parvenir, vous avez besoin d'une excellente surveillance. Cela se concrétise par :
- des métriques : erreurs, latence, disponibilité
- des logs avec des identifiants de corrélation
- des alarmes pour les niveaux sev-3 et sev-2 (paging) branchées sur les deux points ci-dessus
Le réglage des seuils d'alarme relève un peu de l'art et de la science. C'est un équilibre entre sensibilité et rapidité de réaction lors d'un véritable incident. Votre objectif de délai d'alerte sev-2 devrait être de 5 à 10 minutes.
Au début, vous aurez probablement tort, et vos alarmes seront probablement trop sensibles. Malheureusement, cela s'apprend surtout par essais et erreurs, alors attendez-vous à quelques réveils à 2 h du matin.
Feature Flags
Pour tout changement comportant un risque, vous devriez le déployer derrière un feature flag / une configuration à distance. Un feature flag vous permet de faire un rollback et de désactiver n'importe quel changement en quelques minutes, plutôt que de devoir annuler l'intégralité du déploiement. De plus, si votre service de feature flags le permet (et il le devrait), vous pouvez déployer la fonctionnalité de manière progressive, par pourcentage ou par cohorte, ce qui réduit encore l'impact d'un changement défectueux.
Cela nous permet de découpler le déploiement du code et l'activation du code. C'est subtil, mais cela change radicalement la donne en matière de réduction des risques.
Remarque : vous aurez besoin d'un processus pour les nettoyer. Idéalement, créez un ticket de suppression pour chaque flag créé. Sinon, lorsque votre service de feature flags tombera en panne (et il tombera), vous aurez une régression significative. Demandez-moi comment je le sais.
Rollback automatique (disjoncteur au moment du déploiement)
Un disjoncteur au moment du déploiement est une fonctionnalité qui vous permet de faire un rollback du déploiement si vous observez un nombre ou un pourcentage d'erreurs pendant le déploiement sur l'ensemble du parc de machines. La plupart des fournisseurs cloud proposent cela avec une simple case à cocher.
Changements rétrocompatibles
Vous devriez déjà le faire, mais déployer à chaque commit impose cette pratique. Lors d'un déploiement progressif, l'ancienne version et la nouvelle version tournent en même temps. Chaque changement doit fonctionner aux côtés de la version précédente. Votre astuce de déployer à minuit pour éviter cela ne fonctionne plus.
Stratégies de déploiement
Maintenant que tout cela est en place, nous pouvons passer en revue différentes stratégies de déploiement qui peuvent aider à réduire les risques lors du déploiement de vos changements.
Déploiement one box (canary)
Un déploiement one box déploie vos changements sur une seule machine du parc. Cela permet de réduire l'impact de tout changement défectueux à un seul hôte.
Vous déployez et laissez tourner pendant un certain temps, en recevant une petite fraction du trafic global. Vous avez configuré votre surveillance et vos alertes sur cette machine, qui vous alerteront si quelque chose se casse.
Déploiements progressifs
Un déploiement progressif vous permet de déployer par pourcentage au fil du temps, de sorte que s'il y a une erreur catastrophique, vous la détectiez avant qu'elle n'affecte toutes les machines, et vous puissiez alors commencer à faire un rollback.
Déploiement par région
À mesure que votre entreprise grandit, vous finirez par avoir des déploiements multi-régions. Plutôt que de déployer simultanément sur toutes ces régions, vous pouvez d'abord déployer sur une région spécifique (généralement celle avec le moins de trafic).
Cas où cela ne s'applique pas
App Store
Publier une application mobile n'est pas totalement compatible avec ces recommandations. La file de revue de l'App Store freine votre cadence de déploiement et nécessite une stratégie différente.
Environnements certifiés
Dispositifs médicaux, avionique, contrôle industriel, etc. Vous ne pouvez pas faire de déploiement continu si un régulateur doit certifier la build.
Sur site / Auto-hébergé
Vous ne contrôlez pas la mise à niveau. Vous pouvez toujours déployer en continu sur tout ce que vous opérez, mais vous devez versionner chaque changement et c'est votre client qui détermine quand il est adopté.
Par où commencer
Ne faites pas tout cela d'un coup. L'ordre compte :
- Rendez la CI verte et rapide. Idéalement en moins de 15 minutes.
- Mettez en place des métriques et des alarmes sur le taux d'erreur, la latence et la disponibilité. C'est la partie la plus importante de l'exercice.
- Placez tout changement risqué derrière un flag.
- Ajoutez le one box + le rollback automatisé.
- Supprimez le calendrier des releases.
- Trouvez une nouvelle utilité à tout votre temps libre, puisque vous ne planifiez plus les releases.
La plupart des équipes avec lesquelles j'ai travaillé mettent environ un trimestre pour y arriver. Les outils sont la partie facile. Le processus organisationnel et le fait de briser l'illusion que les releases planifiées sont sûres, c'est la partie difficile.
Si votre équipe est sur un calendrier de releases et souhaite en sortir, c'est exactement le travail que je fais. Envoyez-moi un DM.
