未来のいつか/hyoshiokの日記 このページをアンテナに追加 RSSフィード Twitter

2014-07-12

Done(完了)の定義とリリースブランチ

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

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

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

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

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

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

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

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

f:id:hyoshiok:20140713121353g:image

Streamed Lines: Branching Patterns for Parallel Software Development

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

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

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/hyoshiok/20140712/p1
おとなり日記