頻繁にリリースするチームのためのリリース管理プロセス

リリース管理プロセスとは、変更を「マージ済み」から「本番で動いていて、影響を受ける人に説明されている」状態まで進める一連のステップだ。頻繁にリリースするチームなら、7つのステップに集約される。スコープの計画、変更の分離、ビルドとテスト、承認、デプロイと検証、連絡、そして振り返りだ。各ステップには、名前のある担当者と一つの完了条件が必要で、なければ、いつの間にか行われなくなる。

このガイドは、週次または毎日デプロイし、プロセスが邪魔にならないようにしたい、5人から50人のエンジニアのチームを想定している。

リリース管理プロセスとは何か

変更がユーザーに届くまでにたどる、繰り返せる道筋のことだ。スコープ、ビルド、テスト、承認、デプロイ、検証、告知、そして振り返り。これを書き出す意味は、すべてのリリースが同じ道筋をたどるので、休暇中の人も、新入社員も、午前2時のオンコールのエンジニアも、誰にも聞かずに実行できるようになることだ。

リリース管理にはどんな種類があるか

実用的には三つの種類がある。継続的デプロイ、定期リリース、そして規制対応の変更管理だ。リリースの前にどれだけのことが行われ、どれだけが自動化されているかが違う。継続的デプロイはマージされたすべての変更を出荷し、定期リリースは変更をまとめてトレインに載せ、規制対応の変更管理は正式な承認と監査証跡を加える。

ほとんどのチームは混合型だ。SaaS製品は継続的にデプロイしながら、モバイルアプリは週次のトレインで出し、監査人が気にする決済サービスだけは正式な変更記録に従う、ということがある。種類は会社ごとではなく、サービスごとに選ぶ。変更が段階的にしか公開されない場合、リリースと告知は別々のイベントになる。そのケースはフィーチャーフラグのリリースノートで扱っている。

リリースマネージャーの責任は何か

リリースマネージャーは、変更が本番に至る道筋を管理する。リリースカレンダーを保ち、変更の準備ができているかを判断し、デプロイを実行または監督し、ロールバックの判断を下し、ユーザーに確実に伝え、その後の振り返りを行う。

リリースの前には、スコープを確認し、リスクのあるすべての変更にロールバックの手順があるかをチェックする。リリース中は、デプロイのチェックリストを実行し、本番の指標の最初の数分を見守り、早めにロールバックを判断する。その後は、ノートが出されたことを確認し、プロセスで直すべき点を記録する。

小さなチームでは、この役割を週ごとに交代し、誰も暗黙知を必要としないようにチェックリストを書いておく。独立してリリースされるパッケージが多いモノレポでは、通常、パッケージごとにリリース担当者が必要で、そうしないとこの役割がボトルネックになる。

リリース管理の主なKPIは何か

DORAのソフトウェアデリバリー指標を追跡し、自分たちの指標を一つ加える。ユーザーに伝えるまでにかかる時間だ。DORAの調査は五つの指標を挙げており、スループット(変更のリードタイム、デプロイ頻度、失敗したデプロイからの復旧時間)と不安定性(変更失敗率、デプロイのやり直し率)に分かれる。

DORAのガイドは、それらを平易な言葉で定義している(dora.dev、ソフトウェアデリバリー指標)。

古い資料は四つの指標を挙げ、復旧を「復元までの時間」と呼んでいる。現在のガイドは、上の五つを使っている。

同じガイドは、これらを目標として扱うことに警告している。「年末までにすべてが1日に何度もデプロイされるように」といった目標を設定すると、チームが数字をごまかす原因になり、指標は会社全体で混ぜずに、アプリケーションやサービスごとに読むものだ。そのすべてを改善するための実践的な助言は、一つひとつの変更の大きさを縮めることだ。小さい変更は、レビューしやすく、パイプラインを通りやすく、復旧しやすいからだ。

リリースの連絡は、リリース管理プロセスのどこに位置づくか

6番目のステップで、他のステップと同じように担当者と完了条件がある。ユーザーが読む場所にノートが公開され、社内のチームに伝わっていることだ。デプロイのツールは、コードが公開された瞬間に成功を報告するので、チームが最もよく飛ばすステップでもある。

このステップを予定どおりに保つ最も安上がりな方法は、リリースが出荷されるときではなく、変更がマージされるときにエントリを書くことだ。プルリクエストには、すでにタイトル、作者、リンクされたIssue、背景がある。それから作った下書きは、一週間後に記憶から書くのではなく、編集される。これがチェンジログの自動化の考え方だ。マージ時に下書きを作り、人が承認するまで保留し、一つの情報源からあらゆる場所に公開する。Changeloopはこの方式で動き、マージされたプルリクエストからAIでエントリの下書きを作り、何かが公開される前に承認を待つ。

あらかじめ計画しておく価値のあるバリエーションが二つある。サポートと営業には顧客向けとは違うノートが必要で、そのためにあるのが社内向けリリースノートだ。インシデント対応のリリースには、通常の下書きのループを回す時間がないので、緊急リリースノートで説明されているように、短いテンプレートを用意しておく。リリースノートのテンプレートは、顧客向けバージョンの出発点になる形を示している。

プロセスを軽く保つには

機械が確認できる完了条件はすべて自動化し、人は判断が必要なことに残す。グリーンのパイプライン、ダッシュボード上のデプロイのマーカー、マージされたプルリクエストごとのチェンジログの下書きは、確認できる。ロールバックの計画が信頼できるか、ノートが顧客に通じるかは、人が必要だ。

プロセスを試すには、先月のリリースを一つ選び、チームの外の誰かが、書かれた記録だけから、何が出荷され、誰が承認し、どう検証され、いつユーザーに伝えられたかを分かるかを問う。ギャップがあれば、それが次の改善点だ。

FAQ

リリース管理と変更管理の違いは何か? リリース管理は、一連の変更をビルドし、テストし、デプロイし、告知する。変更管理は、ITILの意味では、個々の変更を取り巻く承認とリスクのプロセスだ。頻繁にリリースするチームは、承認をコードレビューと自動チェックに組み込んでいる。

どのくらいの頻度でリリースすべきか? テストとロールバックの手順が許す限り頻繁に。多くのWebチームでは、それは毎日かそれ以上だ。DORAの指針は、一つひとつの変更の大きさを縮めることで、小さな変更はレビューしやすく、復旧しやすい。

小さなチームにリリースマネージャーは必要か? 責任は必要だが、肩書きは必ずしも必要ない。エンジニアの間で役割を交代し、当番の人に書かれたチェックリストを渡し、7つのステップそれぞれに担当者がいるようにする。

リリースのチェックリストには何を含めるべきか? スコープの確認、出荷するコミットでのパイプラインのグリーン、ロールバックの手順の明記、承認の記録、デプロイ後のスモークチェック、ベースラインとの指標の比較、リリースノートの公開、サポートへの連絡、振り返りの予定だ。一ページに収める。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： 開発者向けドキュメント, リリースノートのテンプレート