git-flow による構成管理とRedmineの関係

「git-flow によるブランチ管理」という記事で、分散バージョン管理ツールを使った構成管理手法をとても分かりやすく書かれていた。
以前僕が書いた記事を見直して、理解が足りなかった部分があったと感じたので、もう一度まとめてみた。

A successful git branching model

View more presentations from akipii Oga

【元ネタ】
git-flow によるブランチの管理 - O'Reilly Japan Community Blog

A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind

見えないチカラ: A successful Git branching model を翻訳しました

A successful Git branching model: プログラマの思索

Mercurialで独立並行リリース管理: プログラマの思索

Mercurialによるチケット駆動開発は強力だ！: プログラマの思索

チケット単位に並行開発する事例: プログラマの思索

Subversionのブランチを有効活用してアジャイルに開発せよ: プログラマの思索

【0】git-flow によるブランチの管理 - O'Reilly Japan Community Blogによれば、目的別にブランチを作って開発＆リリースしていく。

(引用開始)
git-flow では、中央と みなす リポジトリ origin を作成することで、この長所を取り入れています。
origin には master, develop という 2 つの メインブランチ を保持します。

(1)master: リリースブランチ。プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。集中型でいう trunk、tag。
(2)develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。

各開発者は master, develop の他に、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチという サポートブランチ を利用し分散開発します。このブランチは最終的には破棄されます。各ブランチの目的は

(3)フィーチャーブランチ: 機能の追加。 develop から分岐し、 develop にマージする。
(4)リリースブランチ: プロダクトリリースの準備。機能の追加やマイナーなバグフィックスとは独立させることで、リリース時に含めるコードを綺麗な状態に保つ（機能追加中で未使用のコードなどを含まないようにする）ことができる。 develop ブランチにリリース予定の機能やバグフィックスがほぼ反映した状態で develop から分岐する。リリース準備が整ったら, master にマージし、タグをつける。次に develop にマージする。
(5)ホットフィックスブランチ: リリース後のクリティカルなバグフィックスなど、現在のプロダクトのバージョンに対する変更用。 master から分岐し、 master にマージし、タグをつける。次に develop にマージする。

となります。このサポートブランチにより、マージ、コミットすべきブランチを明確化することができます。
(引用終了)

【1】構成管理パターンについて唯一解説している本「パターンによるソフトウェア構成管理」で上記の概念を翻訳してみる。
「Redmineによるタスクマネジメント実践技法」の構成管理パターンとほぼ同等だ。

(1)master

「パターンによるソフトウェア構成管理」では「リリースブランチ」に相当する。
つまり、本番環境で動くソースそのものであり、開発チームが裏でガンガン開発中のソースとは異なる。
普通の運用保守では、ステージング環境(UAT：受入環境)が本番環境と同等な環境として作られており、本番障害が発生した場合、その環境でバグを再現させたりする。

git-flowで特徴的なのは、リリースブランチのライフサイクルはtrunk(develope)と同じ寿命であること。
リリース時は必ず、ユーザが運用しているブランチへパッチをマージさせてタグを打ってリリースする運用になる。
この運用の利点は、品質が安定したソース(master)が存在しているので、新規開発やリファクタリングを実施するtrunkと別運用できることだろう。
アジャイル開発では、新規機能の実装やリファクタリングが頻繁に行われるため、品質重視のブランチとまだ品質が安定していないブランチを分けて開発する方がリリース作業も楽になる。

僕がSubversionでメインラインモデルを運用していた時、リリース時はtrunkから必ずリリースブランチを作り、そのリリースブランチの寿命は次Verまでと限定していたが、git-flowの運用の方が安全だろうと思う。
masterの運用が可能なのも、Gitのマージ機能がとても強力だからという理由もある。
SVNは今もマージ作業はGitほど楽でないから。

(2)develope

「パターンによるソフトウェア構成管理」では「trunk」に相当する。
つまり、最新の機能が反映されていて、ほぼ常時リリース可能なブランチになる。
開発者はdevelopeを本流と見なして、どんどんコミットしていく。あるいは、developeから自分だけの開発ソースを派生させたりする。
更に、trunkは継続的インテグレーションで常に常時リリース可能なブランチにして、品質を維持しているのが重要だろう。

(3)feature

「パターンによるソフトウェア構成管理」では「タスクブランチ」に相当する。
よくある例は、顧客から突然大きな仕様追加が要請されて、新規開発中のソースと並行でその仕様追加を開発しなくてはならない状況でfeature(タスクブランチ)を使う。
つまり、trunkでは従来通りの新規開発、feature(タスクブランチ)上で仕様追加の開発とブランチを分けて並行開発していく開発スタイル。
feature(タスクブランチ)を使う状況は「Redmineによるタスクマネジメント実践技法」で詳しく書いた。

変更要求に対する選択肢: プログラマの思索

新規機能の開発は全てfeature(タスクブランチ)上で行えば、他の開発に影響を与えず、複数の開発者が並列に開発できる。
SVNでもfeature(タスクブランチ)を使う状況はあるけれどその難易度は高かった。
でも、GitやMercurialでは複数ブランチで並行開発して、最後に本流(trunk)にマージする一連の作業はとても自然だ。
この運用が可能なのも、GitやMercurialではブランチ管理やマージ機能が強力だからだ。

(4)release

「パターンによるソフトウェア構成管理」では「リリース準備ブランチ」に相当する。
よくある例は、ソフトウェアの開発がほぼ完了したものの、残作業としてインストーラー作成やデプロイのための作業が残っていたりする時、trunkからリリース準備ブランチを切り、リリース準備ブランチ上で残作業を仕上げてリリースしていく。
あるいは、エラーメッセージの修正や画面のデザイン修正など、あとは細かな修正で品質を上げていく作業が残っていた場合、trunkからリリース準備ブランチを切り、リリース準備ブランチ上で後追いテストを実施して、できるだけ品質を上げていく戦略を取る。

リリース準備ブランチの利点は、残作業と新規開発を分けて並行開発できることと、リリースされたらリリース準備ブランチがそのままリリースブランチになるので、新規開発と運用保守の並行開発へすぐに切り替えられること。
git-flowでは、リリース準備ブランチでリリース準備が完了したらリリースブランチ(master)へマージされて廃止される運用になる。

Redmineの開発でも、メジャーVersionのリリース前にtrunkからリリース準備ブランチが切られて、残作業はリリース準備ブランチへ反映させたり、その後のマイナーバージョンアップはリリースブランチ上で行われている。
その理由は、Redmineの開発はSVNで行われている点があるからだろう。

(5)hot fix

「入門Git」では「トピックブランチ」に相当する。
よくある例は、本番障害が発生したので、緊急で障害修正を実施して本番リリースしなくてはならない状況で使う。
git-flowでは、master(リリースブランチ)から派生させたトピックブランチ上で修正し、修正が完了したら、リリースブランチとtrunkへマージする。
注意すべき点は、トピックブランチ→リリースブランチ・turnkへマージするのであり、トピックブランチ→trunk→リリースブランチのようなマージ順序ではないこと。
トピックブランチで作ったパッチ、つまりソースの差分情報が重要なのであり、そのパッチでマージするようにする。
このパッチを育てるためにわざわざトピックブランチ上で作業したのだから。

【2】チケット駆動開発の観点では、トピックブランチはチケット単位で作られることになるだろう。
本番障害は1個のバグチケットで起票されるから、1チケットでその後の修正は管理されていくからだ。
つまり、プロジェクト単位ではなく、チケット単位でブランチが作られることになるだろう。

また、チケット駆動開発の観点では、masterは保守プロジェクト、developeは開発プロジェクトでRedmineプロジェクトを分けた方がタスク管理が楽だろうと思う。
本番運用のソースに関するタスク管理と新規開発のタスク管理はそもそもタスクの観点が全く異なるからだ。
また、実際のチーム運営でも、システム規模が大きいほど、運用保守チームと新規開発チームで分けられている時も多いから、Redmineプロジェクトを別々にして各チームのタスク管理と一致させるようにした方が運用は楽だろう。

構成管理手法とRedmineの運用に密接な関係がある理由は、ブランチ上で履歴管理されているソースや成果物の変更は全てRedmineチケットに起票されて、その後の変更管理は全てRedmineで管理されるからだ。
つまり、SVNやGitリポジトリの管理下にある全ての成果物(ソースも設計書もビルドスクリプトもその他全部)の変更管理は、チケットのタスク管理という仕組みを通じて、Redmineが代用していることになる。

Redmineによるチケット駆動開発を実践してみると、構成管理手法とRedmineの運用に密接な関係があることを経験できたし、その関連性を深く考えていくのが面白い。