matsukawar’s blog

とりあえず、ダイアリーからお引越し中です。

分岐とマージで必要だと思ったこと

ALM Advent Calendar 2012の9日目の記事を書きます。

今日は、分岐とマージについて書きたいと思います。
TFSの構成管理では、ソースコードなどのファイルのバージョン管理を行うことができます。つまり、TFSを使うことでソースコードはTFS上で、日々、分岐とマージを繰り返して進化していくわけですね!プロダクトのリリースが増えるということは、分岐とマージの作業も(もちろんテストも)増えるということですので、しっかり管理したいところです^^

通常、Visual Studioを使用している場合、分岐とマージは、ソース管理エクスプローラ上で操作することになります。

(VS2012のソース管理エクスプローラ)

ソースコードはただ、入れるだけではなく、バージョンの管理(バージョン管理)する必要があります。
TFSでは、各バージョンのデータの差分をSQL Serverで管理してバージョン管理する仕組みになっています。

(TIPS.1)分岐戦略をチームで決める
プロダクトのリリース戦略や、ビジネスのニーズ、チームの状況から、分岐戦略を作ります。
管理形式はどのようにするか?分岐は何時誰がどうするか?等を決めます。

(ソース管理エクスプローラ上での管理)

MAIN:メインブランチ(SubVersion風に言えばTRUNK)
DEVELOP:開発ブランチ
HOTFIX:HOTFIXブランチ
RELEASE:リリースブランチ

(これらが分岐でつながっている)

と、こんな感じです。
より複雑な管理の場合(例えば、開発拠点が何カ所もあって、メインブランチのほかに、拠点ごとの開発バージョンがある等)は、しっかり考える必要がありそうです。

Visual Studio ALM Rangersに公式のブランチング&マージガイドの資料があるので、参考になります!

分岐戦略で決めたら、チームプロジェクトの設定をたいてい??見直します。

(TIPS.2)分岐とマージのセキュリティ設定を設定する
チームプロジェクトのセキュリティ設定のうち、分岐とマージについてセキュリティの設定を見直して、分岐とマージができる人を制限します。これは、分岐戦略に基づかない分岐を阻止する必要があるためです!

(チームプロジェクトのセキュリティ設定で設定できる)

※分岐、マージの他に、チェックアウトなども細かく設定できるので、これらセキュリティの設定をグループメンバシップの設定と一緒にしっかりとやっておくことが後々の管理で楽するのではないかと思います。

分岐とマージがしやすい環境を作る、というのも忘れないようにします。
簡単ですが、いくつか取り組みを紹介します。

(TIPS.3)マージしやすいプロジェクト構成にする
よくあるのは、ソースコードに混じって、EXCELファイルなどのバイナリファイルがある場合です。バイナリファイルは自動マージできないためこのようなファイルが入っていると、マージ作業がとても煩雑になります。凡ミスが発生し、バグになることもありますので、極力このようなファイルが無くなるように改善する必要があります!

EXCELCSVファイル, XMLファイルへ置き換える
WORD → TXTファイルへ置き換える
その他 → レポジトリから除外(※極論ではありますが)

(TIPS.4)マージはマージ用のワークスペースで行う
ワークスペースを切り替えることで、通常の開発作業とマージの作業を別作業として分離します。特にマルチタスクで、いろんな機能の開発を同時並行で行っている時などはワークスペースを分けることで、異なる作業内容が混在しないようにします。

(ワークスペースを必要なだけ用意しておく)

(ローカルの作業フォルダも決めておく)

ワークスペースの使い分けはとても便利ですが、間違えて意図しないワークスペース上でソースコードを修正しないように気をつけてくださいね!;)

ソース管理エクスプローラ上でマージ作業を行うと、競合が発生していないファイルについては、Visual Studioで自動的にマージ(したことに)してくれます。
運悪く、マージが必要となるファイルがある場合は、その一覧を競合の解決に一覧表示して教えてくれます。
この画面は、Visual Studio 2005, 2008, 2010, 2012いずれのバージョンでも用語がわかりにくいのでとても注意が必要です。

(TIPS.5)競合の解決画面の用語/操作に注意する
この画面には、マージが必要な項目の一覧を出してくれ、さらに、次のアクション(手動マージ、破棄、上書き)の操作ボタンまであります。
よく考えずに、間違ったボタンを押すと、悲惨なことになるので、注意が必要なところといっていいでしょう。

(A.チェックイン時に競合の解決が発生した場合)

自動マージ:自動マージは試行されたうえで、競合の解決がでてるので押せません(半輝度)。
マージツールで変更をマージするVisual Studio標準のマージツール(※カスタマイズ可能)で変更点を手動でマージします。
サーババージョンを取得する:ローカルの修正済みファイルを破棄して、チェックインをしない
ローカルバージョンを保持する:サーバのファイルをローカルの修正済みファイルで上書く

(B.マージ時に競合の解決が発生した場合)

【マージ操作】
自動マージ:自動マージは試行されたうえで、競合の解決がでてるので押せません(半輝度)。
マージツールで変更をマージするVisual Studio標準のマージツール(※カスタマイズ可能)で変更点を手動でマージします。
ターゲット分岐バージョンを保持するマージ先のファイルをそのままにして、マージ元のファイルバージョンを破棄
ソース分岐バージョンを保持するマージ元のファイルでマージ先のファイルを上書く
※MAINブランチ(SubVersion風に言えばTRUNK)がターゲットというわけではなく、ソースとターゲットは、マージの方向に依存します。マージ元がソース、マージ先がターゲットになります。

【コード比較】
ターゲットをソースと比較:マージ先(ターゲット)とマージ元(ソース)を比較する
ソースを基本バージョンと比較:マージ元(ソース)と分岐元のファイル(基本バージョン)を比較する
ターゲットを基本バージョンと比較:マージ先(ターゲット)と分岐元のファイル(基本バージョン)を比較する

私のチームでは、TFS導入当初、上記のマージ操作を誤って修正が消えてしまったというトラブルが発生しました。
これは、このような言葉の問題なのですが、混乱の原因になるのであらかじめチーム全員で意識合わせする必要がありそうです。

ここまで、競合の解決でマージができたのでチェックイン・・・とはいかないのがマージの難しいところです(泣)
マージは、そのマージが正しいこととを確認しなければ終わりません!

マージを正しく行うためには、仕様の把握が第一です。
逆に言えば、仕様を知らない人にマージをやらせると悲惨なことになります。当然ですが!(笑)

(TIPS.6)あらかじめマージ先の変更点について仕様を理解する
マージ元、マージ先で何が機能的に変わったか?特に、大きな変更点については把握しておく必要があります。自分が知らないところで、もしかしたら、大きな修正があるかもしれません。それがもし、マージに影響するような(つまり、機能仕様を見直す必要があるような)修正だったとしたら、プログラムの修正が必要になります!

これは、できれば、マージ前までには把握していたいですね。

マージが正しいことを保証するためにはテストするしかありません。
テストは自動化することでコストを下げれます。

(TIPS.7)テストコードを書く習慣をつける
ユニットテストWEBテスト、コード化されたUIテストなど、テストを自動化するような工夫を日ごろから作るよう習慣をつけておくと、マージ後に意図した動作になっていない場合、検出が容易になります。

テストの自動化は、頻繁に発生する分岐とマージにはとても有効だと思います。
一番嫌なのは、他の人がマージしたことで、自分が作った機能を破壊されることです。
でも、テストが有れば、安心感が違いますね!

自動化されたテストが完了したら、残りの手動によるテストを行います。
テストが完了すれば、マージは完了となります!!!

まとめ

マージのコストを減らすためには、状況に合わせていろいろな工夫をする必要があります。
機能設計のフェーズである程度マージしやすい設計にすることもできると思いますし、
プログラムの詳細設計のフェーズでアプローチすることもできるでしょうし、さまざまです。

ビジネス駆動のソフトウェア開発では、変更の要求が頻繁に起こり、分岐とマージを繰り返すことが想定されます。仕様の設計や、プログラミング技法の合い間、合い間でこの「マージのしやすさ」を考慮することで、この問題は乗り越えれるのではないでしょうか?

いい取り組みやアイデアはぜひ、TFSUGでご紹介ください^^