TFS リリース管理による継続的デリバリー

TFS Release Management を使ったリリースの効率化

1

ソフトバンク・テクノロジー株式会社 後藤康浩

第10回 Plus Programming .net 勉強会 - 2014年12月20日（土）

Copyright© 2014 Plus Programming .net All Rights Reserved.

セッションのゴール

TFSリリース管理で何ができるか？を理解する

Release Management for Visual Sttudio 2013®製品を

使う具体的なイメージを持つ

自社案件にリリース管理を採用出来るか？

検討出来るようになる

2

おことわり

Release Management の最新機能（2014年12月現在）

については今回は話しません

Azure VM へのリリース

PowerShell DSC による自動配置

…. etc

3

Release Management は日々進化しています現在も新機能がどんどん追加されています

自己紹介

4

後藤 康浩ソフトバンク・テクノロジー株式会社 サービス開発者

普段はC#で開発しています。

TFS の運用・管理・教育の担当をしています。

今年リリース管理（Release Management）を導入・構築

アジェンダ

1. リリース管理導入の背景

2. リリース管理のＭＳ製品 Release Management とは

3. 実際にリリース管理を使ってのリリースの流れ

4. 実際に導入してみての効果

5

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

6

さらに早くリリースすることを求められる

我々のミッションはリリースすれば完了ではない

機能追加、問題の修正、ユーザーのニーズ変化に対応

十分な品質を保ちながら継続的にデリバリー

開発が Rapid なら、リリースも Rapid が必要！

7

早く開発

早くリリース？早く開発

早くリリース？

アレ？これで Rapid Release ?（こんなに極端ではないですが）

わかってます！

DevOps 役割の違い

Dev は早くリリースしたいが、Ops には安定運用の責任がある

8

設計 実装 テスト 検証リリース

自動ビルド・単体テスト

本番リリース

開発の責任

dev

運用の責任

opsスクラム

配置 検証 承認受入

リリースで削減できる工数は無いか？

検証の自動化は困難

単体テストなら自動化できる

UI テストの全自動化は結構大変

リリース管理で配置を自動化・承認を効率化

9

配置 検証 承認受入

Release Management

Team Foundation Server

Visual Studio

Release Management

※UIテストの自動化にはラボ ( TFS Lab Management ) が使えます。製品の性質に応じて検討してみてください。

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

10

Release Management®とは

TFS のビルドと連携可能

ビルドされたものを、RM Deploayment Agent がインストール

されているサーバーに自動で配置

弊社ではカスタマイズしてWindows Azure に配置しています

配置するときに承認とアクションを追加出来る

承認フローと配置アクションの自動化がRMの主機能11

Release Management の構成

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

Release Management の構成

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

RM 特徴は承認フローと配置の自動化

14

事前にビルド定義・リリースパス・リリーステンプレートを決めておき、ワークフローを開始する

名前 内容 指定されるもの

ビルド定義 どのソースコードをビルド？どこに出力？

ソース ビルドドロップ（出力先）

リリースパス どういうワークフロー？ ステージ 人・グループ（受入・配置・検証・承認の担当者）

リリーステンプレート どのリリースパス？どういう配置処理？

リリースパス 具体的な配置処理を指定 ビルド定義

リリース 実際のリリース処理と結果どのビルド定義のビルド？どのリリーステンプレート？

リリーステンプレート ビルド番号＝ビルドドロップの中身（ビルド定義で指定された中から）

ビルド定義・リリーステンプレート関係図

15

ソース

ビルドドロップ（出力先）

ビルド定義

ビルド番号（ビルド結果）

リリースパス

ステージ（ワークフロー）

人・グループ

リリーステンプレート

具体的な配置処理

リリース

Visual Studo & TFS Build Release Management

リリースパス「ステージ」でワークフローを定義

16

ステージ

受入 承認者を1名指定（自動にするとスキップ）

配置配置を行う

RMに用意された処理が実行できる（PowerShellを実行出来る）

検証正常にコンポーネントが配置されたか？

検証者を1名指定（自動にするとスキップ）

承認 承認者を複数名指定

次のステージに進む / リリース完了

複数のステージでワークフローを定義

17

ステージ1

パッケージバージョンの確認ステージ2

ステージング環境にデプロイステージ3

スワップして動作確認する

受入 スキップ（自動） 自動（スキップ） 承認

配置スキップ

（指定なし）Windows Azure Staging に配置

（PowerShell 実行）

Windows Azure Staging と Production を

スワップ（PowerShell 実行）

検証リリースするモジュールのバージョンを確認（自動）

ステージング環境動作確認（自動）

運用環境動作確認（自動）

承認 承認 承認 承認

１ ２ ３

リリースパス作成のデモ

18

配置をリリーステンプレートで自動化

配置で指定できるのはアクション、コンポーネント

Microsoft が用意している「コピー」や「DB初期化」などの操作が出来る

RM Agent が配置されているサーバーで実行できる操作

RMは RM Agent があるサーバーにリリースする機能

弊社ではここをカスタマイズして、Agent があるサーバーから PowerShell で Windows Azure 上に配置している

19

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

20

バージョン管理「分岐」に対応するには？

ソースバージョン管理ではリリース用に分岐を作成するルールで運用

これに対応するために、ビルド定義・リリーステンプレートを複製

21

M : メインブランチ

D#001 : 開発用ブランチ

P#001 : リリース用ブランチ

マージ ( merge )

分岐 ( branch )

分岐 ( branch )

最新ソースコード

リリースに使うソースコードリリース毎に新しいブランチ

ビルド定義をリリース用に複製

ビルド定義をメインブランチ用に作成しておく

リリースブランチ用に複製

Community TFS Build Manager を使えば、ブランチを指定して複製できる

22

M : メインブランチ

P#001 : リリース用ブランチ

分岐 ( branch )

最新ソースコードを指す

今回リリース用を指す

M用ビルド定義

P#001用ビルド定義

リリーステンプレートもリリース用に複製

リリーステンプレートも複製

複製したビルド定義を指定し

リリースブランチ用のリリーステンプレートとする

複製したリリーステンプレートでリリース

リリースのたびにテンプレートが増える

以前のバージョンをいつでもリリースできる

23

ソース

ビルドドロップ（出力先）

ビルド定義

ビルド番号（ビルド結果）

リリーステンプレート

リリース

複製

複製

※複製しないで、ビルド定義・リリーステンプレートを書き換えた場合は、以前のリリースをもう一度実行することは出来なくなります

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

24

実際のリリースの流れ（1）

1. 開発完了

2. 開発者がビルド定義の複製・リリーステンプレートの複製を用意

3. 開発者がビルドを実行、

リリースするパッケージがビルドドロップに用意される

25

Visual Studioビルド開始

Build DropTFS Buildビルド定義複製

リリーステンプレート複製

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

26ブランチを指定

チームエクスプローラーでビルド開始

27※「ビルド」は TFS ビルドサーバーのキューに追加されて、順次処理されます。

ビルド定義複製のデモ

28

ブランチ用にリリーステンプレート複製

29ブランチの

ビルド定義を選択

実際のリリースの流れ（2）

4. Release Management クライアントでリリース開始

5. 承認依頼を見て、内容を確認（パッケージとバージョンを確認）

6. Web or Release Management クライアントで承認

7. 配置が実施される

30

RM Client開始

パッケージ

確認RM Agent配置

配置の確認RM Client承認

RMクライアントでリリース開始

31

リリーステンプレートを選択

ビルドは「最新」を選択

RMクライアントで承認

32

ＷＥＢブラウザで承認

33

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

34

効果

本番リリース

Azure に配置する時間自体は短縮されない

開発エンジニアが ダブルチェック で複数名数時間アサインが不要に

リリースは運用メンバーだけで行える あるべき状態になった

開発・検証環境にも何度もリリースが出来るため、バグの発見・修正から再テストまでの時間が短縮出来る。

35

リリース管理導入効果

早くリリースできるようになった

36

Rapid Release

Plus Programming .net 勉強会

http://www.facebook.com/PlusProgramming.net

37Copyright© 2014 Plus Programming .net All Rights Reserved.