リリース戦略の整理

All in Once

言葉の定義をよくわからなかったのでこの表現にしました。(一般的に呼ばれている名前があったら教えて欲しいです)
新旧バージョンのアプリケーションを1度に切り替えるリリース方式です。
新バージョンのアプリケーションと、旧バージョンのアプリケーションの互換性がない場合はこの方法1択になると思います。
リリースにバグが含まれていた場合すべてのユーザーに影響があります。

canary release

サービスの変更を一部ユーザーから段階的に全体に向けて展開していくリリース方式です。

どれだけテストやQAを実施したとしても、実稼働のトラフィック上で新バージョンのサービスに問題が見つかることは少なくない。という前提のもとに、
運が悪いユーザーがいることを許容することで大規模なサービスダウンを未然に防ぐ。また、ロールバックは早期に行い頻繁に行う。とういう戦略です。

メリット

実稼働のトラフィックを使用し、段階的にリリースする事で以下の指標を大幅に削減できます。

• 問題平均検知時間（MTTD）
• 平均修復時間(MTTR)
• 影響を受けるユーザー数

段階的にリリースする方法

リリース対象を限定して段階的にリリースしていく方法は大きく2つあります。

1. トラフィックをランダムで振り分ける方法
2. 条件分岐をする方法

1. トラフィックをランダムに振り分ける。

トラフィックをランダムに新バージョンに振り分けていき、システムアラートをモニタリングしながら徐々にトラフィックの振り分けの比率を変更していく方法。
一般的にカナリアリリースと言ったらはこの方法を指す事が多い。

2. 条件分岐をする方法

指定のユーザーIDやfeature toggleなどの条件分岐予め定義しておいて、新旧のバージョンのサービスに振り分ける方法。
一部のユーザーにのみ新サービスを公開する方法をsoft launchという。
マーティン・ファウラー曰くfeature toggleは最後の手段であるべきとの事。

Release toggles are a useful technique and lots of teams use them. However they should be your last choice when you're dealing with putting features into production.

See: https://martinfowler.com/bliki/FeatureToggle.html

ユーザテストの意味合いが強いと言う解釈。

ダークカナリアリリースとは？

条件分岐をする方法のカナリアリリースで、開発者のみを新バージョンのサービス利用できる状態にしておく事。主な用途はサービスのデモンストレーションや本番環境でのテストが必要な時に行う。

参考

Dark launch

稼働中のサービスに来たトラフィックを新バージョンのサービスにも流すことで実際のユーザのトラフィックを使用し、ユーザに影響与えずにテストする方法。
レスポンスは旧バージョンからのレスポンスを使用し、新バージョンのレスポンスは破棄する為ユーザーへの影響はないです。
シャドウプロキシともいう。
Cookpad製のkageが有名。他にもNginxやFluentdでやる方法など手段はたくさんある模様。

参考

Cookpadでのサービスリプレイス時の戦略

新サービスでは、リプレイス済みの場合は新サービスでリクエストを処理してレスポンスを返す。まだリプレイスしてない場合はエラーを返す。
新サービスからエラーが返ってきた場合は、旧サービスに再びリクエストを投げて旧サービスでリクエストを処理してレスポンスを返す。
https://techlife.cookpad.com/entry/2019/03/05/115000

同じCookpad製のgemのchankoのrevorkと同じ発想と言う解釈。