メインラインの定義

構成管理パターンの一つであるメインラインモデルを再考してみた。

【元ネタ】
構成管理　実践入門　第3章 Subversionベストプラクティス　コードライン編その１ メインライン

(引用開始)
■メインラインを1つに保ちましょう
Subversionでは、trunkをメインラインとして使用することを推奨しています。 開発はメインラインに対して行うことを心がけてください。ほかのブランチへメインラインの置き換えを行った場合も、そのブランチにメインラインの原則を適応して、メインラインが複雑化しないようにしましょう。

■メインラインは正しくビルドできる状態に保ちましょう
すべての開発者は、通常メインラインに対して作業を進めていきます。コミット時に事前テストを行ったり、インテグレーションビルドを行うなど、メインラインから取得する作業環境は常に正しくビルドが行えるように保ち続けましょう。

■メインラインからブランチを作成しよう
ブランチは極力作成を行わないほうが好ましいですが、作成を行いたい場合、ブランチからブランチを作成するようなことは避け、メインラインからブランチを作成するように心がけることで、複雑化を抑えることができます。

■ブランチの変更は素早く元のメインラインに反映させましょう
ブランチに対する変更作業にかかる期間が長ければ長いほど、マージを行うことが困難になります。ブ ランチを作成して分岐を行った場合、その変更内容を素早くメインラインに戻すことを心がけましょう。
(引用終了)

メインラインは、ブランチの派生元であり、更新されたブランチが終了する時にマージする先のコードラインになる。
つまり、ブランチに寿命がある場合、ブランチは基本は派生元のメインラインにマージされて消える運用になるのがメインラインモデル。

メインラインは普通はtrunkやmasterだが、ブランチがずっと生き続ける場合、そのブランチがメインラインになる場合もある。
つまり、メインラインの本来の定義では唯一つではない。
そのような例としては、複数の似たような製品を開発せざるを得ない製品ファミリー開発(SPL)が多いだろう。

但し、「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」本では、僕は故意にメインラインの定義を「最新機能を持つ常時リリース可能なコードライン(ブランチ)」へ変更している。
メインラインの本来の定義では、上記の定義のように、そもそもいつも常時リリース可能になる性質はない。
だが、XPのプラクティスであるテスト駆動開発や継続的インテグレーションを実施していれば、メインラインは自然に常時リリース可能なコードラインになっている。

そもそも、現代のソース管理において、メインラインの役割に相当するブランチには、コンパイルエラーが通っていないソースをコミットすることはありえないだろう。
何故ならば、コンパイルできないソースをコミットしたら、メインラインの品質が落ちてしまうだけでなく、メインラインからプライベートなブランチ(トピックブランチ)上で作業する開発者に悪影響を及ぼすからだ。

同様に、現代のソース管理において、メインラインの役割に相当するブランチには、単体テストが通っていないソースをコミットすることはありえない。
現代のソフトウェア開発ではテスト駆動開発は当たり前であり、そもそもTDDをやっていないプロジェクトでは、実際に結合テスト工程のようにかなり時間が経った後に初めて動作確認してバグを発見してしまうから、既に破綻していると言ってもいいだろう。

同様に、現代のソース管理において、継続的インテグレーションを実施しないことはありえないだろう。
そもそもメインラインでビルドが通らない状況のまま放置していれば、そもそも動かないソースを他の開発者に提供してしまうため、悪影響を及ぼすからだ。

つまり、メインラインは単に、すべてのブランチの派生元であり、派生したブランチがマージされるブランチだけでない。
メインラインは、最新機能を持つ常時リリース可能なコードラインでなければ、安定してアジャイルに開発できないからだ。

何故、メインラインが必要なのか？
開発者にとって、どのソースが最新で、どれを修正すればよいか、メインラインがなければすぐに混乱してしまうから。
リリースのたびにブランチを作り、作ったブランチから更にブランチを作る「昇格モデル」は、開発者にとってとても開発しづらい。
開発環境を整えるのはそんなに簡単ではないのに、昇格モデルの場合は開発環境がどんどん移り変わっていくのでとても大変だから。

そして、メインラインから派生して更新されたブランチがマージされる時、GitやMercurialではいろんなマージの種類がある。
merge, push, pullコマンドが一番単純だろうが、rebaseのようにブランチ上で更新されたコミット履歴をメインラインに反映したり、hgのtransplantやGitのgit-cherry-pickのように、ある特定のリビジョンのパッチだけを取り込む方法もある。

git-cherry-pickを掘り下げる - idesaku blog

Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 - TIM Labs

Gitで特定のコミットを指定する108の方法 - TIM Labs

特定目的のバグ修正や機能追加を行うトピックブランチは、多種多様なマージコマンドを必要とする。
その理由は、メインラインと同期したり、必要な最新機能だけ取り込む機会が多いため、特定のパッチだけを取り込む手法が必要だからだろう。

Redmineによるチケット駆動開発とメインラインモデルはとても相性が良い。
更に、変更理由をチケットに書いておき、リビジョンと紐づけておけば、トレーサビリティも実現できる。

チケット管理とバージョン管理の連携機能は、構成管理パターンを更に実現しやすくしてくれる可能性がある。
色々調べてみる。