通常のデプロイ手法は、ステージング環境へのデプロイを経て、十分にテストを実施した後に本番環境へのデプロイを行い、全てのユーザが新しいサービスに触れることができるのが一般的ですが、カナリアリリースはその手法が特殊です。

新規プロダクトやサービスを本番環境の一部分にデプロイし、先に一部のユーザに提供することで新機能のフィードバッグをいち早く得ることで機能としての必要性を受け取ったうえで、全てのデプロイを行うという方法です。

あるいは、複数のノードで構成された運用サーバの一部分のノードにのみリリースを行い、デプロイされた一部のノードにてテストを実施してから、全てのノードへのデプロイを行うといった方法もカナリアリリースと呼ばれております。

複数のノードの一部分のノードのみにデプロイを行う為、問題が起こった時は、本番環境からそのノードを切り離すだけでロールバックができる事もメリットの一つです。

運用するサービスによっては、カナリアリリースを行う事で多大な影響を与える可能性もあるので、デプロイ手法は運用するサービスによって考えなければなりません。

一部のユーザの部分をさらに限定的（開発者のみ等）にし、本番環境と同等のデータを用いてテストをする手法として「ダークカナリアリリース」という手法もあります。

従来のサーバ環境(主にオンプレミスの環境)の運用の手法は、構築した環境に対して既存のソフトウェアの運用管理をしつつ設定を更新していく運用方法が一般的でした。

近年ではクラウドサービスを利用して仮想サーバ環境の入れ替えを行う様々な手法が用いられています。

ブルーグリーンデプロイメントはその手法のひとつであり、「ブルー」と「グリーン」の2つの環境を用意して、デプロイする際に2つの環境の役割を切り替える手法です。

例えば、サーバAが本番環境として運用されている場合、サーバBをサーバAのアップデート済み環境(別の環境)として用意しておくとします。

サーバAの環境を「ブルー」、サーバBの環境を「グリーン」と呼び、「ブルー」から「グリーン」へリクエストの向きを変える事でデプロイが完了する手法となります。

もし、サーバBの環境の「グリーン」に問題が起こった場合は、サーバAの環境の「ブルー」にリクエストの向きを戻す事で容易にロールバックを行う事ができます。

デプロイ後、「ブルー」と「グリーン」の位置づけは変わり「ブルー」をサーバBの環境、「グリーン」をサーバAの環境として運用していくことで、次のブルーグリーンデプロイメントに向けた継続的なデプロイを行う事ができます。

デプロイを行わない期間は、グリーンのサーバの運用コストを低く抑える為の考慮が必要ではありますが、継続的にデプロイを行う為に必要な運用と考えられてます。

ブルーグリーンデプロイメントとは似たようなデプロイの手法ですが、こちらは継続して環境を使いまわすわけではなく、常にImmutable = 不変(変更を行わない)な環境を構築してデプロイ時に、新しい環境に切り替える手法となります。

新しい環境に切り替わった際に、古い環境が必要なくなった場合（ロールバック等行わなくてよい）は、その環境を削除してしまう点がブルーグリーンデプロイメントとの大きな違いです。

クラウドサービスの利用及びコンテナ化が進んできた現在では、構成管理ツールを利用する事で環境自体を新しく構築する作業が容易に行えるようになったことで誕生したデプロイ手法であり、運用コストの面でもメリットは大きいです。