ビックバンリリースを避ける
Webサービスのリリースの話。ビックバンリリースは簡単に言えば大きなリリースのこと。ビッグバンとまでいかずとも、大きなリリースを避けて小さくリリースしたいと思っている。
どれくらいが大きいかの明確な基準はないが、以下のようなリリースは個人的には大きいリリースだと思う。
- 着手開始からリリースまで数週間以上かかる
- リリースに含まれる変更ファイル数が数十ファイル以上ある
- リリースに含まれる変更行数が数百、数千行以上ある
数十や数百の「数」もかなりものによるので、曖昧で申し訳ない。主観的に大きいなと感じたらそれは大きいと見なしてもいいのかもしれないとも思う。また、リリースするのが怖いと感じたら大きなリリースのサインでありうる（ただし、クリティカルな機能に対する変更や初めて触れる機能に対する変更だからといった理由を除く）。
大きなリリースを避けたい理由は沢山ある。
- 実装
- 時間がかかる
- テスト
- 影響範囲が読みにくくなる
- 確認箇所が多い
- PRレビュー
- 変更ファイル数や行数が多い
- レビューし始めるのに気合がいる
- まとまったレビュー時間を要する
- コメント数が多くなる
- レビューの往復回数が多くなる
- レビューに時間がかかる
- リリース
- リリース時期が予測しにくい
- 不具合や障害が発生したときの切り戻しが大変
（PRレビューをすることが多いのでPRレビューの項目が多くなってしまっている） これらのデメリット、リスクを避けたいので、大きなリリースを避けて小さくリリースしたい。
小さくリリースするために、実装に着手し始める前にあらかじめ小さくリリースできないか、計画をする。分割してリリースできるものはないか、リファクタリングだけ先にリリースできないか、ユーザーに見えない範囲でリリースできないか等、切り出してリリースできるものを探す。
リリースを小さくすることによるデメリットは当然ある。PRの数が多くなり、レビューの数が増える。リリースの待ち時間や作業の手間の回数が増える。しかし、トータルで見るとコストも安く、リスクも小さいように思う。また、リリースの待ち時間を減らすためにビルドやデプロイ時間の短縮に力を入れたり、リリース手順の簡略化など取れる手はある。
大きなリリースを避けて、小さくリリースしたいということを書いてきた。大きなリリースを避けて、小さくリリースしたい。
