第10回 Plus Programming .net 勉強会「TFSで エンタープライズ・アジャイル スクラム開発 ～Team Foundation Server でスクラム開発を始めよう！～」のセッションスライド DevOps （開発と運用）には役割の違いがあります。Dev は早くリリースしたい、Ops には安定運用の責任があります。TFS スクラム開発を導入して早く開発が行えるようになっても、リリースに時間と人的リソース（コスト）がかかっていては早いサイクルで製品を出荷することができません。 TFS リリース管理 を導入することで、ソースコードのビルドからサーバーへのリリースまでを効率化・自動化する方法を解説します。

1. TFS リリース管理 による
継続的デリバリー
TFS Release Management を使ったリリースの効率化
1
ソフトバンク・テクノロジー株式会社 後藤 康浩
第10回 Plus Programming .net 勉強会 - 2014年12月20日（土）
Copyright© 2014 Plus Programming .net All Rights Reserved.

2. セッションのゴール
 TFSリリース管理で何ができるか？を理解する
 Release Management for Visual Sttudio 2013® 製品を
使う具体的なイメージを持つ
 自社案件にリリース管理を 採用 出来るか？
検討出来るようになる
2

3. おことわり
 Release Management の最新機能（2014年12月現在）
については今回は話しません
 Azure VM へのリリース
 PowerShell DSC による 自動配置
…. etc
3
Release Management は日々進化しています
現在も新機能がどんどん追加されています

4. 自己紹介
4
 後藤 康浩
ソフトバンク・テクノロジー株式会社 サービス開発者
 普段はC#で開発しています。
 TFS の運用・管理・教育の担当をしています。
 今年 リリース管理（Release Management）を導入・構築

5. アジェンダ
1. リリース管理導入の背景
2. リリース管理のＭＳ製品 Release Management とは
3. 実際にリリース管理を使ってのリリースの流れ
4. 実際に導入してみての効果
5

6. リリース管理導入の背景
なぜリリース管理を採用したのか
6

7. さらに早くリリースすることを求められる
 我々のミッションはリリースすれば完了ではない
 機能追加、問題の修正、ユーザーのニーズ変化に対応
 十分な品質を保ちながら継続的にデリバリー
開発 が Rapid なら、リリース も Rapid が必要！
7
早く
開発
早くリリース？
早く
開発
早くリリース？
アレ？これで Rapid Release ?（こんなに極端ではないですが）
わかってます！

8. DevOps 役割の違い
 Dev は早くリリースしたいが、Ops には安定運用の責任がある
8
設計 実装 テスト 検証リリース
自動ビルド・単体テスト
本番リリース
開発の責任
dev
運用の責任
ops
スクラム
配置 検証 承認受入

9. リリースで削減できる工数は無いか？
 検証の自動化は困難
単体テストなら自動化できる
UI テストの全自動化は結構大変
 リリース管理 で配置を自動化・承認を効率化
9
配置 検証 承認受入
Release Management
Team Foundation Server
Visual Studio
Release Management
※UIテストの自動化には ラボ ( TFS Lab Management ) が使えます。製品の性質に応じて検討してみてください。

10. リリース管理を採用
開発のテスト・検証もリリースと数えれば最も効率化できるポイント
10

11. Release Management®とは
 TFS のビルドと連携可能
 ビルドされたものを、RM Deploayment Agent がインストール
されているサーバーに自動で配置
弊社 ではカスタマイズして Windows Azure に配置しています
 配置するときに 承認 と アクション を追加出来る
承認フロー と 配置アクションの自動化 がRMの主機能
11

12. Release Management の構成
12
※引用元： Release Management for Visual Studio 2013 インストールガイド

13. Release Management の構成
13
※引用元： Release Management for Visual Studio 2013 インストールガイド

14. RM 特徴は承認フローと配置の自動化
14
事前にビルド定義・リリースパス・リリーステンプレートを決めておき、ワークフローを開始する
名前 内容 指定されるもの
ビルド定義 どのソースコードをビルド？
どこに出力？
 ソース
 ビルドドロップ（出力先）
リリースパス どういうワークフロー？  ステージ
 人・グループ
（受入・配置・検証・承認 の担当者）
リリーステンプレート どのリリースパス？
どういう配置処理？
 リリースパス
 具体的な配置処理を指定
 ビルド定義
リリース 実際のリリース処理と結果
どのビルド定義のビルド？
どのリリーステンプレート？
 リリーステンプレート
 ビルド番号
＝ビルドドロップの中身
（ビルド定義で指定された中から）

15. ビルド定義・リリーステンプレート 関係図
15
ソース
ビルド
ドロップ
（出力先）
ビルド定義
ビルド番号
（ビルド結果）
リリースパス
ステージ
（ワークフロー）
人・グループ
リリース
テンプレート
具体的な
配置処理
リリース
Visual Studo & TFS Build Release Management

16. リリースパス「ステージ」でワークフローを定義
16
ステージ
受入 承認者を1名指定
（自動にするとスキップ）
配置
配置を行う
RMに用意された処理が実行できる
（PowerShell を実行出来る）
検証
正常にコンポーネントが配置されたか？
検証者を1名指定
（自動にするとスキップ）
承認 承認者を複数名指定
次のステージに進む / リリース完了

17. 複数のステージでワークフローを定義
17
ステージ1
パッケージバージョンの確認
ステージ2
ステージング環境にデプロイ
ステージ3
スワップして動作確認する
受入 スキップ（自動） 自動（スキップ） 承認
配置
スキップ
（指定なし）
Windows Azure Staging に配置
（PowerShell 実行）
Windows Azure
Staging と Production を
スワップ
（PowerShell 実行）
検証
リリースするモジュールの
バージョンを確認（自動）
ステージング環境動作確認
（自動）
運用環境動作確認
（自動）
承認 承認 承認 承認
１ ２ ３

18. リリースパス作成のデモ
18

19. 配置を リリーステンプレートで自動化
 配置で指定できるのはアクション、コンポーネント
 Microsoft が用意している「コピー」や「DB初期化」などの操作が出来る
 RM Agent が配置されているサーバーで実行できる操作
 RMは RM Agent があるサーバーにリリースする機能
 弊社ではここをカスタマイズして、
Agent があるサーバーから PowerShell で Windows Azure 上に配置している
19

20. リリーステンプレート作成のデモ
20

21. バージョン管理「分岐」に対応するには？
 ソース バージョン管理では リリース用に分岐を作成 するルールで運用
 これに対応するために、ビルド定義・リリーステンプレートを複製
21
M : メインブランチ
D#001 : 開発用ブランチ
P#001 : リリース用ブランチ
マージ ( merge )
分岐 ( branch )
分岐 ( branch )
最新ソースコード
リリースに使うソースコード
リリース毎に
新しいブランチ

22. ビルド定義をリリース用に複製
 ビルド定義をメインブランチ用に作成しておく
 リリースブランチ用に複製
 Community TFS Build Manager を使えば、ブランチを指定して複製できる
22
M : メインブランチ
P#001 : リリース用ブランチ
分岐 ( branch )
最新ソースコードを指す
今回リリース用を指す
M用 ビルド定義
P#001用 ビルド定義

23. リリーステンプレートもリリース用に複製
 リリーステンプレートも複製
複製したビルド定義を指定し
リリースブランチ用のリリーステンプレートとする
 複製したリリーステンプレートでリリース
 リリースのたびにテンプレートが増える
 以前のバージョンをいつでもリリースできる
23
ソース
ビルド
ドロップ
（出力先）
ビルド定義
ビルド番号
（ビルド結果）
リリース
テンプレート
リリース
複製
複製
※複製しないで、ビルド定義・リリーステンプレートを書き換えた場合は、以前のリリースをもう一度実行することは出来なくなります

24. 実際のリリースの流れ
完成した承認フローと 配置の自動化
24

25. 実際のリリースの流れ（1）
1. 開発完了
2. 開発者がビルド定義の複製・リリーステンプレートの複製を用意
3. 開発者がビルドを実行、
リリースするパッケージがビルドドロップに用意される
25
Visual Studio
ビルド開始
Build DropTFS Build
ビルド定義
複製
リリーステンプレート
複製

26. ブランチを指定してビルド定義複製
26ブランチを指定

27. チームエクスプローラーでビルド開始
27※「ビルド」は TFS ビルドサーバーのキューに追加されて、順次処理されます。

28. ビルド定義複製のデモ
28

29. ブランチ用にリリーステンプレート複製
29
ブランチの
ビルド定義を選択

30. 実際のリリースの流れ（2）
4. Release Management クライアントでリリース開始
5. 承認依頼を見て、内容を確認（パッケージとバージョンを確認）
6. Web or Release Management クライアント で承認
7. 配置が実施される
30
RM Client
開始
パッケージ
確認
RM Agent
配置
配置の確認
RM Client
承認

31. RMクライアントでリリース開始
31
リリーステンプレート
を選択
ビルドは
「最新」を選択

32. RMクライアントで承認
32

33. ＷＥＢブラウザ で承認
33

34. リリースの状況を RM で確認
34

35. 効果
 本番リリース
 Azure に配置する時間自体は短縮されない
 開発エンジニアが ダブルチェック で複数名数時間アサインが不要に
 リリースは運用メンバーだけで行える あるべき状態になった
 開発・検証環境にも何度もリリースが出来るため、バグの発見・修正から
再テストまでの時間が短縮出来る。
35

36. リリース管理導入効果
早くリリース
できるようになった
36
Rapid Release

37. Plus Programming .net 勉強会
http://www.facebook.com/PlusProgramming.net
37Copyright© 2014 Plus Programming .net All Rights Reserved.