継続的開発は書いたコードはすぐにリリースするという考えとしてアジャイルやリーンの技術として語られることが多い。この方法には明確な利点がたくさんある。例えば、開発サイクルを短くすることで素早くバグ修正や新機能の市場投入ができる点だ。しかし、これは言うほど簡単だろうか。
Jim Bird氏は継続的統合について語っているときに話題になっている変更はわずかな調整や表面的でとるに足らない変更、小さなバグ修正など些細なものに過ぎないと指摘する。これ以上大きい要求はもっと詳細で慎重な手法が必要だ。
氏によれば、
スキーマの変更は継続的に行えません。大きな機能変更は継続的にできませんしすべきでもありません。例えばEtsy(継続的統合を看板にしている会社のひとつ)は公衆の面前にさらされる大きな機能は継続的にリリースしません。良識のある組織のように、時間をかけて設計し、プロトタイプを作って、テストし、レビューして運用や顧客サポート、製品管理とともにしっかりと計画を立てます。
Jo Liss氏は継続的開発の真の課題は変更を元通りに戻すのにコストがかかる点だと言う。氏によれば、継続的統合の場合は統合作業の頻度の上限はほとんど技術的に決まるが、継続的開発の場合はそうはならない。元に戻すに巨大なコストがかかるからだ。
一度、リリースしてしまうとユーザが利用し価値あるデータが生まれます。そうなると元に戻すのは難しいです。なぜなら、
- データベースのスキーマを元に戻さなければならない。
- 今この瞬間にアプリケーションを利用しているユーザにどんな影響があるか考慮しながらアプリケーションを変更しなければならない(リンクが壊れたり、Ajaxリクエストが失敗するかもしれない)。
- (元に戻したいという単純な理由ではなく)バグが原因で戻さなければならないとき、このバグに影響を受けたユーザにメールして説明し、サポートしなければならないかもしれない。
同じようにEric Ries氏は継続的開発の最大の課題のひとつは常にリリース準備をしなければならないことだ、と言う。
一方ではこれは究極の顧客対応とも言えますが、地獄のように恐ろしいことでもあります。段階的にリリースする場合、時間が(少し錯覚めいていますが)安全網になってくれます。テストの責任を他のだれか(品質保証チーム)と共有できるのも心強いです。
では継続的開発の価値を具現化するにはどうすればいいか。
氏は下記のアドバイスをしている。
- 機能を押し込まない。顧客からの信号に反応する。
- 少量のコードを書く。
- 可能な限り単体テストより機能テストを優先する。
- システムとアプリケーション双方のアラートと監視を実装する。
- 一回だけ予期しないエラーを寛大に扱い、すぐに修正する。
Jo Liss氏はより少ないコミットをするべきだと考える。氏は2日で5時間の開発の遅れくらいが妥当だと考えている。
積極的に開発してすぐにリリースしようとする誘惑に負けずに我慢できれば、本当はリリースしたくない重大な変更を避けられるかもしれません。それも、根拠の薄い初期段階のユーザフィードバックも受ける必要がなくなるだけで済みます。
継続的開発が不可能だと言っているわけではない。Etsy、Heyo、IMVU、Atlassianのような組織は実際に継続的開発を行っている。おそらく上手くいっているはずだ。
Jim Bird氏は次のようにまとめる。
継続的開発から学べることはたくさんあります。リリースや開発を簡素にすることや小さなタスクに分割することでリスクを減らすこと。監視と測定でまとめて運用すること。でも継続的開発は“開発運用の聖杯”ではありませんし、そうなるべきでもありません。