前書き
現代の開発慣行では、ソフトウェアの展開とリリースを区別することがよくあります。 展開は、サーバーに新しいコードを取得することを伴うステップです。 リリースは、新しいコードが本番トラフィックの受信を開始するステップです。
ブルーグリーン展開は、ソフトウェアを展開およびリリースするための戦略です。 議論を容易にするために、青と緑の愛称で呼ばれる2つの独立した本番環境を維持することに依存しています。 このガイドでは、DigitalOceanでの青緑展開を使用して、ユーザーをソフトウェアの新しいバージョンに移行するプロセスを簡素化する方法について説明します。
前提条件
このガイドを完了するには、ホスト間でIPアドレスを簡単に移動できる環境にデプロイされた2つのUbuntu 14.04サーバーが必要です。 DigitalOceanでは、https://www.digitalocean.com/community/tutorials/how-to-use-floating-ips-on-digitalocean [Floating IPs]がこの機能を提供できます。 これらのサーバーは、ステージングと実稼働に代わりに使用される2つの並列環境を表します。 これらのサーバーは自由に呼び出すことができますが、このガイドでは「青」と「緑」と呼びます。
これらの各サーバーには、管理機能用に設定された `+ sudo +`を持つ非rootユーザーが必要です。 これらのユーザーは、https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [Ubuntu 14.04初期サーバーセットアップガイド]に従って構成できます。
Blue-Green Deploymentとは何ですか?
ブルーグリーン展開の背後にある基本概念は、Martin Fowlerのhttp://martinfowler.com/bliki/BlueGreenDeployment.html [この投稿]で人気のある手法であり、それぞれが本番環境でアプリケーションを提供できる2つの環境です。 、維持されます。 これら2つの環境はほぼ同一である必要があります。 慣例により、これらは青と緑の環境と呼ばれます。
これらの環境の1つだけがアクティブであり、実稼働トラフィックを一度に受信します。 これらの環境(Webサーバーまたはロードバランサー)のWebエンドポイントの前で、ルーターまたは他のトラフィックダイレクティングメカニズムは、すべての運用トラフィックを現在アクティブな環境にプッシュします。
新しいリリースが計画されると、非アクティブ環境に展開されます。 青緑展開の場合、非アクティブ環境は最終的なステージング環境として機能します。 実稼働環境を非常によく反映しており、変更をライブにプッシュする前に最終テストに使用できます。
展開を内部でテストし、その堅牢性に自信を獲得したら、ルーティングメカニズムを調整することで、新しいバージョンを迅速かつ簡単にリリースできます。 基本的に、すべての実動トラフィックが新しいソフトウェアバージョンに移動し始めるように、トラフィックディレクティングレイヤーでスイッチを切り替えます。 以前にアクティブであった環境は非アクティブになり、以前のステージング環境は新しい実稼働環境になります。
この時点で、以前のソフトウェアバージョンはアクティブではありませんが、アクセス可能です。 新しくアクティブになったデプロイメントに重大な問題がある場合、以前のバージョンに戻すことは、ルーティングメカニズムを再度変更するのと同じくらい簡単です。
シナリオ例
この一般的な概念を示すために、2つのサーバー環境をセットアップします。 それぞれにWebサーバーがインストールされます。 この例では、Webサーバーはアプリケーションスタック全体を表し、ロードバランサー、複数のWebサーバー、および分散または複製されたデータベースをバックエンドに含めることができることに注意してください。 このリリースパターンを示すことができる最小の環境を表すため、このガイドではWebサーバーを使用しています。
ローカルコンピューターで「アプリ」の開発を開始します。 実際には、これはサーバーにデプロイできる + 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-separate-production-server [
+ git ` post receive hook]を実行すると、 ` git push +`を発行するだけでデプロイできます。 アプリケーションの初期バージョンを両方のサーバーにデプロイします。
このガイドでは、ルーティングメカニズムとしてDigitalOcean Floating IP addressを使用します。 フローティングIPは、あるサーバーから別のサーバーにトラフィックを移動するためのシンプルなメカニズムを提供します。 フローティングIPを作成し、グリーンサーバーをポイントして、これを最初の実稼働マシンとして設定します。
次に、アプリケーションを変更して、ブルーサーバーにデプロイします。 この時点では、運用トラフィックは未変更のグリーンサーバーから引き続き提供されます。 その後、青いサーバーをテストして、展開が成功し、バグがなかったことを確認できます。 準備ができたら、フローティングIPアドレスを青いサーバーに再割り当てするだけで、フローティングIPを新しいバージョンのコードに移動できます。
ローカルアプリケーションを作成する
「アプリケーション」を作成することから始めます。 前述のように、これは実際にはWebサーバーが表示できる単なるインデックスページです。 これにより、実際の開発のオーバーヘッドなしで、アプリのさまざまな「バージョン」を実証できます。
ローカルシステム(または別のドロップレット)で、プラットフォームの推奨方法を使用して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"
ファイルをコミットしたら、ローカルマシンでのアプリケーション開発を一時的に停止し、青と緑のWebサーバーのセットアップに集中します。
青と緑のWebサーバーを構成する
次に、機能するWebサーバーを使用して緑と青の環境を設定します。 このガイドではApacheを使用します。 `+ sudo +`ユーザーでサーバーにログインして開始します。
Note
`+ apt +`でApacheを簡単にインストールできます。 次を入力して、ローカルパッケージインデックスを更新し、Webサーバーソフトウェアをインストールします。
sudo apt-get update
sudo apt-get install apache2
これにより、両方のWebサーバーにApacheがインストールおよび起動されます。
次に、「展開」ユーザーを作成して構成する必要があります。 このユーザーは、Apache Webルートにアクセスし、アプリをプッシュするベア `+ git`リポジトリを所有します。
次を入力して、 `+ deploy +`ユーザーを作成します。
sudo adduser --disabled-password deploy
これにより、パスワード認証が無効な新しいユーザーが作成されます。
この新しいユーザーに、ApacheのデフォルトのWebルートに対する所有権を付与します。 これは `+ / var / www / html`にあります。 次のように入力して、このディレクトリの所有権を変更します。
sudo chown -R : /var/www/html
これが、ファイルをWebルートに移動するだけの単純な展開に必要なすべてです。
Note
GreenおよびBlue WebサーバーでのGit展開のセットアップ
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 +`ブランチのすべての変更をWebディレクトリにデプロイします。 以下のスクリプトに変更は必要ありません。
/ 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
このガイドから逸脱していて、より複雑な展開手順が必要な場合は、上記のスクリプトの `+ then `句に追加してください。 このセクションで昇格された特権を必要とするすべてのステップで、 ` sudo `コマンドを使用するようにしてください。 また、ここで ` sudo `を使用するすべてのコマンドが、最後のセクションの下部で指定されているように ` sudoers +`ファイルに追加されていることを確認してください。
完了したら、ファイルを保存して閉じます。
`+ git `が適切なタイミングで実行できるように、 ` post-receive +`フックのパーミッションを変更します。
chmod +x hooks/post-receive
ブルーサーバーとグリーンサーバーでのSSHキーアクセスの構成
次に、SSHキーを設定して、 `+ git +`がパスワードを要求せずにWebサーバーに変更をプッシュできるようにします。
開発マシンで公開鍵を作成または表示します
*ローカルまたは開発用コンピューター*で、次のように入力して、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
すべてのプロンプトでEnterキーを押して、デフォルト値を受け入れます。 キーが作成されたら、 `+ 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リモートを構成する
WebサーバーへのSSHキーアクセスが設定され、各サーバーにアプリケーションディレクトリが設定されたので、ローカルの「+ git +」アプリリポジトリにリモートとしてブルーサーバーとグリーンサーバーを追加できます。
ローカルマシンで、アプリケーションディレクトリに戻ります。
cd ~/sample_app
リモート参照を追加して、 `+ git +`が緑と青のWebサーバーに変更をプッシュできるようにします。
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:」で始まる行には、サーバーの「+ post-receive 」フックからの「 echo +」ステートメントが含まれています。 アプリを両方のサーバーにプッシュすることを忘れないでください。
curlを使用して、アプリの初期展開が成功したことをテストできます。
curl
curl
これらの呼び出しの両方について、応答は次のようになります。
OutputApp v1
これは、展開スクリプトが正しく機能することを示しています。
トラフィックをルーティングするためのフローティングIPアドレスのセットアップ
アプリケーションの初期バージョンがデプロイされたので、フローティングIPアドレスを作成し、最初に「グリーン」サーバーを指すことができます。
DigitalOceanコントロールパネルで、[ネットワーク]タブをクリックしてから、[フローティングIP]メニュー項目をクリックします。 提供されたメニューで、緑色のサーバーを選択し、「フローティングIPの割り当て」ボタンをクリックします。
image:https://assets.digitalocean.com/articles/blue_green_deployment/create_ip.png [DigitalOcean create Floating IP]
数秒後、IPがグリーンサーバーに割り当てられます。
image:https://assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [割り当てられたDigitalOceanフローティングIP]
これで、このIPアドレスを運用アプリケーションの展開への主要なエントリポイントとして使用できます。 Webアプリのドメイン名を設定する場合は、ドメインをこのフローティング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
ただし、* blueサーバーの通常のIPアドレス*をチェックアウトすると、アプリケーションのバージョン2をテストできます。
curl
OutputApp v2
これは私たちが期待するものであり、私たちが望むものです。 これで、必要な内部テストを介してブルーサーバー環境を実行できます。 その間、緑のサーバーは引き続き本番トラフィックを処理します。
生産を新しい環境にひっくり返す
アプリケーションの最新バージョンをテストし、期待どおりに動作していると確信できたら、運用トラフィックを青いサーバーに切り替えることができます。
そのための最も簡単な方法は、DigitalOceanコントロールパネルにアクセスすることです。 「ネットワーク」タブをクリックして、「フローティングIP」ナビゲーション項目を選択します。 「フローティングIP」リストに、現在グリーンサーバーを指しているフローティングIPが表示されます。
image:https://assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [割り当てられたDigitalOceanフローティングIP]
切り替える前に、ターミナルウィンドウの1つで「+ while」ループを開始して、フローティングIPアドレスを介して繰り返しリクエストを行うことができます。 これにより、本番アプリケーションのバージョンがv1からv2に移行したことがすぐにわかります。
while true; do curl ; sleep 2; done
Webリクエストの結果の出力を開始する必要があります。
OutputApp v1
App v1
App v1
App v1
ここで、スイッチを作成してソフトウェアの新しいバージョンを「リリース」するには、フローティングIP割り当ての右側にある青いボタンをクリックして、IPアドレスを再割り当てします。 青いサーバーを選択します。
image:https://assets.digitalocean.com/articles/blue_green_deployment/reassign_ip.png [DigitalOcean reassign IP address]
数秒で、フローティングIPがブルーサーバーに再割り当てされます。 端末ウィンドウで、切り替えが明確になります。
OutputApp v1
App v1
App v2
App v2
「CTRL-C」を押して、「+ while +」ループを停止します。
本番トラフィックは、アプリケーションの新しいバージョンにルーティングされています。 これで、以前の運用サーバーである緑のサーバーが、ロールバックマシンと次のステージングエリアの両方として設定されました。
トラフィックを新しいバージョンのアプリケーションに移動した後に問題を発見した場合、このリリース戦略により、以前のバージョンに迅速かつ簡単にロールバックできます。 これを行うには、プロセスを逆にして、フローティングIPアドレスをグリーンサーバーに戻すだけです。
データベースの更新に対処する
上記のシナリオは、展開およびリリース戦略自体に焦点を合わせるために簡素化されました。 ただし、より複雑ではなく、データベースが関係するような一般的な設定については触れませんでした。
2つの環境間で永続データを処理するために使用できるいくつかの異なる戦略があります。
環境ごとに個別のデータベースを維持することができます。 ただし、この戦略では、運用データベースのデータを非アクティブデータベースに複製し、切り替えを開始する瞬間にトランザクションを停止する必要があります。 基本的には、データベースのライブマイグレーションと、各展開でのダウンタイムが必要です。 これはすぐに非常に時間がかかり、エラーが発生しやすくなります。
より良い代替策は、通常、緑と青の環境間で単一のデータベースシステムを共有することです。 データベース自体は両方の環境で使用されますが、アプリケーションコードは青緑のリリース戦略を使用して切り替え可能です。
このアプローチの主な関心事は、後方互換性のないデータベース移行を含む更新を展開およびリリースする方法です。 現在の運用展開で機能しない方法でデータベースに追加または変更するステージングに新しいリリースを展開すると、アプリケーションが破損します。
これを防ぐには、多くの場合、コードベースの展開とは別に、必要に応じて段階的に移行を展開するのが最善です。 この変更されたプロセスは、http://blog.dixo.net/2015/02/blue-turquoise-green-deployment/ [blue-turquoise-green deployment]と呼ばれることもあります。 基本的には、データベースの古いバージョンと新しいバージョンの両方を処理できるアプリケーションコードの中間バージョンを展開することにかかっています。
中間アプリケーションコードは、古いバージョンとほぼ完全に同じですが、移行が行われた後に存在する新しいデータ構造に対応するためのいくつかの追加ロジックがあります。 多くの場合、これは、既存のデータ構造を変更するのではなく、完全に新しいデータ構造を作成するように移行を構築することで実現されます。 このようにして、古いデータ構造(テーブルなど)を保持し、重大な変更を含む新しいデータ構造を作成できます。
中間の青緑色の展開は、移行プロセスの最初のステップとして展開されます。 この展開では、最初に古いテーブルの読み取りと書き込みが行われますが、新しい構造の存在が確認されます。 次に、移行自体が実行され、古いバージョンとともに新しいバージョンのデータ構造が作成されます。 ターコイズブルーの展開のロジックは、新しい構造が配置されていることを認識し、古い構造と新しい構造の両方に変更の書き込みを開始するように構成する必要があります。 しばらくの間、古い構造から読み取りを続けます。
この時点で、すべての新しいアクティビティが両方のデータ構造に記録されます。 新しい構造に古い構造からのデータを埋め戻し、新しい構造の条件を満たすように変換することができます。 これが完了すると、すべてのレコードが両方の場所に存在するはずです。 移行を続行するために、次のアプリケーションデプロイメントは両方の構造に書き込みを続けますが、新しい構造から読み取る場合があります。 すべてが順調に実行されていることが確認された後、別の展開によって古い構造からの書き込みが遮断され、古い構造が削除される場合があります。
このプロセスは、最初はかなり複雑に思えるかもしれませんが、通常は実際には追加作業があまり多くありません。 主な作業には、レガシーと新しい構造の両方を一時的に使用するセーフティネットの構築が含まれます。 これにより、移行をコミットする前に詳細に移行をテストする時間ができ、データ構造の以前の作業バージョンにいつでもロールバックできます。 このデータの移行方法の例については、EtsyのMike Brittainのhttp://www.slideshare.net/mikebrittain/mbrittain-continuous-deploymentalm3public/50 [これらのスライド]をご覧ください。
結論
展開を新しいコードの実際のリリースから分離するために採用できる他の多くの戦略がありますが、青緑色の展開は実装が簡単なかなり単純なメカニズムです。 本番環境を完全にミラーリングする優れたステージング環境を提供すると同時に、リリースが予期したとおりに進まなかった場合、リリース後すぐにロールバックの機会を提供します。