Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TFS リリース管理 による継続的デリバリー TFS Release Management を使ったリリースの効率化

2,750 views

Published on

第10回 Plus Programming .net 勉強会「TFSで エンタープライズ・アジャイル スクラム開発 ~Team Foundation Server でスクラム開発を始めよう!~」のセッションスライド

DevOps (開発と運用)には役割の違いがあります。Dev は早くリリースしたい、Ops には安定運用の責任があります。TFS スクラム開発を導入して早く開発が行えるようになっても、リリースに時間と人的リソース(コスト)がかかっていては早いサイクルで製品を出荷することができません。

TFS リリース管理 を導入することで、ソースコードのビルドからサーバーへのリリースまでを効率化・自動化する方法を解説します。

Published in: Technology
  • Be the first to comment

TFS リリース管理 による継続的デリバリー TFS Release Management を使ったリリースの効率化

  1. 1. TFS リリース管理 による 継続的デリバリー TFS Release Management を使ったリリースの効率化 1 ソフトバンク・テクノロジー株式会社 後藤 康浩 第10回 Plus Programming .net 勉強会 - 2014年12月20日(土) Copyright© 2014 Plus Programming .net All Rights Reserved.
  2. 2. セッションのゴール  TFSリリース管理で何ができるか?を理解する  Release Management for Visual Sttudio 2013® 製品を 使う具体的なイメージを持つ  自社案件にリリース管理を 採用 出来るか? 検討出来るようになる 2
  3. 3. おことわり  Release Management の最新機能(2014年12月現在) については今回は話しません  Azure VM へのリリース  PowerShell DSC による 自動配置 …. etc 3 Release Management は日々進化しています 現在も新機能がどんどん追加されています
  4. 4. 自己紹介 4  後藤 康浩 ソフトバンク・テクノロジー株式会社 サービス開発者  普段はC#で開発しています。  TFS の運用・管理・教育の担当をしています。  今年 リリース管理(Release Management)を導入・構築
  5. 5. アジェンダ 1. リリース管理導入の背景 2. リリース管理のMS製品 Release Management とは 3. 実際にリリース管理を使ってのリリースの流れ 4. 実際に導入してみての効果 5
  6. 6. リリース管理導入の背景 なぜリリース管理を採用したのか 6
  7. 7. さらに早くリリースすることを求められる  我々のミッションはリリースすれば完了ではない  機能追加、問題の修正、ユーザーのニーズ変化に対応  十分な品質を保ちながら継続的にデリバリー 開発 が Rapid なら、リリース も Rapid が必要! 7 早く 開発 早くリリース? 早く 開発 早くリリース? アレ?これで Rapid Release ?(こんなに極端ではないですが) わかってます!
  8. 8. DevOps 役割の違い  Dev は早くリリースしたいが、Ops には安定運用の責任がある 8 設計 実装 テスト 検証リリース 自動ビルド・単体テスト 本番リリース 開発の責任 dev 運用の責任 ops スクラム 配置 検証 承認受入
  9. 9. リリースで削減できる工数は無いか?  検証の自動化は困難 単体テストなら自動化できる UI テストの全自動化は結構大変  リリース管理 で配置を自動化・承認を効率化 9 配置 検証 承認受入 Release Management Team Foundation Server Visual Studio Release Management ※UIテストの自動化には ラボ ( TFS Lab Management ) が使えます。製品の性質に応じて検討してみてください。
  10. 10. リリース管理を採用 開発のテスト・検証もリリースと数えれば最も効率化できるポイント 10
  11. 11. Release Management®とは  TFS のビルドと連携可能  ビルドされたものを、RM Deploayment Agent がインストール されているサーバーに自動で配置 弊社 ではカスタマイズして Windows Azure に配置しています  配置するときに 承認 と アクション を追加出来る 承認フロー と 配置アクションの自動化 がRMの主機能 11
  12. 12. Release Management の構成 12 ※引用元: Release Management for Visual Studio 2013 インストールガイド
  13. 13. Release Management の構成 13 ※引用元: Release Management for Visual Studio 2013 インストールガイド
  14. 14. RM 特徴は承認フローと配置の自動化 14 事前にビルド定義・リリースパス・リリーステンプレートを決めておき、ワークフローを開始する 名前 内容 指定されるもの ビルド定義 どのソースコードをビルド? どこに出力?  ソース  ビルドドロップ(出力先) リリースパス どういうワークフロー?  ステージ  人・グループ (受入・配置・検証・承認 の担当者) リリーステンプレート どのリリースパス? どういう配置処理?  リリースパス  具体的な配置処理を指定  ビルド定義 リリース 実際のリリース処理と結果 どのビルド定義のビルド? どのリリーステンプレート?  リリーステンプレート  ビルド番号 =ビルドドロップの中身 (ビルド定義で指定された中から)
  15. 15. ビルド定義・リリーステンプレート 関係図 15 ソース ビルド ドロップ (出力先) ビルド定義 ビルド番号 (ビルド結果) リリースパス ステージ (ワークフロー) 人・グループ リリース テンプレート 具体的な 配置処理 リリース Visual Studo & TFS Build Release Management
  16. 16. リリースパス「ステージ」でワークフローを定義 16 ステージ 受入 承認者を1名指定 (自動にするとスキップ) 配置 配置を行う RMに用意された処理が実行できる (PowerShell を実行出来る) 検証 正常にコンポーネントが配置されたか? 検証者を1名指定 (自動にするとスキップ) 承認 承認者を複数名指定 次のステージに進む / リリース完了
  17. 17. 複数のステージでワークフローを定義 17 ステージ1 パッケージバージョンの確認 ステージ2 ステージング環境にデプロイ ステージ3 スワップして動作確認する 受入 スキップ(自動) 自動(スキップ) 承認 配置 スキップ (指定なし) Windows Azure Staging に配置 (PowerShell 実行) Windows Azure Staging と Production を スワップ (PowerShell 実行) 検証 リリースするモジュールの バージョンを確認(自動) ステージング環境動作確認 (自動) 運用環境動作確認 (自動) 承認 承認 承認 承認 1 2 3
  18. 18. リリースパス作成のデモ 18
  19. 19. 配置を リリーステンプレートで自動化  配置で指定できるのはアクション、コンポーネント  Microsoft が用意している「コピー」や「DB初期化」などの操作が出来る  RM Agent が配置されているサーバーで実行できる操作  RMは RM Agent があるサーバーにリリースする機能  弊社ではここをカスタマイズして、 Agent があるサーバーから PowerShell で Windows Azure 上に配置している 19
  20. 20. リリーステンプレート作成のデモ 20
  21. 21. バージョン管理「分岐」に対応するには?  ソース バージョン管理では リリース用に分岐を作成 するルールで運用  これに対応するために、ビルド定義・リリーステンプレートを複製 21 M : メインブランチ D#001 : 開発用ブランチ P#001 : リリース用ブランチ マージ ( merge ) 分岐 ( branch ) 分岐 ( branch ) 最新ソースコード リリースに使うソースコード リリース毎に 新しいブランチ
  22. 22. ビルド定義をリリース用に複製  ビルド定義をメインブランチ用に作成しておく  リリースブランチ用に複製  Community TFS Build Manager を使えば、ブランチを指定して複製できる 22 M : メインブランチ P#001 : リリース用ブランチ 分岐 ( branch ) 最新ソースコードを指す 今回リリース用を指す M用 ビルド定義 P#001用 ビルド定義
  23. 23. リリーステンプレートもリリース用に複製  リリーステンプレートも複製 複製したビルド定義を指定し リリースブランチ用のリリーステンプレートとする  複製したリリーステンプレートでリリース  リリースのたびにテンプレートが増える  以前のバージョンをいつでもリリースできる 23 ソース ビルド ドロップ (出力先) ビルド定義 ビルド番号 (ビルド結果) リリース テンプレート リリース 複製 複製 ※複製しないで、ビルド定義・リリーステンプレートを書き換えた場合は、以前のリリースをもう一度実行することは出来なくなります
  24. 24. 実際のリリースの流れ 完成した承認フローと 配置の自動化 24
  25. 25. 実際のリリースの流れ(1) 1. 開発完了 2. 開発者がビルド定義の複製・リリーステンプレートの複製を用意 3. 開発者がビルドを実行、 リリースするパッケージがビルドドロップに用意される 25 Visual Studio ビルド開始 Build DropTFS Build ビルド定義 複製 リリーステンプレート 複製
  26. 26. ブランチを指定してビルド定義複製 26ブランチを指定
  27. 27. チームエクスプローラーでビルド開始 27※「ビルド」は TFS ビルドサーバーのキューに追加されて、順次処理されます。
  28. 28. ビルド定義複製のデモ 28
  29. 29. ブランチ用にリリーステンプレート複製 29 ブランチの ビルド定義を選択
  30. 30. 実際のリリースの流れ(2) 4. Release Management クライアントでリリース開始 5. 承認依頼を見て、内容を確認(パッケージとバージョンを確認) 6. Web or Release Management クライアント で承認 7. 配置が実施される 30 RM Client 開始 パッケージ 確認 RM Agent 配置 配置の確認 RM Client 承認
  31. 31. RMクライアントでリリース開始 31 リリーステンプレート を選択 ビルドは 「最新」を選択
  32. 32. RMクライアントで承認 32
  33. 33. WEBブラウザ で承認 33
  34. 34. リリースの状況を RM で確認 34
  35. 35. 効果  本番リリース  Azure に配置する時間自体は短縮されない  開発エンジニアが ダブルチェック で複数名数時間アサインが不要に  リリースは運用メンバーだけで行える あるべき状態になった  開発・検証環境にも何度もリリースが出来るため、バグの発見・修正から 再テストまでの時間が短縮出来る。 35
  36. 36. リリース管理導入効果 早くリリース できるようになった 36 Rapid Release
  37. 37. Plus Programming .net 勉強会 http://www.facebook.com/PlusProgramming.net 37Copyright© 2014 Plus Programming .net All Rights Reserved.

×