ここ数日Team Foundation Server(TFS)でのバージョン管理についてモヤモヤしていたけど、いくつかの資料を見ているうちに少しモヤモヤが晴れたので過程を残しておきます。
ちなみに、今使ってるのがTFSというだけで、バージョン管理の一般的な悩み事です。
モヤモヤ
前提として、TFSのバージョン管理はSubversion(SVN)と同じく中央リポジトリ型です。
ということで、SVNと同じ構成にしてたんですね*1。
普通に開発してる分には問題なかったんですが、複数のバージョンが並行して走る場合に、どういう構成にしたらいいかなーという疑問が。今までそういうのやったことなかったので。
何人かの方に相談してみたところ、単純にバージョン管理の問題にとどまらず、リリースの考え方や、ソフトウェアの構成にも依存するので、一概には言えないような感じです。
しかしながら、とりあえずリポジトリ構成自体は、ここの説明で少しモヤモヤが晴れた感じです。
バージョン管理の説明って機能の説明があっても、リポジトリ構成の説明をあまり見ないんですよね。コンテキスト依存なのかもしれませんが、上記含めていくつかリファレンス的なものがあるので、もう少し表に出てもいいんじゃないかなぁと思ったりします。
基本的な構成
「Main」と「Develop」のラインでよさそう。
「Main」が「trunk」相当、「Depvelop」が「branches」相当、「ラベル」が「tags」相当になりますね。
- 「Main」は常にクリーンな状態が保たれ、いつでもリリース可能な状態にします
- 「Develop」は開発用となり、新機能の追加はこの分岐で行います
- リリースすると、「Main」に「ラベル」を振り、その時点のスナップショットをとります
自動ビルドの付加
Mainを常にクリーンな状態に保つため、またDevelopの不具合を早期に検出するために、自動ビルドを付加すると精神衛生上よろしいかと思います。MainとDevelopそれぞれに自動ビルドの設定を行いますが、それぞれ役割が違うため、ビルドのトリガを考える必要があります。
Main
Mainは常にクリーンであるために、ビルドとテストが通る状態でのみチェックインできるようにしたいので、ビルドのトリガを「ゲートチェックイン」にします。「ゲートチェックイン」はチェックインすると、いったん「シェルブ」と呼ばれる棚上げの状態にしてビルドを行います。その結果、正常にビルドが終了すれば、実際にチェックインされます。もし、ビルドのどこかでエラーが発生した場合は、チェックインされません。
このような防御線を張ることで、Mainを常にクリーンに保つことができます。合わせてデイリービルドのように、毎日ビルドを行って壊れていないことを確認できると、より確実になりそうですね。
Develop
Developにはどんどん新しい機能が追加されるので、チェックインされたコードが壊れたことをすぐに確認できるように「継続的インテグレーション(チェックインをトリガとした自動ビルド)」にします。
とありまずが、ビルドがある程度の速度で行われるのであれば、こちらも「ゲートチェックイン」でいいかもしれませんね。
複数バージョンをメンテナンスするときの構成
で、肝心の複数バージョン(たとえば、V1、V2のような)をメンテナンスするときは、基本的な構成をベースに、Mainから分岐したReleaseバージョンをメンテすればよいでしょうか。
#一番良い方法は、MainにV2があり、その機能限定版としてV1がある。という状態になるかと思います。
これらを踏まえて、リポジトリのツリーを構成すると、このようになるのかなぁと思います。
TFSの履歴で、上のようなツリーが見えるといいですねぇ(知らないだけ？)
