カナリア放出戦略と青/緑
カナリアリリースの私の理解は、スティッキーセッションがオンになっている実稼働ノードのサブセットへの部分的なリリースであるということです。そうすれば、悪いバグをリリースした場合に影響を受けるユーザー/顧客の数を制御し、最小限に抑えることができます。
私の理解ブルー/グリーンリリースでは、2つのミラー化された実稼働環境（「ブルー」と「グリーン」）があり、ブルーまたはグリーンのすべてのノードに変更を一度にプッシュします。次に、ネットワークマジックを使用して、ユーザーがDNS経由でルーティングされる環境を制御します。
それで、始める前に、これまでに言ったことが間違っているなら、私を修正することから始めてください！
多かれ少なかれ順調に進んでいると仮定すると、2つの戦略に関する質問がいくつかあります。
- カナリアが青/緑よりも好まれるシナリオがありますか？
- 展開モデルが両方の戦略を同時に実装できるシナリオはありますか？
青緑色のリリースはより簡単で高速です。
canテスト環境で新しいバージョンをテストし、新しいバージョンが本番環境で正しく機能することを確信している場合は、青緑色のリリースを行います。常に feature toggles を使用することは、誰かが機能を切り替えるまで新しいバージョンが古いものとまったく同じように機能するため、新しいバージョンに対する自信を高める良い方法です。アプリケーションを小さな独立してリリース可能なサービスに分割することも別の理由です。テストする必要が少なく、破損する可能性も少ないからです。
need to新しいバージョンが本番環境で正しく機能することを完全に確信できない場合、カナリアリリースを行います。たとえあなたが徹底的なテスターであっても、インターネットは大きく複雑な場所であり、予想外の課題に常に直面しています。機能トグルを使用しても、正しく実装されない可能性があります。
展開の自動化には手間がかかるので、ほとんどの組織は毎回いずれかの戦略を使用することを計画します。
そのため、自信を持って行うことができるプラクティスにコミットしている場合は、ブルーグリーン展開を行います。それ以外の場合は、カナリアを送ります。
青緑色の本質は一度に展開され、カナリア展開の本質は段階的に展開されるため、ユーザーの単一プールを考えると、両方を同時に行うプロセスとは考えられません。複数の独立したユーザープールがある場合、たとえば異なる地域のデータセンターを使用すると、各データセンター内で青緑色を実行し、データセンター全体でカナリアを実行できます。データセンター内でカナリアを導入する必要がない場合は、おそらくデータセンター間でカナリアを導入する必要はないでしょう。
このトピックに関する詳細なエッセイをここに書きました： http://blog.itaysk.com/2017/11/20/deployment-strategies-defined
私の意見では、違いは、新しい「グリーン」バージョンが実際のユーザーに公開されるかどうかです。もしそうなら、私はそれをカナリアと呼びます。 Canaryを実装する一般的な方法は、特定のユーザーの新しいバージョンへのスマートルーティングを追加した通常のブルー/グリーンです。詳細な比較については投稿をお読みください
青/緑： 
カナリア： 
ブルー/グリーンとカナリアの両方のリリースは、ソフトウェアの機能をより多くのユーザーにリリースする前に、ターゲットとするユーザーに対してソフトウェアをテストするという同じ目的を解決します。カナリアの場合、展開は下の同じインフラストラクチャを共有できますが、ブルー/グリーンの場合、インフラストラクチャ全体がルーティングトラフィックのためにルーター/ DNS /リバースプロキシと前面に複製されます。
インフラストラクチャのスクリプト化と再作成が簡単なクラウド環境では、インフラストラクチャを自動化と同期できるため、ブルー/グリーン展開が推奨されます。これは、環境を再作成する機能が必要なときに持つ素晴らしい機能です。
より詳細な比較については、以下の記事を参照できます。
BlueGreenデプロイメント： http://martinfowler.com/bliki/BlueGreenDeployment.html
これらの用語はどちらも非常に近いように見えますが、微妙な違いがあります。 1つは機能のリリースに自信を置き、もう1つはリリース方法に自信を置きます。
カナリア
カナリアリリースは、インフラストラクチャ全体に展開する前に、ユーザーの小さなサブセットに変更をゆっくりと展開することにより、運用中に新しいソフトウェアバージョンを導入するリスクを軽減する手法です。
新しいバージョンがどのように実行されるかについてのアイデアを得ようとしています（他のアプリ、CPU、メモリ、ディスク使用量などと統合します）。
青/緑：
- ダウンタイムなしの展開で予測可能なリリースについてです。
- 障害が発生した場合の簡単なロールバック。
- 完全に自動化された展開プロセス
定義の良いスタート。また、「リリース」の定義を「デプロイ」と「リリース（機能）」に分割すると、戦略の決定に役立つと思います。
デプロイ（バイナリ）
製品の（運用）システムへのバイナリ展開のアクション。
リリース（機能）
ユーザー（のグループ）に対する機能の可用性を管理するアクション。
どうして？通常、「リリース」する際には（複数の）2つの懸念事項があります。1）バグ/後方互換性/ etc 2）新機能の有効性/有用性の検証
次に、カナリア、ブルー/グリーン、またはグレー/ミックスモードの戦略を選択する前に、次のことを自問してください。新しいバージョンをリリース/展開するとき、どのような懸念がありますか。そして、懸念を知っている場合にのみ、戦略を選択してください。
さらに、より複雑な展開/リリース戦略を実行することもできます。たとえば、一部のクラウド/インフラでは、複数の実稼働サーバーを使用し、異なるサーバーおよび製品のバージョンに異なる割合で負荷を中継し、リリース/デプロイをすべてのユーザーに拡大する前に健全性を監視することができます。
機能のフラグ付け
どの機能をユーザーのどの（グループ）で利用可能（利用不可）にするか（「コールド」または「ホット」）を設定するアクション
「機能フラグ」なども行う場合は、最初に展開し、後方互換性/バグの観点からリリースの健全性を測定し、新しい機能を徐々に異なるユーザーにリリースするか、その逆（スケールダウンまたはロールバック機能やバイナリ） ）。機能のフラグ付けにより、機能の可用性をバイナリの展開から分離でき、「展開/ロールバック」のみよりもはるかにきめ細かい意思決定が可能になります。