TOC

Как использовать сине-зеленые развертывания для безопасного выпуска программного обеспечения

Вступление

Современные практики разработки часто различают развертывание и выпуск программного обеспечения. Развертывание - это шаг, который включает в себя получение нового кода на серверах. Выпуск является шагом, когда новый код начинает получать производственный трафик.

Сине-зеленое развертывание - это стратегия развертывания и выпуска программного обеспечения. Он опирается на поддержку двух отдельных производственных сред, прозванных синим и зеленым для простоты обсуждения. В этом руководстве мы обсудим, как использовать сине-зеленые развертывания в DigitalOcean для упрощения процесса перехода ваших пользователей на новую версию вашего программного обеспечения.

Предпосылки

Для выполнения этого руководства вам понадобятся два сервера Ubuntu 14.04, развернутые в среде, которая позволяет легко перемещать IP-адреса между хостами. В DigitalOcean Floating IPs могут предоставить эту функциональность. Эти серверы будут представлять две параллельные среды, которые альтернативно используются для подготовки и производства. Вы можете называть эти серверы так, как вам нравится, но в этом руководстве мы будем называть их «синими» и «зелеными».

На каждом из этих серверов у вас должен быть пользователь без полномочий root с + sudo +, настроенным для административных функций. Вы можете настроить этих пользователей, следуя нашему Ubuntu 14.04 начальному руководству по установке сервера.

Что такое сине-зеленое развертывание?

Базовая концепция сине-зеленого развертывания, методика, ставшая популярной благодаря Мартину Фаулеру, this post, состоит в том, что два набора сред, каждый из которых способен обслуживать ваше приложение в производстве , поддерживаются. Эти две среды должны быть почти идентичны. По соглашению они называются синей и зеленой средой.

Только одна из этих сред является активной и получает производственный трафик одновременно. Перед веб-конечными точками для этих сред (веб-серверами или балансировщиками нагрузки) маршрутизатор или другой механизм направления трафика направляет весь производственный трафик в текущую активную среду.

Когда планируется новая версия, она развертывается в неактивной среде. Для сине-зеленых развертываний неактивная среда выступает в качестве конечной промежуточной среды. Он очень близко отражает производственную среду и может быть использован для окончательного тестирования перед принятием решения о внесении изменений.

После того, как вы самостоятельно проверили свое развертывание и убедились в его надежности, вы можете быстро и легко выпустить новую версию, настроив механизм маршрутизации. По сути, вы переключаете коммутатор на уровень управления трафиком, чтобы весь производственный трафик начал переходить на новую версию программного обеспечения. Ранее активная среда становится неактивной, а предыдущая промежуточная среда становится новой производственной средой.

На данный момент ваша предыдущая версия программного обеспечения неактивна, но все еще доступна. Если ваше новое активное развертывание страдает от каких-либо серьезных проблем, вернуться к предыдущей версии так же просто, как снова изменить механизм маршрутизации.

Пример сценария

Чтобы продемонстрировать эту общую концепцию, мы настроим две серверные среды. У каждого будет установлен веб-сервер. Помните, что в этом примере веб-сервер представляет собой весь стек приложений, который может включать балансировщик нагрузки, несколько веб-серверов и распределенные или реплицированные базы данных в бэкэнде. В этом руководстве мы используем веб-сервер, поскольку он представляет собой наименьшую среду, которая может продемонстрировать этот шаблон выпуска.

Мы начнем разрабатывать «приложение» на нашем локальном компьютере. В действительности это будет только страница + index.html, которую мы можем развернуть на наших серверах. Мы настроим https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#using-git-hooks-to-deploy- to-a-Отдельный производственный сервер [+ git + post receive hook] на каждом из наших серверов, чтобы мы могли просто выполнить развертывание, введя + git push +. Мы развернем первоначальную версию нашего приложения на обоих наших серверах.

В этом руководстве мы будем использовать DigitalOcean Floating IP-адрес в качестве механизма маршрутизации. Плавающие IP-адреса предоставляют простой механизм для перемещения трафика с одного сервера на другой. Мы создадим плавающий IP-адрес и направим его на наш зеленый сервер, чтобы установить его в качестве нашей начальной рабочей машины.

Затем мы изменим наше приложение и развернем его на нашем синем сервере. На этом этапе производственный трафик будет по-прежнему обслуживаться неизменным зеленым сервером. Затем мы можем протестировать синий сервер, чтобы убедиться, что наше развертывание прошло успешно и ошибок нет. Когда мы будем готовы, мы можем переместить Плавающий IP-адрес в новую версию кода, просто переназначив Плавающий IP-адрес на синий сервер.

Создать локальное приложение

Мы начнем с создания нашего «приложения». Как указано выше, это на самом деле просто страница указателя, которую могут отображать наши веб-серверы. Это позволяет нам демонстрировать различные «версии» приложения без затрат на фактическую разработку.

В вашей локальной системе (или в другой Droplet) установите https://git-scm.com/downloads [+ git +], используя предпочтительный метод вашей платформы. Если на вашем локальном компьютере установлена ​​Ubuntu, вы можете установить, набрав:

sudo apt-get update
sudo apt-get install git

Нам нужно установить несколько параметров конфигурации, чтобы зафиксировать репозиторий + git +. Мы установим наше имя и адрес электронной почты, набрав:

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

С нашим набором конфигурации мы можем создать каталог для нашего нового приложения и перейти в него:

mkdir ~/sample_app
cd ~/sample_app

Инициализируйте репозиторий git в каталоге нашего приложения, набрав:

git init

Теперь создайте файл + index.html, который представляет ваше приложение:

nano index.html

Внутри мы просто укажем номер версии нашего приложения. Таким образом, мы можем легко определить, какая версия нашего приложения находится на каждом сервере:

~ / Sample_app / index.html

App v1

Сохраните и закройте файл, когда вы закончите.

Чтобы закончить, мы можем добавить файл + index.html в область подготовки` + git`, а затем зафиксировать, набрав:

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

После того, как наш файл будет зафиксирован, мы на мгновение остановим разработку наших приложений на нашем локальном компьютере и сосредоточимся на настройке наших синих и зеленых веб-серверов.

Настройте синий и зеленый веб-серверы

Далее мы будем работать над настройкой наших зеленых и синих сред с функциональными веб-серверами. Мы будем использовать Apache в этом руководстве. Войдите в свои серверы с вашим пользователем + sudo +, чтобы начать.

Note

Мы можем легко установить Apache с помощью + apt +. Обновите локальный индекс пакетов и установите программное обеспечение веб-сервера, введя:

sudo apt-get update
sudo apt-get install apache2

Это должно установить и запустить Apache на обоих ваших веб-серверах.

Далее мы должны создать и настроить пользователя «развертывания». Этот пользователь будет иметь доступ к веб-корню Apache и будет иметь собственный репозиторий + git, куда мы будем помещать наше приложение.

Создайте пользователя + deploy +, набрав:

sudo adduser --disabled-password deploy

Это создаст нового пользователя с отключенной аутентификацией по паролю.

Мы дадим этому новому пользователю право собственности на стандартный веб-корень Apache. Это находится в + / var / www / html. Измените владельца этого каталога, набрав:

sudo chown -R : /var/www/html

Это все, что нам нужно для нашего простого развертывания, которое опирается только на перемещение файлов в корневой веб-каталог.

Note

Настройка Git Deployment на зеленом и синем веб-серверах

Теперь, когда у нас установлен Apache и пользователь сконфигурирован для выполнения развертывания, мы можем настроить пустой репозиторий + git + для отправки нашего приложения. Затем мы можем установить хук + post-receive +, который автоматически развернет самую последнюю версию нашей основной ветки, когда мы отправим ее на наши серверы.

Note

Начните с установки + git + на обоих ваших серверах:

sudo apt-get install git

Далее нам нужно войти как наш + deploy + пользователь. Мы можем сделать это с помощью + sudo +, набрав:

sudo su - deploy

В домашнем каталоге нашего пользователя + deploy + создайте каталог для нашего примера приложения, как мы это делали на нашем локальном компьютере. Переместиться в каталог после создания:

mkdir ~/sample_app
cd ~/sample_app

Мы инициализируем репозиторий + git + в этом каталоге, как мы это делали в нашей локальной системе. Однако на наших серверах мы включим опцию + - bare +. Это создаст репозиторий + git + без рабочего каталога. Вместо этого содержимое, обычно скрытое в каталоге + .git +, будет помещено в основную папку:

git init --bare

Далее мы установим хук + post-receive +. Это всего лишь скрипт, который развернет ваши изменения после того, как произойдет + git push. Вы можете узнать больше об этой стратегии развертывания, прочитав https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#using-git- зацепки для развертывания на отдельном производственном сервере [это руководство]. Мы должны поместить этот скрипт в каталог + hooks + нашего репозитория. Создайте и откройте файл, набрав:

nano hooks/post-receive

Внутри вставьте следующий сценарий развертывания. Это в основном тот же сценарий, который описан в статье, указанной выше. Мы используем переменную + GIT_DIR + для обозначения нашего репозитория + git + на сервере, переменную + WORK_TREE + для указания корня нашего документа Apache и + HOSTNAME + для получения имени хоста нашего сервера для сообщений о ходе выполнения. Этот скрипт развернет все изменения в ветке + master + в веб-каталоге. Никаких изменений не нужно вносить в скрипт ниже:

/ Главная / развернуть / sample_app / Крючки / после приема

#!/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

Если вы отклоняетесь от этого руководства и нуждаетесь в более сложных шагах развертывания, добавьте их в предложение + then + в приведенном выше сценарии. Убедитесь, что любые шаги, которые требуют повышенных привилегий в этом разделе, используют команду + sudo +. Также убедитесь, что все команды, использующие + sudo +, добавлены в файл + sudoers +, как указано в нижней части последнего раздела.

Сохраните и закройте файл, когда вы закончите.

Измените разрешения на хуке + post-receive +, чтобы + git + мог выполнить его в соответствующее время:

chmod +x hooks/post-receive

Настройка доступа по ключу SSH на синем и зеленом серверах

Далее мы настроим SSH-ключи так, чтобы + git + мог отправлять изменения на наши веб-серверы без запроса пароля.

Создайте или покажите свой открытый ключ на своей машине разработки

На своем * локальном компьютере или компьютере разработки * проверьте, настроен ли уже SSH-ключ, введя:

cat ~/.ssh/id_rsa.pub

Если у вас уже есть пара ключей SSH, вы должны увидеть что-то похожее на это:

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

Если команда выполняется правильно, скопируйте текст, который отображается полностью. Мы будем использовать это в следующем разделе. Вы можете спокойно пропустить там сейчас.

Если у вас * нет * ключей SSH на вашем локальном компьютере, вы, вероятно, увидите ошибку, которая выглядит следующим образом:

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

Если это так, вы можете создать новую пару открытого и закрытого ключей, набрав:

ssh-keygen

Нажмите клавишу ВВОД во всех запросах, чтобы принять значения по умолчанию. Когда ключи созданы, введите команду + cat + еще раз, чтобы отобразить новый открытый ключ:

cat ~/.ssh/id_rsa.pub

Это должно выполняться правильно на этот раз. Скопируйте отображаемые строки для использования в следующем разделе.

Добавьте ваш открытый ключ SSH к пользователю развертывания на зеленом и синем серверах

Вернувшись на ваш зеленый и синий серверы, мы авторизуем вашу учетную запись на нашем локальном компьютере или компьютере для разработки для подключения к нашим пользователям + deploy.

Как ваш пользователь + deploy +, создайте каталог + ~ / .ssh +. Внутри откройте файл с именем + authorized_keys +:

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

В этом файле вставьте вывод, скопированный с локального компьютера:

~ / .Ssh / authorized_keys

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

Сохраните и закройте файл, когда вы закончите.

Затем заблокируйте разрешения, чтобы SSH мог использовать созданный вами файл:

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

Сконфигурируйте Git Remotes на локальной машине разработки

Теперь, когда у нас настроен доступ с помощью ключа SSH к нашим веб-серверам и каталог приложений, настроенный на каждом сервере, мы можем добавить наши синие и зеленые серверы в качестве удаленных в нашем локальном репозитории приложений + git +.

На локальном компьютере вернитесь в каталог приложения:

cd ~/sample_app

Добавьте удаленные ссылки, чтобы + git + мог вносить изменения в ваш зеленый и синий веб-серверы:

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

Теперь мы должны иметь возможность отправить наше приложение на оба наших сервера. Давайте проверим это, отправив версию 1 нашего приложения на оба сервера.

git push blue master
git push green master

Возможно, вам придется принять отпечаток ключа каждого сервера при первом развертывании. Вы должны увидеть вывод, который выглядит примерно так:

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

Как видите, строки, начинающиеся с «remote:», содержат операторы + echo + из ловушки + post-receive + на нашем сервере. Не забудьте отправить ваше приложение на оба ваших сервера.

Мы можем проверить, что первоначальное развертывание нашего приложения прошло успешно с помощью curl:

curl
curl

Для обоих этих вызовов ответ должен быть следующим:

OutputApp v1

Это указывает на то, что наш скрипт развертывания работает правильно.

Настройка плавающего IP-адреса для маршрутизации трафика

Теперь, когда у нас развернута начальная версия нашего приложения, мы можем создать плавающий IP-адрес и изначально направить его на наш «зеленый» сервер.

На панели управления DigitalOcean щелкните вкладку «Сеть», а затем пункт меню «Плавающие IP-адреса». В предоставленном меню выберите свой зеленый сервер и нажмите кнопку «Назначить плавающий IP»:

изображение: https: //assets.digitalocean.com/articles/blue_green_deployment/create_ip.png [DigitalOcean create Floating IP]

Через несколько секунд IP-адрес должен быть назначен вашему зеленому серверу:

изображение: https: //assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [Назначен плавающий IP-адрес DigitalOcean]

Теперь вы можете использовать этот IP-адрес в качестве основной точки входа в развертывание вашего производственного приложения. Если вы хотите настроить доменное имя для своего веб-приложения, вы должны указать домен на этот плавающий IP-адрес.

Проверьте, что ваше приложение доступно через плавающий IP-адрес, набрав:

curl

Вы должны увидеть версию 1 вашего приложения:

OutputApp v1

Зеленый сервер в настоящее время предоставляет этот ответ.

Практика сине-зеленого развертывания

Теперь, когда наша конфигурация завершена, мы можем продемонстрировать, как сине-зеленое развертывание работает на практике. В настоящее время наш плавающий IP-адрес указывает на наш зеленый сервер. Как указывалось ранее, плавающий IP-адрес представляет производственный трафик и будет местом, где мы будем прикреплять доменное имя нашего приложения.

Внести изменения в приложение

На вашем локальном компьютере или компьютере для разработки мы можем внести некоторые изменения в наше приложение. Откройте файл индекса:

cd ~/sample_app
nano index.html

Давайте внесем простое, видимое изменение в наше приложение, увеличив номер версии:

~ / Sample_app / index.html

App v2

Сохраните и закройте файл, когда вы закончите.

Добавьте файл в область подготовки + git + и подтвердите изменения, набрав:

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

Толчок к неактивной среде

Затем мы можем внести наши новые изменения в неактивную среду. Это даст нам возможность протестировать наше развертывание без ущерба для нашего производственного сервера.

Поскольку наш плавающий IP-адрес в настоящее время указывает на нашу зеленую среду, мы развернем наш синий сервер. Внесите новые изменения в синюю среду, набрав на локальной машине разработки следующее:

git push blue master

Если мы посетим наш * Плавающий IP-адрес *, мы должны увидеть, что версия 1 нашего приложения все еще обслуживается:

curl
OutputApp v1

Однако, если мы проверим обычный IP-адрес нашего синего сервера *, мы сможем протестировать версию 2 нашего приложения:

curl
OutputApp v2

Это то, что мы ожидаем и чего хотим. Теперь мы можем запустить нашу среду «голубого сервера» через любое внутреннее тестирование, которое нам нужно. Все это время зеленый сервер будет продолжать обслуживать наш производственный трафик.

Перевернуть производство в новую среду

После того как вы протестировали новейшую версию своего приложения и убедились, что оно работает должным образом, мы можем переключить рабочий трафик на синий сервер.

Для этого самый простой способ - посетить панель управления DigitalOcean. Нажмите на вкладку «Сеть», а затем выберите элемент навигации «Плавающие IP-адреса». В списке «Плавающие IP-адреса» вы должны увидеть свой Плавающий IP-адрес, который в данный момент указывает на зеленый сервер:

изображение: https: //assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [Назначен плавающий IP-адрес DigitalOcean]

Прежде чем переключиться, в одном из окон вашего терминала запустите цикл + while, чтобы мы могли повторять запросы через плавающий IP-адрес. Это позволяет нам сразу же увидеть переход нашей производственной версии приложения с v1 на v2:

while true; do curl ; sleep 2; done

Он должен начать выводить результаты веб-запросов:

OutputApp v1
App v1
App v1
App v1

Теперь, чтобы переключиться и «выпустить» новую версию вашего программного обеспечения, нажмите синюю кнопку справа от назначения с плавающим IP, чтобы переназначить IP-адрес. Выберите свой синий сервер:

изображение: https: //assets.digitalocean.com/articles/blue_green_deployment/reassign_ip.png [DigitalOcean переназначить IP-адрес]

Через несколько секунд ваш плавающий IP будет переназначен на ваш синий сервер. В окне вашего терминала изменение должно быть очевидным:

OutputApp v1
App v1
App v2
App v2

Остановите цикл + while +, нажав «CTRL-C».

Ваш производственный трафик теперь направляется на новую версию вашего приложения. Ваш предыдущий производственный сервер, зеленый сервер, теперь настроен как ваша машина отката и ваша следующая промежуточная область.

Если после переноса трафика на новую версию приложения вы обнаружите проблему, эта стратегия выпуска позволяет быстро и безболезненно вернуться к предыдущей версии. Для этого просто измените процесс и направьте свой плавающий IP-адрес обратно на зеленый сервер.

Работа с обновлениями базы данных

Описанный выше сценарий был упрощен, чтобы сосредоточиться на самой стратегии развертывания и выпуска. Тем не менее, мы не затрагивали более сложные, но распространенные настройки, такие как те, которые связаны с базами данных.

Существует несколько различных стратегий, которые вы можете использовать для обработки постоянных данных между двумя средами.

Можно поддерживать отдельную базу данных для каждой из ваших сред. Однако эта стратегия потребует, чтобы вы реплицировали данные в производственной базе данных в неактивную базу данных и останавливали транзакции в моменты, когда вы инициируете переключение. По сути, это потребует оперативной миграции базы данных, а также нескольких минут простоя при каждом развертывании. Это может быстро стать очень трудоемким и подверженным ошибкам.

Лучшей альтернативой обычно является разделение единой системы баз данных между зелеными и синими средами. Код приложения будет переключаться с использованием сине-зеленой стратегии выпуска, тогда как сама база данных будет использоваться обеими средами.

Основная проблема этого подхода заключается в том, как развертывать и выпускать обновления, которые включают не обратно совместимые миграции баз данных. Если мы развернем в промежуточной версии новый выпуск, который добавляет или изменяет базу данных таким образом, который не работает с текущим производственным развертыванием, мы сломаем наше приложение.

Чтобы этого не происходило, часто лучше развертывать миграции отдельно от развертываний на базе кода и поэтапно, где это необходимо. Этот измененный процесс иногда называется blue-turquoise-green deploy. По сути, это зависит от развертывания промежуточной версии кода вашего приложения, которая может обрабатывать как старые, так и новые версии вашей базы данных.

Промежуточный код приложения почти полностью совпадает с предыдущей версией, но с некоторой дополнительной логикой, которая подготавливает его к новым структурам данных, которые будут существовать после миграции. Зачастую это достигается путем построения миграций таким образом, чтобы они создавали совершенно новые структуры данных вместо изменения существующих. Таким образом, вы можете сохранить старую структуру данных, скажем, таблицу, и создать новую, включающую критические изменения.

Промежуточное бирюзовое развертывание развертывается как первый шаг в процессе миграции. Это развертывание сначала будет читать и записывать в старую таблицу, но будет проверять существование новой структуры. Затем выполняется сама миграция, которая создает новую версию структуры данных вместе со старой версией. Логика бирюзового развертывания должна быть настроена так, чтобы распознавать, что новая структура на месте, и она должна начать записывать изменения в both старая структура и новая структура. Это будет продолжать читать из старой структуры в настоящее время.

На этом этапе все новые действия будут записаны в обеих структурах данных. Вы можете заполнить новую структуру данными из старой структуры, преобразовав их по пути, чтобы удовлетворить условиям новой структуры. Когда это будет завершено, все ваши записи должны существовать в обоих местах. Чтобы продолжить переход, при следующем развертывании приложения может продолжаться запись в обе структуры, но может выполняться чтение из новой структуры. После подтверждения того, что все работает нормально, другое развертывание может отрезать записи от старой структуры, а старую структуру можно удалить.

Поначалу этот процесс может показаться довольно сложным, но на практике это обычно не слишком большая дополнительная работа. Основная работа заключается в создании системы безопасности, которая будет временно использовать как устаревшие, так и новые структуры. Это дает вам время для тщательного тестирования ваших миграций перед их фиксацией и позволяет в любой момент выполнить откат к предыдущей рабочей версии вашей структуры данных. Для примера того, как эта миграция данных может иметь место, взгляните на некоторые из these слайдов от Майка Бриттена из Etsy.

Заключение

Хотя существует множество других стратегий, которые можно использовать для отделения развертывания от фактического выпуска нового кода, сине-зеленое развертывание является довольно простым механизмом, который можно быстро внедрить. Он обеспечивает хорошую промежуточную среду, которая полностью отражает производственную среду, и в то же время предлагает возможности немедленного отката после выпуска, если все пошло не так, как ожидалось.

Related