TOC

Comment utiliser les déploiements Blue-Green pour commercialiser le logiciel en toute sécurité

introduction

Les pratiques de développement modernes font souvent la distinction entre le déploiement et la publication de logiciels. Le déploiement est l’étape qui consiste à transférer le nouveau code sur les serveurs. La libération est l’étape où le nouveau code commence à recevoir du trafic de production.

Le déploiement bleu-vert est une stratégie de déploiement et de publication de logiciels. Il est essentiel de maintenir deux environnements distincts capables de production, surnommés bleu et vert, pour faciliter la discussion. Dans ce guide, nous expliquerons comment utiliser les déploiements bleu-vert sur DigitalOcean pour simplifier le processus de transition de vos utilisateurs vers une nouvelle version de votre logiciel.

Conditions préalables

Afin de compléter ce guide, vous aurez besoin de deux serveurs Ubuntu 14.04 déployés dans un environnement vous permettant de déplacer facilement les adresses IP entre les hôtes. Sur DigitalOcean, Floating IPs peut fournir cette fonctionnalité. Ces serveurs représenteront deux environnements parallèles utilisés alternativement pour la mise en attente et la production. Vous pouvez appeler ces serveurs comme bon vous semble, mais dans ce guide, nous les qualifierons de «bleus» et de «verts».

Sur chacun de ces serveurs, vous devriez avoir un utilisateur non root avec + sudo + configuré pour les fonctions administratives. Vous pouvez configurer ces utilisateurs en suivant notre Ubuntu 14.04 - Guide de configuration du serveur initial.

Qu’est-ce qu’un déploiement Blue-Green?

Le concept de base du déploiement bleu-vert, une technique rendue populaire par this post de Martin Fowler, est que deux ensembles d’environnements, chacun capable de servir votre application en production , sont maintenus. Ces deux environnements devraient être presque identiques. Par convention, on parle d’environnements bleu et vert.

Un seul de ces environnements est actif et reçoit du trafic de production à la fois. Devant les points de terminaison Web de ces environnements (serveurs Web ou équilibreurs de charge), un routeur ou un autre mécanisme de gestion du trafic renvoie tout le trafic de production à l’environnement actuellement actif.

Lorsqu’une nouvelle version est planifiée, elle est déployée dans l’environnement non actif. Pour les déploiements bleu-vert, l’environnement non actif fonctionne comme un environnement intermédiaire final. Il reflète très étroitement l’environnement de production et peut être utilisé pour les tests finaux avant de décider de faire vivre les changements.

Une fois que vous avez testé votre déploiement en interne et que vous avez acquis la confiance en sa robustesse, vous pouvez publier la nouvelle version rapidement et facilement en ajustant le mécanisme de routage. Fondamentalement, vous basculez le commutateur au niveau de la couche de gestion du trafic afin que tout le trafic de production commence à migrer vers votre nouvelle version de logiciel. L’environnement précédemment actif devient inactif et votre environnement intermédiaire précédent devient votre nouvel environnement de production.

À ce stade, votre version précédente du logiciel n’est pas active, mais reste accessible. Si votre déploiement récemment actif présente des problèmes graves, il est aussi simple de revenir à votre version précédente que de modifier à nouveau le mécanisme de routage.

Exemple de scénario

Pour illustrer ce concept général, nous allons configurer deux environnements de serveur. Chacun aura un serveur Web installé. Gardez à l’esprit que, dans cet exemple, le serveur Web représente une pile d’applications complète pouvant inclure un équilibreur de charge, plusieurs serveurs Web et des bases de données distribuées ou répliquées dans le backend. Nous utilisons un serveur Web dans ce guide car il représente le plus petit environnement pouvant démontrer ce modèle de version.

Nous allons commencer à développer une «application» sur notre ordinateur local. En réalité, il ne s’agira que d’une page + index.html que nous pourrons déployer sur nos serveurs. Nous allons configurer un https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#using-git-hooks-to-deploy- vers un serveur de production séparé [+ git + post receive hook] sur chacun de nos serveurs afin que nous puissions nous déployer simplement en émettant un + git push +. Nous déploierons la version initiale de notre application sur nos deux serveurs.

Dans ce guide, nous utiliserons une adresse IP DigitalOcean https://www.digitalocean.com/community/tutorials/how-to-use-floating-ips-on-digitalocean en tant que mécanisme de routage. Les adresses IP flottantes constituent un mécanisme simple permettant de transférer le trafic d’un serveur à un autre. Nous allons créer une adresse IP flottante et le diriger vers notre serveur vert pour le définir comme machine de production initiale.

Nous modifierons ensuite notre application et la déploierons sur notre serveur bleu. Le trafic de production sera toujours servi à partir du serveur vert inchangé à ce stade. Nous pouvons ensuite tester le serveur bleu pour nous assurer que notre déploiement a été réussi et qu’il n’y a pas eu de bogues. Lorsque nous sommes prêts, nous pouvons déplacer l’IP flottante vers la nouvelle version du code en réaffectant simplement l’adresse IP flottante au serveur bleu.

Créer une application locale

Nous allons commencer par créer notre "application". Comme indiqué ci-dessus, il s’agit en réalité d’une page d’index que nos serveurs Web peuvent afficher. Cela nous permet de démontrer différentes «versions» de l’application sans les frais généraux liés au développement.

Sur votre système local (ou sur un autre Droplet), installez https://git-scm.com/downloads [+ git +] en utilisant la méthode préférée de votre plate-forme. Si votre machine locale exécute Ubuntu, vous pouvez l’installer en tapant:

sudo apt-get update
sudo apt-get install git

Nous devons définir quelques paramètres de configuration afin de nous engager dans un référentiel + git +. Nous allons définir notre nom et adresse email en tapant:

git config --global user.name ""
git config --global user.email ""

Avec notre jeu de configuration, nous pouvons créer un répertoire pour notre nouvelle application et y accéder:

mkdir ~/sample_app
cd ~/sample_app

Initialisez un référentiel git dans notre répertoire d’application en tapant:

git init

Maintenant, créez le fichier + index.html qui représente votre application:

nano index.html

A l’intérieur, nous allons simplement spécifier le numéro de version de notre application. De cette façon, nous pouvons facilement savoir quelle version de notre application est installée sur chaque serveur:

~ / sample_app / index.html

App v1

Enregistrez et fermez le fichier lorsque vous avez terminé.

Pour finir, nous pouvons ajouter le fichier + index.html à la zone de stockage intermédiaire` + git` puis valider en tapant:

git add .
git commit -m "initializing repository with version 1"

Une fois notre fichier validé, nous allons arrêter momentanément le développement de nos applications sur notre machine locale et nous concentrer sur la configuration de nos serveurs Web bleus et verts.

Configurer les serveurs Web bleu et vert

Nous travaillerons ensuite à la configuration de nos environnements vert et bleu avec des serveurs Web fonctionnels. Nous utiliserons Apache dans ce guide. Connectez-vous à vos serveurs avec votre utilisateur + sudo + pour commencer.

Note

Nous pouvons installer Apache facilement avec + apt +. Mettez à jour l’index de package local et installez le logiciel du serveur Web en tapant:

sudo apt-get update
sudo apt-get install apache2

Cela devrait installer et démarrer Apache sur vos deux serveurs Web.

Ensuite, nous devrons créer et configurer un utilisateur «déployer». Cet utilisateur aura accès à la racine Web Apache et sera propriétaire du référentiel nu + git où nous allons pousser notre application.

Créez un utilisateur + deploy + en tapant:

sudo adduser --disabled-password deploy

Cela créera un nouvel utilisateur avec l’authentification par mot de passe désactivée.

Nous allons donner à ce nouvel utilisateur la propriété de la racine Web par défaut d’Apache. Ceci est situé à + ​​/ var / www / html. Changez la propriété de ce répertoire en tapant:

sudo chown -R : /var/www/html

C’est tout ce dont nous avons besoin pour notre déploiement simple, qui repose uniquement sur le transfert de fichiers vers la racine Web.

Note

Configuration du déploiement de Git sur les serveurs Web vert et bleu

Maintenant que Apache est installé et qu’un utilisateur est configuré pour exécuter le déploiement, nous pouvons configurer un référentiel nu + git + pour y envoyer notre application. Nous pouvons ensuite configurer un hook + post-receive + qui déploiera automatiquement la version la plus récente de notre branche master lorsque nous le placerons sur nos serveurs.

Note

Commencez par installer + git + sur vos deux serveurs:

sudo apt-get install git

Ensuite, nous devons nous connecter en tant qu’utilisateur + deploy +. Nous pouvons le faire avec + sudo + en tapant:

sudo su - deploy

Dans le répertoire de base de notre utilisateur + deploy +, créez un répertoire pour notre exemple d’application, comme nous l’avons fait sur notre ordinateur local. Déplacer dans le répertoire après la création:

mkdir ~/sample_app
cd ~/sample_app

Nous allons initialiser un dépôt + git + dans ce répertoire, comme nous l’avons fait sur notre système local. Cependant, sur nos serveurs, nous inclurons l’option + - bare +. Cela créera un repo + git + sans répertoire de travail. Au lieu de cela, le contenu généralement caché dans un répertoire + .git + sera placé dans le dossier principal:

git init --bare

Nous allons mettre en place un hook + post-receive +. Ceci est juste un script qui déploiera vos modifications après un + git push. Pour en savoir plus sur cette stratégie de déploiement, consultez https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#using-git-. hooks-to-deploy-to-a-separ-production-server [ce guide]. Nous devrions placer ce script dans le répertoire + hooks + de notre repo. Créez et ouvrez le fichier en tapant:

nano hooks/post-receive

À l’intérieur, collez le script de déploiement suivant. C’est fondamentalement le même script que celui décrit dans l’article lié à ci-dessus. Nous utilisons une variable + GIT_DIR + pour indiquer notre référentiel + git + sur le serveur, la variable + WORK_TREE + pour spécifier la racine de notre document Apache et + + HOSTNAME + pour récupérer le nom d’hôte de notre serveur pour les messages de progression. Ce script déploiera toutes les modifications de la branche + master + dans le répertoire Web. Aucune modification ne devrait être nécessaire dans le script ci-dessous:

/ home / deploy / sample_app / hooks / post-receive

#!/bin/bash

GIT_DIR=/home/deploy/sample_app
WORK_TREE=/var/www/html
HOSTNAME=$(hostname)

while read oldrev newrev ref
do
   if [[ $ref =~ .*/master$ ]];
   then
       echo "Master ref received.  Deploying master branch to $HOSTNAME..."
       git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f
       echo "Git hooks deploy complete."
   else
       echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
   fi
done

Si vous vous écartez de ce guide et avez besoin d’étapes de déploiement plus complexes, ajoutez-les à la clause + then + dans le script ci-dessus. Assurez-vous que toutes les étapes nécessitant des privilèges élevés dans cette section utilisent la commande + sudo +. De plus, assurez-vous que toutes les commandes qui utilisent + sudo + ici sont ajoutées au fichier + sudoers + comme spécifié au bas de la dernière section.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Modifiez les autorisations sur le hook + post-receive + afin que + git + puisse l’exécuter au moment opportun:

chmod +x hooks/post-receive

Configurer l’accès par clé SSH sur les serveurs bleu et vert

Ensuite, nous allons configurer les clés SSH de sorte que + git + puisse transmettre les modifications à nos serveurs Web sans demander de mot de passe.

Créer ou afficher votre clé publique sur votre machine de développement

Sur votre * ordinateur local ou de développement *, vérifiez si vous avez déjà une clé SSH configurée en tapant:

cat ~/.ssh/id_rsa.pub

Si vous avez déjà une paire de clés SSH disponible, vous devriez voir quelque chose qui ressemble à ceci:

Outputssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDilFdzkgBcSKdh6tx5pLf+HH6Pv7z7jRZ7cSo6lQvecWOOgGl/wHCVZWx1ULvrF7VgJpgugLwxYsFh3E39sm1+7zeAlRxhFrbWvATwpAEwh5m0+48LTmvXCnJ8/om+GfmAwplmzGk/DNs5trVeagG62Css0rypdoNuLrVdCVKUXGXbO6KnpOsBqoM2HvZKtQ8j1gx+1UUnvK9LYes+ZzC2XZZeBh2dGABe7HNnd8+6e1f2ZjPEKAEV2fPJGAGaAQOnzSKJkUt/B9PdKFbCjnnG1sT0kQoxMRIAiqfR7wa7PUQCM5Orm5S92OTNcnRr8bWVjN18bWCyXkpxxWbIvVU/ user@devel

Si la commande s’exécute correctement, copiez le texte affiché dans son intégralité. Nous allons utiliser cela dans la section suivante. Vous pouvez y aller en toute sécurité maintenant.

Si vous n’avez * pas * de clés SSH sur votre machine locale, vous verrez probablement une erreur qui ressemble à ceci:

Outputcat: /home/user/.ssh/id_rsa.pub: No such file or directory

Si tel est le cas, vous pouvez créer une nouvelle paire de clés publique et privée en tapant:

ssh-keygen

Appuyez sur ENTREE à travers toutes les invites pour accepter les valeurs par défaut. Une fois les clés créées, ressaisissez la commande + cat + pour afficher la nouvelle clé publique:

cat ~/.ssh/id_rsa.pub

Cela devrait s’exécuter correctement cette fois. Copiez les lignes affichées à utiliser dans la section suivante.

Ajoutez votre clé publique SSH à l’utilisateur du déploiement sur les serveurs vert et bleu

De retour sur vos serveurs verts et bleus, nous autoriserons votre compte sur notre machine locale ou de développement à se connecter à nos utilisateurs + deploy.

En tant qu’utilisateur + deploy +, créez un répertoire + ~ / .ssh +. À l’intérieur, ouvrez un fichier nommé + registered_keys +:

mkdir ~/.ssh
nano ~/.ssh/authorized_keys

Dans ce fichier, collez le résultat que vous avez copié à partir de votre ordinateur local:

~ / .ssh / registered_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDilFdzkgBcSKdh6tx5pLf+HH6Pv7z7jRZ7cSo6lQvecWOOgGl/wHCVZWx1ULvrF7VgJpgugLwxYsFh3E39sm1+7zeAlRxhFrbWvATwpAEwh5m0+48LTmvXCnJ8/om+GfmAwplmzGk/DNs5trVeagG62Css0rypdoNuLrVdCVKUXGXbO6KnpOsBqoM2HvZKtQ8j1gx+1UUnvK9LYes+ZzC2XZZeBh2dGABe7HNnd8+6e1f2ZjPEKAEV2fPJGAGaAQOnzSKJkUt/B9PdKFbCjnnG1sT0kQoxMRIAiqfR7wa7PUQCM5Orm5S92OTNcnRr8bWVjN18bWCyXkpxxWbIvVU/ user@devel

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, verrouillez les autorisations afin que SSH puisse utiliser le fichier que vous avez créé:

chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

Configurer les télécommandes Git sur la machine de développement locale

Maintenant que l’accès aux clés SSH est configuré pour nos serveurs Web et que notre répertoire d’applications est configuré sur chaque serveur, nous pouvons ajouter nos serveurs bleus et verts comme télécommandes dans notre référentiel d’applications local + git +.

Sur votre ordinateur local, revenez dans le répertoire de votre application:

cd ~/sample_app

Ajoutez des références distantes pour que + git + puisse appliquer les modifications à vos serveurs Web verts et bleus:

git remote add blue deploy@:sample_app
git remote add green deploy@:sample_app

Nous devrions maintenant être en mesure de pousser notre application sur nos deux serveurs. Essayons-le en envoyant la version 1 de notre application sur les deux serveurs.

git push blue master
git push green master

Vous devrez peut-être accepter l’empreinte de la clé de chaque serveur lors de votre premier déploiement. Vous devriez voir une sortie qui ressemble à ceci:

OutputThe authenticity of host '111.111.111.111 (111.111.111.111)' can't be established.
ECDSA key fingerprint is 30:a1:2c:8b:ec:98:a3:3c:7f:4a:db:46:2b:96:b5:06.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added '111.111.111.111' (ECDSA) to the list of known hosts.
Counting objects: 3, done.
Writing objects: 100% (3/3), 246 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Master ref received.  Deploying master branch to blue...
remote: Git hooks deploy complete.
To [email protected]:sample_app
* [new branch]      master -> master

Comme vous pouvez le constater, les lignes commençant par «remote:» contiennent les instructions + echo + du hook + post-receive + sur notre serveur. N’oubliez pas de pousser votre application sur vos deux serveurs.

Nous pouvons tester que le déploiement initial de notre application a réussi avec curl:

curl
curl

Pour ces deux appels, la réponse devrait être la suivante:

OutputApp v1

Cela indique que notre script de déploiement fonctionne correctement.

Configuration d’une adresse IP flottante pour acheminer le trafic

Maintenant que la version initiale de notre application est déployée, nous pouvons créer une adresse IP flottante et la diriger vers notre serveur «vert» au départ.

Dans le panneau de configuration de DigitalOcean, cliquez sur l’onglet «Réseau», puis sur l’élément de menu «IP flottantes». Dans le menu fourni, sélectionnez votre serveur vert et cliquez sur le bouton “Attribuer une adresse IP flottante”:

image: https: //assets.digitalocean.com/articles/blue_green_deployment/create_ip.png [DigitalOcean crée une adresse IP flottante]

Après quelques secondes, l’adresse IP doit être attribuée à votre serveur vert:

image: https: //assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [IP flottante attribuée à DigitalOcean]

Vous pouvez maintenant utiliser cette adresse IP comme point d’entrée principal dans le déploiement de votre application de production. Si vous souhaitez configurer un nom de domaine pour votre application Web, vous devez indiquer le domaine à cette adresse IP flottante.

Vérifiez que votre application est accessible via l’adresse IP flottante en tapant:

curl

Vous devriez voir la version 1 de votre application:

OutputApp v1

Le serveur vert fournit actuellement cette réponse.

Pratiquer le déploiement bleu-vert

Maintenant que notre configuration est terminée, nous pouvons démontrer comment le déploiement bleu-vert fonctionne dans la pratique. Actuellement, notre adresse IP flottante pointe vers notre serveur vert. Comme indiqué précédemment, l’adresse IP flottante représente le trafic de production et serait l’emplacement auquel nous attacherions le nom de domaine de notre application.

Apporter des modifications d’application

Sur votre machine locale ou de développement, nous pouvons apporter des modifications à notre application. Ouvrez le fichier d’index:

cd ~/sample_app
nano index.html

Faisons un changement simple et visible dans notre application en incrémentant le numéro de version:

~ / sample_app / index.html

App v2

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ajoutez le fichier à la zone de transfert + git + et validez vos modifications en tapant:

git add .
git commit -m "Application version 2"

Pousser vers l’environnement non actif

Ensuite, nous pouvons appliquer nos nouvelles modifications à notre environnement non actif. Cela nous donnera l’occasion de tester notre déploiement sans impact sur notre serveur de production.

Étant donné que notre adresse IP flottante pointe actuellement vers notre environnement vert, nous allons procéder au déploiement sur notre serveur bleu. Poussez les nouvelles modifications dans l’environnement bleu en tapant ce qui suit sur votre ordinateur de développement local:

git push blue master

Si nous visitons notre * adresse IP flottante *, nous devrions voir que la version 1 de notre application est toujours en cours de traitement:

curl
OutputApp v1

Cependant, si nous vérifions l’adresse IP * régulière de notre * serveur bleu, nous pourrons tester la version 2 de notre application:

curl
OutputApp v2

C’est ce à quoi nous nous attendons et ce que nous voulons. Nous pouvons maintenant exécuter notre environnement de serveur bleu au moyen des tests internes dont nous avons besoin. Pendant ce temps, le serveur vert continuera de servir notre trafic de production.

Transférer la production dans le nouvel environnement

Une fois que vous avez testé la dernière version de votre application et que vous êtes sûr qu’elle fonctionne comme prévu, vous pouvez basculer le trafic de production sur le serveur bleu.

Pour ce faire, la méthode la plus simple consiste à consulter le panneau de configuration de DigitalOcean. Cliquez sur l’onglet «Réseau», puis sélectionnez l’élément de navigation «IP flottantes». Dans la liste «IP flottantes», vous devriez voir votre IP flottante, qui pointe actuellement vers le serveur vert:

image: https: //assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [IP flottante attribuée à DigitalOcean]

Avant de passer, dans l’une de vos fenêtres de terminal, démarrez une boucle + while afin que nous puissions faire des demandes répétées via l’adresse IP flottante. Cela nous permet de voir immédiatement la transition de la version 1 à la version 2 de notre application de production:

while true; do curl ; sleep 2; done

Il devrait commencer à générer les résultats des requêtes Web:

OutputApp v1
App v1
App v1
App v1

Maintenant, pour faire le changement et «libérer» votre nouvelle version de votre logiciel, cliquez sur le bouton bleu sur le côté droit de l’affectation d’adresse IP flottante pour réaffecter l’adresse IP. Sélectionnez votre serveur bleu:

image: https: //assets.digitalocean.com/articles/blue_green_deployment/reassign_ip.png [DigitalOcean réaffecte l’adresse IP]

Dans quelques secondes, votre adresse IP flottante sera réaffectée à votre serveur bleu. Dans la fenêtre de votre terminal, le basculement doit être évident:

OutputApp v1
App v1
App v2
App v2

Arrêtez la boucle + while + en appuyant sur “CTRL-C”.

Votre trafic de production est maintenant acheminé vers la nouvelle version de votre application. Votre serveur de production précédent, le serveur vert, est maintenant configuré à la fois comme machine à restauration et comme zone de stockage intermédiaire suivante.

Si, après avoir déplacé le trafic sur la nouvelle version de l’application, vous découvrez un problème, cette stratégie de publication vous permet de revenir à la version précédente rapidement et sans douleur. Pour ce faire, il suffit d’inverser le processus et de rediriger votre adresse IP flottante vers le serveur vert.

Faire face aux mises à jour de la base de données

Le scénario décrit ci-dessus a été simplifié afin de se concentrer sur la stratégie de déploiement et de publication elle-même. Cependant, nous n’avons pas parlé de configurations plus complexes, mais communes, comme celles impliquant des bases de données.

Vous pouvez utiliser différentes stratégies pour gérer les données persistantes entre vos deux environnements.

Il est possible de maintenir une base de données distincte pour chacun de vos environnements. Toutefois, cette stratégie nécessiterait que vous répliquiez les données de la base de données de production vers la base de données non active et que vous arrêtiez les transactions au moment où vous initiez un commutateur. Fondamentalement, cela nécessiterait une migration de base de données en temps réel, ainsi que quelques instants de temps mort pour chaque déploiement. Cela pourrait rapidement prendre beaucoup de temps et être source d’erreurs.

Une meilleure solution consiste généralement à partager un seul système de base de données entre les environnements vert et bleu. Le code de l’application sera commutable à l’aide de la stratégie de version bleu-vert, tandis que la base de données elle-même sera utilisée par les deux environnements.

La principale préoccupation de cette approche est de savoir comment déployer et publier des mises à jour qui incluent des migrations de bases de données non compatibles avec les versions antérieures. Si nous déployons une nouvelle version dans le stockage intermédiaire qui ajoute ou modifie la base de données d’une manière qui ne fonctionne pas avec le déploiement de production actuel, nous allons casser notre application.

Pour éviter cela, il est souvent préférable de déployer vos migrations séparément des déploiements de votre base de code et par étapes si nécessaire. Ce processus modifié est parfois appelé blue-turquoise-green deployment. Fondamentalement, il s’agit de déployer une version intermédiaire du code de votre application capable de gérer à la fois l’ancienne et la nouvelle version de votre base de données.

Le code d’application intermédiaire est presque complètement identique à la version précédente, mais avec une logique supplémentaire le préparant aux nouvelles structures de données qui existeront après la migration. Ceci est souvent accompli en construisant les migrations de manière à créer de nouvelles structures de données au lieu de modifier celles existantes. De cette façon, vous pouvez conserver l’ancienne structure de données, disons une table et en créer une nouvelle qui inclut les modifications les plus récentes.

Le déploiement turquoise intermédiaire est déployé en tant que première étape du processus de migration. Dans un premier temps, ce déploiement sera lu et écrit dans l’ancienne table, mais il vérifiera l’existence de la nouvelle structure. Ensuite, la migration elle-même est exécutée, créant la nouvelle version de la structure de données à côté de l’ancienne version. La logique de déploiement turquoise doit être configurée pour reconnaître que la nouvelle structure est en place et il devrait commencer à écrire les modifications apportées à l’ancienne et à la nouvelle structure. Il continuera à lire de l’ancienne structure pour le moment.

À ce stade, toute nouvelle activité sera enregistrée dans les deux structures de données. Vous pouvez compléter la nouvelle structure avec les données de l’ancienne structure et la transformer en cours de route pour satisfaire les conditions de la nouvelle structure. Lorsque cela est terminé, tous vos enregistrements doivent exister aux deux emplacements. Pour poursuivre la transition, le prochain déploiement d’application peut continuer à écrire dans les deux structures, mais peut également être lu à partir de la nouvelle structure. Une fois que tout est confirmé pour que tout fonctionne correctement, un autre déploiement peut couper les écritures de l’ancienne structure et l’ancienne structure peut être supprimée.

Ce processus peut sembler assez compliqué au début, mais dans la pratique, il ne s’agit généralement pas de beaucoup de travail supplémentaire. Le travail principal consiste à mettre en place un filet de sécurité qui utilisera à la fois les anciennes structures et les nouvelles structures. Cela vous laisse le temps de tester vos migrations en profondeur avant de vous y engager et de revenir à tout moment à la version de travail précédente de votre structure de données. Pour un exemple de la manière dont cette migration de données pourrait avoir lieu, consultez certaines des these slides de Mike Brittain chez Etsy.

Conclusion

Bien que de nombreuses autres stratégies puissent être utilisées pour séparer le déploiement de la version actuelle de votre nouveau code, le déploiement bleu-vert est un mécanisme assez simple, rapide à mettre en œuvre. Il fournit un bon environnement de transfert qui reflète complètement l’environnement de production, tout en offrant des possibilités de restauration immédiate à la suite d’une version si les choses ne se passaient pas comme prévu.

Related