OITEC第19回勉強会。開発フローに合わせたTFSの使い方について。

1. チームでの開発フローに
合わせたTFS運用
2014/7/19
OITEC 第19回勉強会
貞松 政史
@sady_nitro

2. 自己紹介
•貞松 政史 (@sady_nitro)
•＃R社
•仕事では専らマイクロソフト製品を利用
•趣味で色々な技術をちょっとかじっては飽きる
多芸は無芸を地でいく、自作自演何でも屋

3. 本セッションの目的
Team Foundation Server(TFS)について…
•聞いたことはあるけど詳しくは知らない
•機能は一通り知ってるけど、どう活用したら
いいかわからない
•既に導入済みだけど、ソース管理ぐらいしか
使ってない
と、いう方の参考になれば幸い

4. とりあえずTFSの概要
•Team Foundation Server（TFS）
–「チームでの開発」に関する機能を司るサーバー製品
–Visual Source Safe（VSS）の後継製品
–ソース管理に加えてプロジェクト管理などの機能を
備えている
–VisualStudioファミリーの一製品として組み
込まれている
•Team Foundation Service
–TFSのクラウドサービス（ただし英語表示）
–現在はVisualStudioOnlineの一部として提供

5. おしながき
1. 導入
2. モダンなチーム開発フロー
3. TFSでやってみよう
4. まとめ

6. 導入
理想と現実

7. ありがちな現状
• ガチガチのウォーターフォール
（既にデスマまっしぐら）
• ソース管理が日付フォルダ
• かろうじてバージョン管理を導入しているものの
未だにVSS、良くてSVN（Git何それおいしいの？）
そこまで悲惨ではないところもあるとは思う

8. 理想的なALM
• アジャイル開発
• 分散リポジトリのソース管理(要はGit)
• チケット駆動開発
• ユニットテスト、継続的インテグレーション(CI)
• プロトタイピング、継続的デリバリー
これ全部TFSで出来ますよ
⇒この流れで使える機能をざらっと説明するのが
マイクロソフトのセミナー

9. 全部いっぺんには無理…
やれない理由（やらない理由）も様々…
• プロジェクトがアジャイル開発に向いてない
⇒アジャイルが何かよくわかってないだけの場合も…
⇒別にアジャイルじゃなくてもいいと思う
• Gitコワイ
⇒個人的には別に何を使ってもいいと思う
• テストは腕力でやってます
⇒ユニットテストコードを書くのは必須
⇒これも何を使ってもいいと思う（書かないよりは）
• 組織のしがらみ（または現状の技術力）の問題
⇒…。
小さくでいいから始めてみよう

10. モダンなチーム開発フロー
ソース管理、トラッキング、CI等々…

11. モダンな開発と言っても様々
最近よく見かけるモダンなチーム開発
•アジャイル開発
•ソース管理
•トラッキング(Task, Bug, Issue)
•継続的インテグレーション(CI)
利用するツール、サービスも様々

12. ソース管理(だけじゃないけど)
•GitHub
•Bitbucket

13. トラッキング
•Redmine
•PivotalTracker

14. 継続的インテグレーション(CI)
•Jenkins
•Circle CI
•Travis CI
•Wercker

15. お手本にしたい実例
「はてなブログチームの開発フローとGitHub」
https://speakerdeck.com/shibayu36/haten
aburogutimufalsekai-fa-hurotogithub
•GitHubによる管理
•タスク管理はIssueのみ
•コードレビューはPull Request
•上記に加えてカンバンやレビューの仕組みを
導入して改善している

16. TFSでやってみよう
•じゃあGitHubでやればいいじゃn(ry
⇒VisualStudioで開発(.NET系の開発)を
するならばTFSを利用するのがベター
⇒同様のフローをTFS(and VisualStudio)で
実現するにはどうするか

17. TFSでやってみよう
全部盛りの実力

18. さあはじめよう
•小さく始めよう
⇒いきなり全部をやらなくても
高価なエディションを導入しなくても
改善の効果は見込めるはず
•TFS(VisualStudio)のバージョンは2013の
Update2を想定
•エディションはProfessional以下を想定

19. 小さく、とは言え
•小さく始めよう、とはいえ最低限最初に導入すべき
もの(考慮しておくべきこと)もある
•Team Foundation Server をチームで使う前に
するべき10のこと
http://kaji-
3.hatenablog.com/entry/2012/10/17/06584
6

20. このあたりは考慮しておこう
•ソース管理の選択
•ユニットテストフレームワークの選択
•ブランチ計画
•チェックインポリシーとゲートチェックイン
•Power Toolsの導入
•ドキュメント管理
•プロセステンプレート
導入するレベルに応じてどこまで考慮するかが
変わってくる

21. ソース管理の選択
•Team Foundation Serverソース管理
–Subversionライク
–集中リポジトリ
–チェックイン・チェックアウト
–ファイルのロックは選択可能
•Git
–おなじみのGitがそのまま利用可能
–VS上でリポジトリを操作できる(GUI)
–VS2013Update2から作業項目に関連付け可能

22. ユニットテストフレームワークの選択
•MSTest
–VisualStudio完全統合。
–テストランナー、カバレッジ分析、TFSビルド設定など、
ひと手間かけずにすぐに導入可能。
–TestCaseがない。代わりにデータソース読み込みが可能。
•NUnit
–TestAdapterを導入すればVisualStudio上で利用可能
–一般的な何とかUnit的(JUnitなど)
–もちろんTestCaseが使える
–必要十分

23. ブランチ計画
•TFSバージョン管理でもGitでも同様
–Master
⇒本番（リリース版）と同一
–Develop
⇒開発中の最新
必ずビルド＆ユニットテストが通るヘルシーコード
–Feature
⇒個別の機能開発用
完成後Developにマージされる
•Version Control Guide (ex-Branching &
Merging)
http://vsarbranchingguide.codeplex.com/releas

24. チェックインポリシーとゲートチェックイン
•チェックインポリシー
–(TFSバージョン管理のみ)チェックイン時の
ポリシーを設定可能
–コード分析、ビルド、作業項目、変更セットの
コメントポリシー
•ゲートチェックイン
–チェックイン時にビルドやユニットテストが
通らなければチェックインできないなど
自動ビルド時の設定が可能

25. Power Toolsの導入
•TeamFoundationServer2013 PowerTools
http://visualstudiogallery.msdn.microsoft.com
/f017b10c-02b4-4d6d-9845-58a06545627f
–プロセステンプレートのカスタマイズが可能
–リポジトリ操作がエクスプローラー上で出来る
–とりあえず入れておいて損は無い

26. ドキュメント管理
•リポジトリにドキュメント用のフォルダを作る
–プロジェクトに関するドキュメントは全部ここに
–個人的にはブランチ内に含めないほうが良いのでは
•SharePointServerを利用する
–Wikiなども含め、ポータルとしてひとまとめに
してしまうのであれば良いと思う
•ファイルサーバーで管理する
–致し方なし…何にしても決め事が重要になる

27. プロセステンプレート
•テンプレートの選択
–３つのプロセステンプレートから選択
–デフォルトのプロセステンプレート
全てアジャイルなのが柔軟性を損ねている
（と個人的には思う）
•テンプレートのカスタマイズ
–そのまま使用する必要はない
–開発のプロセスに合わせてカスタマイズ
–字面や期間の切り方を変えるだけでかなり改善する

28. ここからが本番
•現状に合わせて、出来ることから取り組む
•うまく組み合わせればVisualStudio
（とWebポータル）上で全て完結できるはず
•GitHub(＋α)でやっているようなフローで実際に
やってみる
Issues
タスク等の
トラッキング
Pull Request
コードレビュー
Jenkins等
CI環境

29. GitHubでいうところのIssues
GitHubのIssues

30. GitHubでいうところのissues
TFSのバックログとタスク

31. GitHubでいうところのPull Request
GitHubのPull Request

32. GitHubでいうところのPull Request
TFSの作業項目と変更セットの連携

33. CI環境の構築
Jenkins等でなくTFSで
•自動ビルドの設定
•ビルド定義
–トリガー(ビルド実行のタイミング)
–ソース設定
–ビルドの既定値
–プロセス
–アイテム保持ポリシー

34. CI環境の構築
•継続的インテグレーション
–チェックインする度にビルドを実行する
–自動テストの実行も可能
•ゲートチェックイン
–送信された変更が正常にマージされ、ビルドされる
場合のみチェックインを受け入れる
–プロセス設定で、自動テストの設定およびテスト
失敗時にビルド自体を失敗とする設定が可能
–正常にマージ→ビルド成功→テスト成功で
ようやくチェックイン、という定義も可能

35. CI環境の構築

36. ドキュメント管理もここで
•リポジトリにドキュメントフォルダを作成する
•Master, Develop, Featureのブランチには
含めない
•開発メンバー以外とのやり取りにも使用
(Team Explorerを利用、CALに注意…)
•PowerToolsを導入していればエクスプローラー上
で操作も容易に

37. 当面の課題
•Team Roomなるもの
–TFS上のイベントをフックしてくれるが、これ自体の
使い勝手はまだ微妙…
–Team Room自体が進化してくれるのが望ましいが
現状では外部のツールで補完するしかない…
•上位のエディションでないといまいちなところも
–コードレビュー
–テスト全般

38. まとめ
結局何を言いたかったかという話

39. まとめ
•何でもできる全部盛りのTFS
•いきなり全部はやっぱり無理…
⇒とはいえ、どうせ使うならソース管理だけ
なんてもったいない
•最低限必要なものは導入するとして、あとは
出来る限りで始めてみよう

40. まとめ
•全部盛りが理想的
⇒でも一つ一つにちゃんと意味（効果）がある
•想像してみよう
⇒これが導入されてなかったら…
逆にこれが導入されていれば…
•結局最終的にはトライアンドエラー
⇒小さく始めて効果を実感
大きく広めていこう