Team Foundation Serverの運用事例と雑感

ある案件でTeam Foundation Server（TFS）を使った時の雑感をまとめてみました。昨日のワンクリックデプロイ勉強会にインスパイヤされて書きました。参考になりましたら幸いです。アンチパターンも含まれていますので反面教師にして頂ければと思います。ああ恥ずかしい。

プロジェクトの性質

6ヶ月で要件定義から試験までやってリリース。開発チームは最大8名で年度末に解散。
R&D的な取り組みなので要件はほとんど見えておらず、最初の1ヶ月でプロトタイプを提供して本当にやりたいことを検討した。（これ以上は割愛）
アジャイルではない。一括請負契約のウォーターフォール。
顧客にはリッチクライアントアプリを提供した。

開発環境

サーバ
- Windows Server 2008 R2
- Visual Studio Team Foundation Server 2010
  - 短時間でCI環境を構築できるメリットは大きい。Windows Serverを使える人ならTFSを管理できる。
- SQL Server 2008 R2
- その辺に転がっているPCを使うのは望ましくない。継続的な運用を考えると、速くて安心できるマシンが必要。当然ながらデータバックアップや代替機の用意も必要。
開発PC
- Visual Studio 2010
- SQL Server 2008 R2

SCM

TFSのソースコードリポジトリを採用
- 当初は別案件との兼ね合いでSubversionを使っていたが、途中でTFSに移行した。
- チェックイン、チェックアウトの操作に慣れればSubversionとあまり違わないと思う。特に説明資料は作らなかった。
- 分岐とマージについては説明資料を作った。
  - 将来のバージョンで、Git+SVNのように分散バージョン管理の美味しいところを取り入れてくれたら嬉しい。
決めごと（暗黙も含む）
- 基本的にはタスクごとにチェックインすること。
- チェックインは必要に応じてタスクやバグと関連付けること。
  - TFSはチェックイン時に関連付けるバグを選択できるので便利。バグIDを手入力したりする必要はない。
- 最低でも1日1回チェックインすること。
  - 最初から全部作ろうとして抱え込んでしまう*1人がいたので、少しずつ書いてチェックインしてもらうようにした。
  - 手に負えなくなったコードはシェルブして質問に来てもらうようにした。
シェルブ
- いろいろ使い道があると思う。
- 私は git stash みたいに使ってた。
- Gitのローカルブランチみたいに、ちょっと大きな変更を途中で保管しておくのにも使ってた。
- 他人がシェルブしたコードも見られるので、質問や議論のネタを入れておくのにも使ってた。席が遠いと困るよね*2。
チェックインポリシー
- ビルドの通らないコードはチェックインできない。
- ユニットテストの通らないコードもチェックインできないようにしていたが、諸々の問題で運用が回らなくなったので制約から外した。
  - 負けだと思うけど現実を見たほうがいい。けど言い訳はしない。
- ゲートチェックインも使ってみたが諸々の問題で運用できず。

デプロイメント

リリース
- ワンクリックCD-Rリリース。世の中にはインターネットにつながらない世界が存在する。
- ビルドサーバの共有フォルダにバイナリを出力するようにして、リリース時は共有フォルダを丸ごと焼いて顧客拠点に持っていく運用にした。
- 顧客端末へのリリースは人力でやるしかなくて、煩雑な手順が問題になった。
- デプロイしたバージョンにはラベルを付ける。
ブランチラインの運用
- TFSの「分岐」という用語は分かりにくいと思う。
- これは6ヶ月のプロジェクトが終わってからの話だけど、前年度の保守と次年度の開発が並行して走ることになったのでブランチを分けた。
- どのブランチで作業しているかを分かりやすくするため、コードツリーの上位（正確にはソリューションのフォルダ）にブランチ名の付いた空ファイルを放り込んでおいた。

継続的インテグレーション

ビルド
- 夜間ビルドのみ。
  - 当初はチェックインごとにビルドしていたが、ビルドサーバが過負荷になって他に影響が出たので泣く泣くやめた。
  - 問題の発見が遅れるのでアンチパターンだと思う。
- ビルド通知ツールを入れておくとビルド結果がバルーンで表示されるようになる。
- 当然ながらテストが失敗すると赤くなる。
  - 赤い日々を過ごしてはいけない。赤くなったら騒ぐ人は必要。
  - 環境が原因の場合は切り分け調査に時間がかかる。
- ビルドされたバージョンには自動的にラベルが付加される。
- 変更がない日はビルドが実行されない。
成果物
- ビルド結果は共有フォルダに保管する。
- /ブランチ名/(Debug|Release)/ソリューション名/プロジェクト名/hoge.exe のように出力先を細かく設定できる。
静的解析とかカバレッジとか
- 黄色い日々を過ごしてはいけない。少しでも黄色があると慣れてしまうので撲滅する文化が必要。
- レポートを上手く使いこなせなかった。

マイグレーション

スキーマとデータはリポジトリで管理
- Visual StudioとSQL Server Expressを組み合わせると、開発環境でアプリを実行するときにデータベースファイル（MDF）を自動的にアタッチして実行してくれる。つまり、開発端末のデータベースを同一に揃えることが可能。
- 数百MBのMDFファイルをリポジトリに入れていた。
  - リポジトリサイズが大きくなるとビルドプロセスが重くなる。そのため、ビルドサーバでビルドする時にMDFファイルの作業コピーを作らないように設定した。
  - 自動ビルドで残す世代を制限しないとディスクスペースの消費が激しい。
本番環境
- データベースファイルをCD-Rに焼いておき、現地で配置する。
- あるいは事前に用意したSQLを流す。
  - マスターデータが変わるのは法改正みたいな特殊な世界だったので参考にならないと思う。
ユニットテスト
- ユニットテストの実行時に接続文字列を変更し、空のMDFをアタッチしてテストを実行するようにした。
- テストケースごとにデータベースを空にする。
ビルドサーバの自動テスト
- アプリの実行時にMDFをアタッチする機能は SQL Server Express しか使えない。そのため、SQL Server Enterpriseでアプリを実行する時はSQL Serverに接続する必要がある。