マージしたら、その日のうちに全ユーザーへ届く。
小さなチームのうちはそれで回っていても、変更が大きくなるほど出すたびに全員を巻き込む賭けになっていきます。
新しい機能を「いつ、誰に、どれだけの割合で見せるか」を組み立てるのが、リリース戦略という仕事です。
テックリードを目指して学んでいる筆者にとっても、ここはコードの書き方より先に決めておくべき領域だと感じました。
手がかりにしたのは、Martin Fowler のサイトに載っているフィーチャーフラグの解説と、Google の SRE Workbook。
デプロイとリリースを切り離す
リリース戦略の出発点は、デプロイ（コードを本番に置くこと）とリリース（ユーザーに機能を見せること）を別の出来事として扱うことにあります。
その切り離しを実現する代表的な道具が、フィーチャーフラグ（フィーチャートグル）です。
Pete Hodgson が2017年に書いたFeature Toggles (aka Feature Flags)では、フラグを使うと未完成の機能を「眠ったコード」のまま本番に出せると説明されています。
機能ブランチを何週間も抱え込まずに済むので、メインラインへこまめに統合する開発の進め方とも相性がいい。
コードを置くことと見せることが分かれていれば、見せる相手や割合をあとから調整できるようになるのです。
フラグは4種類あり、寿命がまったく違う
Hodgson の解説は、フラグを目的と寿命で4つに分けています。
リリーストグル
開発途中の機能を隠しておくためのフラグで、残す期間は1〜2週間程度が目安だそうです。
機能が出そろって全員に公開したら、役目は終わり。
実験トグル
ユーザーをグループに分け、どちらの挙動がよい成果を出すかを比べる A/B テスト用のフラグです。
同じユーザーが毎回同じ側に振り分けられるように、リクエストごとに判定するのが特徴になります。
運用トグル
障害時に重い機能を止めるなど、運用する人が本番の振る舞いをその場で切り替えるためのフラグ。
多くは短命ですが、負荷が高いときに重要度の低い機能を落とす「キルスイッチ」のように、長く残すものもあります。
権限トグル
有料会員や社内ユーザーなど、特定の人にだけ機能を見せるためのフラグで、年単位で残ることもある長命な種類です。
同じ「フラグ」でも、消すべき時期がまったく違うという点が、運用ルールを考えるときの前提になります。
段階リリースは「一部に出して、比べる」
フラグで見せ方を制御できるようになれば、新しい変更を一気に全員へ出す必要はなくなるはず。
Google の SRE Workbook の章Canarying Releasesは、カナリアリリースを変更の一部かつ期間を限った展開と、その評価と定義しています。
変更を入れた一部（カナリア）と、入れていない残り（コントロール）を並べて比べるのが要点。
ここで効いてくるのが、影響範囲の小ささです。
同書の例では、トラフィックの5%に出したカナリアで20%のエラーが出ても、サービス全体では1%にしか見えないと説明されています。
裏を返せば、全体の指標だけを眺めていても問題に気づけないので、バージョンごとに分けて測れる監視が前提になるわけですね。
同じ理由で、小さく出すことはエラーバジェットの消費を抑えることにもつながります。
エラーバジェットの考え方そのものは、SRE 連載の記事で整理しました。
同書は、カナリアを一度に1つずつ走らせることや、負荷が高い時間帯を含めて評価することも勧めています。
テックリードが先に決めておく3つのルール
フラグも段階リリースも、道具を入れただけでは運用が少しずつ崩れていくもの。
1つ目は、フラグを作るときに、消す段取りまで決めておくことです。
Hodgson は、フラグを維持コストのかかる在庫として扱い、数をできるだけ少なく保つよう勧めています。
具体策として挙がっているのは、リリーストグルを作ったら削除タスクをバックログに積む、期限を設けて過ぎたらテストを失敗させる、フラグの総数に上限を置く、といった方法でした。
消し忘れたフラグは分岐を増やし続けるので、技術的負債と同じく「利息」を払う対象として見える化しておきたいところ。
2つ目は、段階の刻みと判定の基準を先に書いておくこと。
何%から始めて、どの指標がどう動いたら次へ進むのか、どこで止めるのかを出す前に決めておけば、判断を当日の空気に任せずに済みます。
3つ目は、戻し方を用意しておくことです。
フラグで機能を切る、トラフィックを元の版へ戻すなど、悪化したときに何を操作するかを、決めた本人以外でも実行できる形にしておくと安心でしょう。
こうした決めごとは、Design Doc や ADR に残しておくとチームで共有しやすくなります。
最後に
リリース戦略の中心にあるのは、デプロイとリリースを分けるという一つの発想でした。
フラグで「誰に見せるか」を握り、カナリアで「どれだけに出して比べるか」を決め、役目を終えたフラグはきちんと片づける。
出す速さと安全さを両立させる仕組みを、コードより先にルールとして決めておくことが、テックリードの持ち場なのだと感じています。
以上です。
コメントを残す