リリース候補(RC)とは何か、どう運用するか
1分で読めます
リリース候補(RC)とは、チームが出荷できる状態だと考えているビルドのことだ。機能は出そろい、計画したテストを通過していて、リリースを止めるほど深刻なバグが見つからない限り、そのまま最終リリースになる。このラベルはビルドについての約束で、新機能は入れず、直すのはブロッカーだけという意味だ。修正が必要になったら、チームは新しい候補を作り、最初から数え直す。
| 段階 | 機能 | 対象 | 期待される状態 |
|---|---|---|---|
| アルファ | まだ追加中 | 社内チーム | 未完成で、既知のバグが多い |
| ベータ | 完成またはほぼ完成 | ボランティアと選ばれた顧客 | 使えるが、バグは想定内 |
| リリース候補 | 凍結 | テスターとアーリーアダプター | 出荷可能と考えられ、直すのはブロッカーのみ |
| 一般提供(GA) | 凍結 | 全員 | 最後のRCと同じビルド |
ソフトウェアにおけるリリース候補とは何か
一般提供の前の、最後のプレリリース段階だ。考え方としては、そのビルドが最終版の候補であり、リリースは新しくビルドし直すのではなく、同じビルドを昇格させて行う。Wikipediaのソフトウェアのリリースライフサイクルの記事も、アルファ、ベータ、リリース候補、リリースという同じ流れを説明しており、これらの用語はオープンソースのプロジェクトやベンダーの間で広く通じる。
ベータとリリース候補の違いは何か
ベータはまだ変更が許される。機能を調整でき、インターフェースも動かせて、足りないものや間違っているものを知ることが目的だ。リリース候補はそうした変更を止めていて、リリースを妨げるものがないと確認することが目的になる。実際の見分け方は、バグ報告にチームがどう対応するかだ。ベータでは、報告が設計の変更につながることがある。RCでは、報告を受けて直すのはそのバグが出荷を止めるときだけで、それ以外は次のバージョンの待ち行列に回す。
リリース候補にはどうバージョンを付けるか
これから出荷するバージョンにプレリリースの接尾辞を付ける。セマンティックバージョニングでは、ハイフンに続けてドット区切りの識別子を置くとプレリリースを表す。2.4.0の最初の候補は 2.4.0-rc.1、次は 2.4.0-rc.2 で、リリースは接尾辞のない 2.4.0 になる。
優先順位は仕様に従う。2.4.0-rc.1 は 2.4.0-rc.2 より下に並び、どのプレリリースもリリースより下に並ぶ。識別子は一つずつ比較され、数値は数として比べられるので、rc.10 は rc.9 より上に並ぶ。alpha、beta、rcという名前は、アルファベット順に並べても正しい順序になり、これもチームがこの名前を使う理由の一つだ。各候補はgitでタグを付け、gitタグとリリースで説明している方法で、正確なコミットを記録する。
リリース候補の終了条件は何か
最初のRCを切る前に書き出しておく。実用的な一組は次のとおりだ。
- 自動テストが、ビルドしたそのコミットで通っている。
- 前のリリースからのアップグレード経路が、現実的なデータでテストされている。
- 既知の問題が仕分けされ、ブロッカーと評価されたものがない。
- パフォーマンスとエラー率が、合意した範囲内で前のリリースと一致している。
- リリースノートが下書きされ、最終的な変更リストと照らしてレビューされている。
- ロールバックの手順があり、誰かがそれを読んでいる。
候補についてすべての項目が満たされたら、その候補がリリースになる。一つでも満たされなければ、修正によって新しい候補ができ、確認はやり直しになる。この流れを、各ステップの担当者とともに七つのステップにまとめたものがリリース管理プロセスにある。
RCが通ったらビルドをどう扱うか
同じ成果物を昇格させる。タグからビルドし直してはいけない。ビルドし直すと別の依存関係やコンパイラの出力を取り込むことがあり、行ったテストは元のビルドに対するものだからだ。多くのチームは、タグを付け直すか、レジストリのラベルを付け替えて候補の名前を変え、テストされたバイト列がそのままユーザーのダウンロードするものになるようにしている。
パッケージの場合は、候補を別のチャンネルで公開し、通常のユーザーが誤って受け取らないようにする。npmなら npm publish --tag rc を使えば、既定の latest タグはそのままで、@rc を指定した人だけが候補を受け取る。コンテナイメージやモバイルのビルドにも、プレリリースのタグ、段階的ロールアウト、TestFlight型のトラックなど、別の名前で同じ考え方がある。
リリース候補のリリースノートはどう書くか
最初のRCからノートを書き始め、候補に合わせて更新していく。テスターには、何が変わったか、何を確認すべきか、何が壊れていると分かっているかを知らせる必要がある。早く下書きすれば、最後に誰も覚えていない項目も見つかる。ページやGitHubのリリースをプレリリースとして印を付け、最終版と間違われないようにし、出荷時に完成した文面をGAのリリースに移す。構成と内容はソフトウェアのリリースノートに、GitHub側はGitHubのリリースノートにある。
SaaSチームにリリース候補は必要か
継続的にデプロイするチームでは、ほとんど必要ない。本番へのデプロイがテストであり、フィーチャーフラグで誰が変更を見るかを制御するからだ。リリース候補が役に立つのは、ユーザーが自分でソフトウェアをインストールし、デプロイでロールバックできない場合だ。ライブラリ、デスクトップやモバイルのアプリ、セルフホスト型の製品、長く使われるクライアントを持つAPIがそれにあたる。変更を少しずつ公開するホスト型の製品では、これに相当するのが段階的ロールアウトで、伝え方の面からフィーチャーフラグのリリースノートの記事で扱っている。
FAQ
ソフトウェアにおけるRCとは何を意味するか? RCはリリース候補(release candidate)の略だ。テストでブロッカーとなるバグが見つからない限り、チームが最終版として出荷するつもりのビルドを指す。アルファとベータの段階のあとで、一般提供の前に来る。
リリース候補は本番で使えるほど安定しているか? ステージング環境や限定的な本番環境でのテストなら、たいてい使える。ただしテストが終わっていないかもしれないので、最終リリースにはないリスクがある。本番品質のコードだが、まだ試用期間中だと考える。
リリースにはリリース候補をいくつ用意すべきか? 必要なだけで、ほとんどのリリースは一つから三つで足りる。候補が長く続くときは、凍結を早く宣言しすぎたか、テストの網羅がうまくいっておらず問題の発見が遅れていることが多い。
リリース候補は変更なしで最終リリースになれるか? なれる。それが想定された結果だ。最終リリースは最後の候補と同じビルドで、名前やラベルをGAに変えるだけにする。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。