Team Foundation Server で構成管理を運用してみた

id:kaorun55 さんがバージョン管理事例についてMSDNを参考にしつつまとめたエントリ（より実践的な、Team Foundation Serverのバージョン管理 - かおるんTFSダイアリー）を上げていたのに影響されて私も事例を。構成管理をどうやっているかはあまり公開されていないので色々な方が事例を上げてくれると幸せだなぁ。

コーディング、単体テスト、結合テスト、総合テスト、リリースという流れ。各テストをクリアしないと

テストコードを書いてCIを回したかったのですが、テストを書ける技術者も自動化する範囲を決定する事ができませんでした。

プログラマーが20名。TFSユーザではないメンバーが10人という規模。

二週間単位など定期的にリリースするのではなく、顧客と調整の上で日程を決めていました。

イメージはこのとおり。
f:id:kaji_3:20120411190239p:plain

リリースまで幾つかのテストを実施する必要がありました。またver.2の総合テスト実施中に、ver.3の結合テストを、ver.4の開発を並行して行う必要があったことから以下の5つの分岐で運用しました。

プログラマがいつでもチェックインできる分岐。帰宅前、コーディング完了時にチェックインするルールにしました。

単体テストが完了したら、申請を構成管理担当者に依頼しDevelopから対象リソースをマージする分岐。結合テスト環境にデプロイされます。

結合テストが完了したらこの分岐にマージ。リリース候補版として総合テスト環境にデプロイされます。

リリース日が確定した場合、IntegrationTestedからマージします。

リリース直後に分岐をさせておきます。緊急対応はこの分岐に変更を入れます。次のリリース時には削除をしてReleaseから再度分岐します。

　TFSを１台のサーバで運用。ビルドコントローラーも同一サーバ。そのため、大量のチェックイン時は自動ビルドのキューが消化できない状況がありました。サーバスペックの増強で回避しました。

　各分岐にマージするために申請が発生し、かつ、ソース単位で管理していたため管理者が高負荷となってしまいました。

多忙でも手を休めて導入しておきたかったものがいくつかあります。

時々他の人のソースを削除してチェックインする方がいました。対応コストが半端ないため、ゲートチェックインを導入するべきでした。

本当にただ時間を作らなかっただけ。。

ビルドが失敗したらプロジェクト全体にメールを送信する予定でしたがPMにNGを出されてしまいました。押し切っておけば開発者の自発的なビルド失敗回避を促せたと思います。

誰もTFSを運用した事がない状態で始めたため製品ノウハウが足りず。導入を検討してTFSUGに参加される事をオススメします。

id:kaorun55 さんのエントリの分岐数じゃないと管理負荷が高く本質である開発に集中できないと思っています。
そもそも開発に集中するためにTFSを入れたのに本末転倒な事になります。
その分岐は本当に必要か十分に検討して運用をしてください。

TFSで困った時、Twitterでフォローしていただいた@tomohnさんありがとうございました。
また、この大変な構成管理に最後まで付き合ってくれたTさん本当にありがとうございましたm(__)m