Résumé
La plupart de ce qui s’écrit sur le déploiement Blue/Green répète la définition ou déroule un service hello-world sans rapport avec le terrain. J’ai écrit cet article pour lister ce qu’il faut réellement décider avant qu’un pipeline Blue/Green puisse réussir.
La première décision est le périmètre. Le Blue/Green s’applique à un composant, et à une version de ce composant, pas à un environnement entier. Dupliquer toute la pile, répartiteurs de charge, base de données, cache, stockage, frontend et backend dans un seul pipeline est un anti-pattern qui mène à une complexité ingérable et à des données désynchronisées; dupliquer un cluster Kubernetes pour cela est hors de question. Des composants différents peuvent même suivre des stratégies différentes: Blue/Green ou rolling update pour la migration de la base, canary pour le backend.
Viennent ensuite les questions que les tutoriels sautent. Si le premier déploiement et les mises à jour suivantes partagent un même pipeline. La rétrocompatibilité de tout ce qui persiste, schémas, fichiers, propriétés et topics d’événements, sans laquelle le retour arrière est impossible; supprimer logiquement d’abord, physiquement quelques versions plus tard. Les sessions stockées hors de l’application, dans un cache ou une base, pour que la bascule ne déconnecte personne. Qui décide de décommissionner Blue, et sur quel déclencheur, sachant que la plupart des projets reposent sur une recette métier manuelle plutôt que sur des tests fonctionnels complets. Et comment revenir sur Blue tant que les deux environnements existent encore.
Aucune de ces questions n’est seulement technique. Elles demandent que le métier, le développement et l’exploitation s’accordent sur les exigences, composant par composant, avant que quiconque n’écrive un pipeline.
Idées clés
- Le Blue/Green s’applique à un composant et à sa version, pas à un environnement; mélanger tous les concepts dans un seul pipeline est un anti-pattern.
- Toute stratégie de déploiement sauf recreate garde le service disponible; ce que le Blue/Green exige en retour, c’est un chemin de retour arrière qui existe encore.
- La persistance doit rester rétrocompatible, schémas, fichiers, propriétés et topics compris: supprimer logiquement maintenant, physiquement quelques versions plus tard.
- Garder les sessions hors de l’application, dans un cache ou une base, pour qu’un changement de version ne déconnecte personne.
- Décommissionner Blue est une décision commune du métier, du développement et de l’exploitation, sur un déclencheur qu’ils choisissent: automatique, manuel, événement ou heure.
Pourquoi j’ai écrit cet article
La littérature propose beaucoup d’articles qui avancent la définition du Blue/Green ou expliquent très brièvement la mise en œuvre d’un service hello-world déconnecté de la réalité du terrain. L’objectif de cet article est de faire ressortir les éléments à identifier pour réussir cette stratégie.