なぜリリース頻度を上げるのか 
top

サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。

リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。

リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になります。

リリース頻度は、プロダクションサイトでの問題発見から修正までのサイクルを縮めることにもなります。毎日リリースが行われていれば、小さなサービスの不具合は、ロールバックを行わずとも、翌日のリリースで修正できますが、週1回のリリースであれば、その不具合は1週間ユーザーの目に触れることになります。

リリース頻度を上げるための割り切り

リリース頻度を上げるための割り切りも行われています。

まず、以前は各リリースに入る機能が決まり、それらの開発が終わった時点でリリースが始まるスタイルだったものが、リリースは定期的に行われるようになりました。これにより、予定している開発が遅れてしまってもリリースは見切り発車します。遅れた機能はそれが完成した後、一番早いリリースに入れてユーザーに送り出します。たとえてみれば、東京駅から新幹線は次々に出発しますので、予約をせずに駅に行き、駅についた時点で次に出発する新幹線に乗るようなイメージです。

テスト(QA)は多くの場合、自動テストのみで人手によるテストはほとんど見られなくなりました。以前はリリースサイクルごとにテストのために数日の期間が取られていました。

リリース間隔が短いため、リリースに変更を取り込む条件も厳しくなります。リリースに入れるための条件、例えば自動テストをパスするなどの条件が満たされない場合は問答無用でそのリリースからはじき出されることになります。リリース期間が長い頃であれば、パッチを当ててリリースに再度取り込んでもらうようなことがよくありました。

リリース・プロセスのバリエーション

頻繁なリリースはウェブでのサービスなど、自分たちのコントロールが効くもので行われています。モバイルのアプリやデスクトップのアプリケーションなど、一旦リリースしてしまったあとのアップデートはユーザー主導でやってもらわなければならないものについてはリリースでのミスの修正のコストが高いため、リリース頻度はやや低めになっています。とはいえ、やはりユーザのフィードバックをなるべく早く得たいことは変わりませんし、大きなリリースのリスクはやはり大きいため、ウェブのリリースと同様、モバイルのリリースも数ヶ月から1ヶ月、2-3週間おきへと短縮されてきています。

小さな企業や、こまわりの効く開発チームなどではリリースの頻度を極限まで上げ、開発リポジトリ上でのテストがすべてパスしたタイミングで随時リリースを行う手法もあります。リリースのことをプロダクションサイトにpushするといい、テストがパスするとテストのダッシュボードに緑色のインジケーターが表示されるので、push on greenなどと呼びます。

関連項目