Done（完了）の定義とリリースブランチ

Doneだ。終わったよという宣言をするのは心地よい。しかしながらこの「完了」という言葉ほどソフトウェア開発現場では曖昧に使われているものはない。

わたしも新人の頃、いいかげんに使っていた。

よ「〜の機能の実装完了です」先輩「ビルドした？」よ「コーディングしただけです」先輩「ばかやろ、それは実装完了とは言わねーよ」よ「すいません」、（あれやこれや作業）…、よ「ビルドしました。コンパイルエラー、ビルドエラーとかないっすよ」先輩「で、テストした？」よ「てへ」先輩「お前あほか」、（あれやこれや作業）…、よ「テストしましたーー。ばっちりっす」先輩「あれ、こっちでは確認できないなー。ソースコードをチェックインしたの？」よ「あ、自分のローカルな環境でしか試してません」先輩「おい首締めるぞ。チェックインしてから言えよ」、（あれやこれや作業）…、よ「チェックインもしました」先輩「やっとか。どれどれ。あれー、〜の機能が動かないなあ。〜はどう実装したの？」よ「あ、〜の実装はまだでした」（振り出しに戻る）

上記会話は実話に基づく創作です。

結局、コーディングして、ビルドして、リグレッションテストにかけて、出荷できる品質まで持っていって、それで完了ということになる。ソフトウェア製品の場合は、プログラマが自分の作業が完了というのは、自分の担当のところが出荷できる品質になったことをさす。毎日毎日全ビルドしているので常に動くものがある。その動くものの品質は時には不安定になることもあれば安定してバグ（不具合）が少ないこともあるが、常に毎日動くものが存在する。

自分の担当の部分のテストはすべて問題がないということを毎日確認する。時には誰かの変更の影響で自分の担当のテストが壊れることもあるが、そーゆー場合は朝会社に来て、その壊れた原因を分析するのがトッププライオリティになる。そして、壊れた原因が自分の問題であれば、それを修復するし、変更した誰かの責任であれば、その人に修正を依頼する。常に動くものを維持しておく。それがディリービルドを利用した開発のリズムである。

ビルドを壊さないで開発をすると、毎日少しずつ機能が追加されていく。毎日、品質にばらつきがあるとしても動くものが存在する。実装が完了した機能リストをみながらリリースマネージャーが、いつのタイミングで出荷するか決定する。ある時点で、ほぼ実装すべき機能がそろったとしたら、そこから安定化プロセスにはいる。それは、機能フリーズと言って、新規機能は一切追加しない出荷用ブランチを作って、ひたすらバグだけを直していくフェーズになる。例えば現状で1000個の不具合がバグデーターベースに登録されていたとしたら、そのバグに優先順位をつけて、新機能の開発をとめてバグだけを直していく。修正が簡単なバグも難しいバグもあるが、ひたすら直していく。そうするとみるみるうちにバグが収束していって、出荷規準を満たすまで続く。

データーベース製品の場合、メジャーバージョンアップが２−３年毎くらいの周期なので、出荷されるまで、毎日のビルドが数百とか1000を超えることがある。その特定のビルドを選んで、そこから安定化プロセス（リリース版の開発）が始まり、出荷されることになる。リリース版はサポートが終了するまで維持管理される。通常、出荷されてサポートされるバージョンは複数あるので、リリースのブランチは複数存在することになる。

Streamed Lines: Branching Patterns for Parallel Software Development

ウェブ開発だと、複数のリリースを同時並行的に長期間維持するということはまれなので、Github flowのようなシンプルなバージョン管理、リリース管理になる。

ソフトウェア開発と言っても対象となる製品やサービスによってリリース管理の方法はまちまちである。