Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

ウォーターフォール・アジャイル・DevOps どんなチームでも開発・テスト・リリースでVSTS/TFSをフル活用する方法

5 286 vues

Publié le

これから本格的に Visual Studio Team Services (旧Visual Studio Online) や Team Foundation Server を使い始めるチーム(マネージャ・リーダー・メンバー)向けに、画面操作のデモ含めて約2時間の研修用の資料です。

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

ウォーターフォール・アジャイル・DevOps どんなチームでも開発・テスト・リリースでVSTS/TFSをフル活用する方法

  1. 1. 開発・テスト・リリースで VSTS/TFSをフル活用する方法 ウォーターフォール・アジャイル・DevOps どんなチームでも 1 アバナード株式会社 シニアコンサルタント( Microsoft MVP )古賀 慎一 2016年11月21日(月) Copyright© 2016 Shin-ichi Koga All Rights Reserved.
  2. 2. このセッションのゴール  Work の使い方をイメージする Test と WorkのBug の使い方を決めることができる Build と Release の使い方とCodeに必要な条件を理解する VSTS / TFSをフル活用して、低コストで高品質な開発・運用を! 2 工程管理・進捗管理・開発 シナリオテスト管理 バグ管理 自動ビルド 承認ワークフローによるデプロイ ウォーターフォール・アジャイル・DevOps それぞれのチームにあった 自動テスト・分岐
  3. 3. 自己紹介 3 古賀 慎一 Microsoft MVP for Visual Studio and Development Technologies アバナード株式会社 シニアコンサルタント  前職ではクラウドサービス開発で TFS 導入事例 http://tech.surviveplus.net/archives/1114  某大手 情報サイトのデータ入稿システム のフレームワークを開発  「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか?  書籍執筆 日経BP社より発売中
  4. 4. アジェンダ  VSTS/TFSで出来ることはDevOps  Work による工程管理・進捗管理  Test によるシナリオテスト管理  Work の Bug によるバグ管理  Code によるソースバージョン管理  Build & Release による継続的デリバリー(自動ビルド・自動テスト・自動デプロイ) 4 このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )
  5. 5. VSTS/TFSで出来ることはDevOps ウォーターフォールとアジャイルに継続的デリバリーをプラスする 5
  6. 6. VSTS/TFSで何ができますか? Visual Studio Team Services のメニューを見るとわかります  Home ⇒ ダッシュボード・見える化  Code ⇒ ソースバージョン管理  Work ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム  Build & Release ⇒ 自動ビルド・自動テスト・自動デプロイ(継続的デリバリー)  Test ⇒ シナリオテスト管理・バグトラッキングシステム 6
  7. 7. VSTS/TFSで出来ることは DevOps  アジャイル(≒Dev) + 継続的デリバリー(≒Ops) = DevOps  開発向けの機能と運用向けの機能を分けずに1つのサービスとして提供  全ては 開発 と 運用 を繰り返す ためにある(早く安く高品質で) 7 中投資 中投資 時代の変化とニーズに応じて常にアップデート 数年で基礎から見直す
  8. 8. DevOps と各機能のバランス  Home ダッシュボード・見える化 (Dev = Ops)  Code ソースバージョン管理 (Dev)  Work タスク管理・工程管理・進捗管理・バグトラッキングシステム (Dev ≧ Ops)  Build & Release 継続的デリバリー (Ops)  Test シナリオテスト管理・バグトラッキングシステム ( Dev ≦ Ops ≒ QA ) 8 Dev Ops
  9. 9. VSTS/TFSはウォーターフォールでは活用できない?  メニューと用語がアジャイル・DevOps向け  そのままでは旧来のウォーターフォールでは使い方がわからない  Codeしか使われていない現場が多い 10年前の Visual SourceSafe と同じ使い方になりがち 9
  10. 10. 考え方は「前提として」ちゃんとつながっている  約40年前 ウォーターフォール (書類で管理、Windowsやパソコンが生まれる前)  約15年前 アジャイル (.NET 登場、Java が普及し始めた頃)  7年前 DevOps ( TFS 2010 DevOps対応に生まれ変わる )  現在 DevOps 2.0 へ (VSTS、Azure、クロスプラットフォーム、マイクロサービス) ※Microsoft Tech Summitより 作る物の機能・規模・複雑さの増大、スピードも求められる 書類で頑張る方法から、システムの支援を受けて効率化・自動化へ 10
  11. 11. 実は日本のウォーターフォールはもはやアジャイル!  要件、機能、実装、テストの繋がりを保って開発するも(WBS段階的詳細化)  テスト駆動開発などの開発手法を取り入れて、後工程を出来るだけ前倒し  最後まで顧客に見せないことはなく、早い段階で細かく動作をデモ  後工程になって明らかになる顧客の要望もできるだけ取り入れる  V字ではなく、WOOO... ≒ アジャイル ならば、より “アジャイルらしいウォーターフォール” で効率よくやろう! 11
  12. 12. 文書での管理からTFS画面での管理に変更できる PMBOKに出てくる文書で、  日々更新・集計するものは Work / Test に対応する画面がある 簡単入力・リアルタイムで見える化 ⇒ 報告時に書類にエクスポート  あまり変わらないものは Code に保存する Markdownはダッシュボードに表示可能 ⇒ Wordに変換可能 ウォータフォール式文書が報告や納品に必要なら その時エクスポート・変換して作成できる!(普段はTFS画面で見える化) 12
  13. 13. 開発手法・用語と人の役割の違い  アジャイル開発手法をウォーターフォールにも追加可能  単体テスト、テスト駆動開発、カンバン (必要に応じて効率化可能)  完全に対応するものは 用語 の違いに慣れるだけ  人の役割の違い • WBSの作成・設計・実装・テスト・デプロイを違う人がやる • 実質同じ人がやる • チームで適切に分担してやる  どの管理でも予定と実績の比較が必要(チームメンバーの使い方はほぼ同じ) 13
  14. 14. VSTS/TFSをウォーターフォールでも活用できる! この後、具体的に解説・・・  アジャイル・DevOps向けのメニューと用語に慣れる  TFS 簡単入力・リアルタイム見える化、報告時や納品時に文書ファイル化  人の役割に応じて、WorkとTestの使い方を明確にする  アジャイル開発手法を取り入れて、Build や Home を活用する ウォーターフォール + 継続的デリバリー ≒ DevOps だって可能 14
  15. 15. どんなチームでも VSTS/TFSの機能を フル活用して DevOps ができる! 15
  16. 16. Work による工程管理・進捗管理 ウォーターフォールとアジャイルの違いは、いつ誰がタスクを作るか? 16
  17. 17. Workの基本は「その期間に何をするか?」  誰が Assigned To  この期間(週)に Iteration  何を Task  あとどれくらいの時間で Remaining Work  やるか? やっているか? To Do / Doing / Done ( Proposed / Active / Resolved / Closed ) 開発者は自分のタスクを完了させていく 17
  18. 18. イテレーション期間は  進捗報告・確認 ・カイゼンの最小単位  ウォーターフォールなら週次報告 etc...  アジャイル・スクラムならプロダクトをリリースする最小リードタイム  開発者(チームメンバー)は期間中にタスクを完了させる  管理者は期間ごとにレポートを取得し、報告と改善を実施できる  リリース、仕掛の進捗、チームの生産性の実績、EVMの元となる実績値  バーンダウンチャート 18
  19. 19. タスクを誰が作るか?  開発者にとって「自分のタスクを完了させる」のは同じ  そのタスクを誰が・いつ・洗い出して・見積もるか? ウォーターフォールとアジャイル・スクラムでは大きく違う ここに注意すれば、どちらでもうまくWorkを使いこなせる 19
  20. 20. ウォーターフォールのタスクの管理方法(全体) プロジェクトの開始時  WBS(日付なし)階層構造で一覧化した作業項目の一覧 +見積もり工数  スケジュールとリリース (WBSに日付と人を設定) 開発中  毎日 作業を実施して、実績工数・進捗状況 を入力・集計  週次など EVM (予実の比較、CPI・SPIなどインデックス値による評価)  課題の解決・改善(問題の発見が遅れる程、対応は困難) 20
  21. 21. ウォーターフォールのタスクの管理方法(開始時1) WBS(日付なし)階層構造で一覧化した作業項目の一覧 +見積もり工数  Project でタスクの一覧を作成  大分類・中分類・小分類・・とタスクを詳細化していく  親子関係を必ず維持、 WBS番号(1.1.1など)でタスクを識別  過去の実績から、タスクの見積もり工数(時間・日数)を設定 21
  22. 22. ウォーターフォールのタスクの管理方法(開始時2) スケジュールとリリース (WBSに日付と人を設定)  タスクにリソース(作業者)をアサインする  リソースの一日の作業量をみて、 タスクに日付を設定  マイルストーン、クリティカルパスの確認  ガントチャート完成  リソースの単価とタスクの工数から見積もり金額が確定 受託開発の場合、この内容で提案&契約できれば開発開始 22
  23. 23. ウォーターフォールのタスクの管理方法(開発中1) 毎日 作業を実施して、実績工数・進捗状況 を入力・集計  作業者はガントチャートで「今日やるタスク」を確認  自分で一日の作業したタスクと作業時間と記録  作業完了後に Project Server で自分の作業時間を登録  Project Server が無いときは、Excelなどで収集して、 PMがProjectファイルに全員分の進捗を登録する(これがすごく大変) 23
  24. 24. ウォーターフォールのタスクの管理方法(開発中2) 週次など EVM (予実の比較、CPI・SPIなどインデックス値による評価)  ガントチャートのイナズマ線ではタスクごとの遅れを確認  EVMでは全体を数値で把握 日付、PV: 完了しているべきタスクの見積もり工数、EV : 完了している工数、 SPI : 予定より遅いか?早いか?、CPI : 予定より工数がかかっているか?かかっていないか? 課題の解決・改善(問題の発見が遅れる程、対応は困難)  顧客に説明してベースラインの変更(再スケジュール)これは本当にすごく大変  ウォーターフォールでもできるだけ早く問題に気づいて対応したい 24
  25. 25. ウォーターフォールのタスクを VSTS / TFS を使用して 管理するには・・・ 25
  26. 26. ウォーターフォールでは Work をこう使う(開始時1) WBS(日付なし)階層構造で一覧化した作業項目の一覧 +見積もり工数  これまで通りProjectで作成  製品、フェーズ、機能、要件、納品物に注目  WBSを 3階層(タスクなし) or 4階層でTSFにインポート (※違いは後述)  CMMI テンプレートを使用 Epic / Feature / Requirement(Backlog) / Task に対応  親子関係を必ず維持してインポート WBS番号(1.1.1など)もタイトルにつける  4段階の場合 見積もり工数は Task の Remaining Work と Original Estimate に  3段階の場合 見積もり工数は Backlog の Original Estimate に 26
  27. 27. ウォーターフォールでは Work をこう使う(開始時2) スケジュールとリリース (WBSに日付と人を設定)  これまで通りProjectで計画  タスクが、TFSのイテレーション期間のどれにあたるか?  該当するIteration Pathを設定してTFSにインポート  タスクがそのイテレーション期間に表示される  担当者もAssigned Toに設定してインポート Project ファイルをマスタースケジュールとして保管しておく 27
  28. 28. ウォーターフォールでは Work をこう使う(開発中1) 毎日 作業を実施して、実績工数・進捗状況 を入力・集計  作業者は Workで「この期間でやるタスク」を確認  Taskを開始・完了させる  作業したら Completed Workに時間を足して、Remaining Workを減らす  PMの登録作業は不要  誰でもカンバンボードで進捗をリアルタイムに確認 開発者もPMもすごく楽!それでいて、より正確な記録! 28
  29. 29. ウォーターフォールでは Work をこう使う(開発中2) 3段階でインポートしたときは、Task の作成をチームメンバーに任せる  作業者はWorkで「この期間で完成させるバックログ」を確認  バックログを完成させるために必要な全てのタスクを洗い出し、見積もる  Taskを追加  見積もり工数をTask の Remaining Work と Original Estimate に入れる PMはバックログの見積もり工数と、タスクの合計工数を比較してチェック 29
  30. 30. ウォーターフォールでは Work をこう使う(開発中3) TaskをProjectで作成するとちょっとした作業が追加で必要になったときに困る (Project の最小タスクが TFSの Task)  ウォーターフォールでタスクを足すのは変更報告が必要な場合が多い  Projectでタスクを登録しなおして、承認を得て、TFSに再インポート・・・  必ずやらなくなる・やれなくなる TFSにタスクを追加しないで作業する癖がつく、実績と乖離、TFSが使われなくなる Taskをメンバーが追加できる3段階のインポートがお勧め (Projectの最小タスクは、TFSのBacklog)  TFSタスクの追加は、Projectのタスク追加ではない(作業用の詳細化) 30
  31. 31. ウォーターフォールでは Work をこう使う(開発中4) 週次など EVM (予実の比較、CPI・SPIなどインデックス値による評価)  4段階では Task の Original Estimate と Completed Work を比較  3段階では Backlog の Original Estimate と、子 Task のCompleted Workの合計を比較  もとの Project ファイルの実績値に入力(TFSからエクスポートしてコピペ)  ExcelにエクスポートしてPower BIで分析もできる  EVMレポートを作成して進捗会議で報告する 課題の解決・改善(問題の発見が遅れる程、対応は困難)  PMが集計に苦労しないでチームの状況を把握できるのですぐに手を打てる 31
  32. 32. Work をインポート・エクスポートするにはクエリ  方法をスライドで解説 バックログとタスクをインポート・エクスポート Team Foundation Server と Excel・Project との連携 http://www.slideshare.net/shinichikoga355/ss-43464369 32
  33. 33. VSTS/TFS + Power BI で EVMレポートを作成できる VSTS/TFS を使いながらウォーターフォールらしい管理・報告が可能 33
  34. 34. アジャイル・スクラムでは Work をこう使う(1)  事前にバックログに要件・作業を登録  プロダクトオーナーから優先度をつけてやるべきことを挙げておく  期間の最初に「この期間でやるべきバックログ」を決める  過去の実績からバックログに見積もり時間を登録すると、TFSが計算  工数時間ではなく、チーム内で使う相対見積もりの数値  しばらく同じチームで開発すると、1期間にできる数値が分かってくる(ベロシティ)  プロダクトオーナーにバックログを宣言して期間開始 34
  35. 35. アジャイル・スクラムでは Work をこう使う(2)  毎日、チームメンバー全員で、 バックログを完成させるために必要な全てのタスクを洗い出し、見積もる (こちらは工数で良い)  Taskを追加し、見積もり工数をTask の Remaining Work に入れる  Taskを 開始・完了させる  チーム全体でタスク全部を完了できるか?毎日セルフチェックする  期間内に完成させられる工夫をチームで考える(自立した組織)  無理なことは無理と宣言する 35
  36. 36. 期間内に終わらないときはどうするか?  ウォーターフォールではそのまま  以前のIterationの作業であっても、実際に作業したときに Task を完了させる(遅延)  遅れがEVMレポートとして報告される。最終的にどこかで取り返す。  アジャイル・スクラムでは、未完成であっても完了  期間の完了時に、プロダクトオーナーにその期間で完成したものを正確に報告する  終わらなくて続けたいバックログも、 新しい別のバックログとして次の期間以降に作業する  次の期間で、他のバックログと優先度を比較する 36
  37. 37. タスクが足されて見積もりより遅延するんだけど?  チームの事実として受け入れよう  見積もりが甘い  無理なスケジュールをハラスメントで無理やり終わらせていなかったか?  スキルが不足しているメンバーをアサインした?  引継ぎが不足していた?引継ぎのコストをそもそも見積もっていなかった?  これらが顕在化 ・見える化された と理解しよう  例えば「人を足せば早くできるわけじゃない」が明確に見える化されてしまう 正しく見積もって出来ることをしよう!そのうえで工数を下げる工夫を! 37
  38. 38. Test によるシナリオテスト管理 テストケースを作成、テストを実施して、結果を記録する 38
  39. 39. Test は手動テストを扱う コードによる単体テストは Test ではなく、Code に保存して Build で扱う(※後述)  Testでは 手動テストの計画・実行・結果の記録を扱う  最新結果のチャートをHomeに表示して見える化  Test にテスト計画を追加するには Test Manager 拡張機能 ( Visual Studio Enterprise or Test Professional サブスクリプション※ or 支払い ) が必要 ※ユーザーの設定で Basic になっていないか?確認 39
  40. 40. テストケースと結果の管理  タスクが完了させて無くしていく作業  バックログが完成していく成果物・納品物(実際のファイルはCodeに保存)  テストはテストケースの一覧 + 結果の一覧 = 「今、製品は正常か?」の一覧表  必要に応じてテストを実施、再実施して、最新結果の一覧を更新していく 40
  41. 41. 要件ベースのテストスイートを作る  ウォーターフォールV字モデルを思い出してみる 後工程〇〇テストは、前工程□□をテストする・・  Work に登録されているテスト対象の機能や要件の Backlog に対応する テストスイート(テストケースの親)を作れる(一括で作成可能)  テスト計画(テストスイートの親)に 「単体テスト」や「結合テスト」などを作成  開発・修正でどの範囲をテストする・しなおすか?(トレーサビリティ) 41
  42. 42. Grid表示で簡単にテストケースとステップを登録  Excelの表のように一覧で登録できる  テストケース テストステップ アクション(操作) 期待される結果(そうならなかったら失敗とする条件) 42
  43. 43. テスト実行(成功時の流れ)  Webでも、クライアント(Test Manager)でも  テストケースを選んで開始  ステップ(アクションと期待される結果)の一覧画面が表示される  ステップのアクションに従って順に操作  期待される結果通りならステップを成功に  必要に応じてコメントを追加、画像(エビデンス)を添付 (※後述)  全ステップ成功になるとテストケースが成功になる 43
  44. 44. 期待される結果にならなかったら  ステップの結果を失敗にする その時点でテストケースは失敗になる  ステップの結果にコメントを追加 どういう結果か?詳細を記載する  ステップの結果に画像を添付  エビデンスとしてスクリーンキャプチャを保存  Windows標準のスニッピングツール、Light Cutter、OneNoteのツールなど  右クリックメニューからステップの結果に画像を添付できる  間違ってステップ(計画)に添付してしまう人が多いので注意 44
  45. 45. テストが失敗したら  バグを起票する(※後述)  開発作業中のテスト実施の場合にはバグを起票しなくてもいい  バグ起票のルールはチームで決めて、README.mdなどに書いておく  テストケースのステップの間違い・更新が必要でないか?確認  要件ベースのテストスイートなら、WorkとCodeのチェンジセット(※後述)を確認  バックログやタスクを追加して問題を解決する 45
  46. 46. テスト結果チャートをダッシュボードに表示  何パーセントが成功しているか?で、全体として正常かどうか?を判断  Homeに表示すると毎日見える  「壊れた窓効果」にならないように、テストの失敗を放置しない  テスト結果(ケースの結果、ステップの結果とコメント)のTSV形式エクスポートと 添付画像の一括ダウンロードができる Visual Studio 拡張機能あります(納品物の作成に) ※現在作成中でほぼ完成。公開準備が間に合っていないので、すぐに必要ならご連絡ください。 46
  47. 47. Work の Bug によるバグ管理 取り扱いを最初にチームで決めておく 47
  48. 48. バグの扱い方はプロジェクトでルールを決める  イテレーション期間に属する・属さない  表示の仕方を設定で変更できる  ボードのイテレーション期間に表示するかどうか?  表示はバックログと同様か?タスクと同様か?  いつバグを起票するか?(テスト失敗時常に?テストフェーズのみ?)  そのバグをどう解決するか?(次の期間?その期間?期間に関係なし?) 48
  49. 49. Work の Bug と Backlog・Taskの違い  タスク・バックログは予定のイテレーション期間内に完了させることが目的  バグは期間内・あるいは期間に関係なく追加して、完了させることが目的  開発者の使用方法はほぼ同じ  バグに直接時間を入れて完了させてもいい、  バグに関連する別のタスクを追加して完了させてもいい  管理者の集計の仕方が変わるので、チームでどちらかに決めておく必要がある 49
  50. 50. バグ チャートをダッシュボードに表示する  バグがすべて解決されているか?で、全体として正常かどうか?を判断  Homeに表示すると毎日見える  「壊れた窓効果」にならないように、テストの失敗を放置しない  Bug は Work の Backlog や Task 同様、クエリでエクスポートできる  Bug に時間を入れるときは、EVM でBacklog や Task の集計と同等に扱う (クエリを準備するときに Bug がないと忘れがち) 50
  51. 51. Code によるソースバージョン管理 継続的デリバリーのために、改めてルールを見直しておく 51
  52. 52. Work・Testと共にCodeを使用する  ソースバージョン管理  チェックインするときに、タスクに関連付ける(強制もできる)  変更セットとタスクが関連付けられるので、何のための修正なのか?明確  コメントを強制するだけでは、人の努力に依存してしまう。  仕組みでミスできなくする。  Testが失敗したとき、WorkとCodeのチェンジセットから原因をたどれる 52
  53. 53. Build & Release と共にCodeを使用する  ソースを分岐する  「テストと開発を並行で行う時は分岐必須」が常識だが...  DevOps2.0 では チェックイン 即 自動テスト&リリース  これだとメインブランチしか要らない  そうでなければ開発・メイン・自動リリース用のブランチを用意する  メインブランチにマージすると自動的に単体テスト(※後述)  開発とテストが完了して、マージしたら自動的にデプロイ(※後述) 53
  54. 54. Build & Release による継続的デリバリー 自動ビルド・自動テスト・自動デプロイを実現する 54
  55. 55. DevOpsのためにBuild & Releaseを使う  Work・Test をうまく扱える(Dev)前提で、継続的デリバリー(Ops)を実現  ソース管理に保存すると、自動ビルド・自動テストされる状態を保つ  リリースにかかる時間を限りなく0に近づける  問題が発見された時に、前のバージョンに戻すことも自動化された状態を保つ  運用やリリースに関わる課題の解決も全て Work バックログの管理で行う。  プロダクトを継続的に開発 新機能の開発・リリースを2週間程度で繰り返して、競争力を保つ 55
  56. 56. 継続的デリバリーがなければ 早いリリースを 繰り返すことは 不可能 56
  57. 57. いや、ウォータフォールでは そんなに繰り返して リリースすること ないし… 57
  58. 58. ウォータフォールでの継続的デリバリー  開発したらすぐに検証用サーバー・Azure にリリースして動作確認  テストチームにテストを依頼するときに、必ず最新のプログラムにしたい  週次の定例会議で、ちょっとお客様に動きを見てもらいたい(≒アジャイル) V時の最後のリリースだけが継続的デリバリーの対象ではない! 58
  59. 59. 自動テスト(コードによる単体テスト)が前提  C#/Visual Basic 全てのメソッドに単体テストを作成  Codeに保存  DevOpsでは必須  プログラムを書き換えて自分でテストを実行すると、壊れていないか?確認できる  チーム開発で、メインブランチにマージしたときに、壊れていないか?確認できる  単体テストが無ければ、壊れたまま自動リリースされてしまう可能性 あるいは全シナリオテストをやりおなおし必須に 59
  60. 60. 単体テストに求められること  引数と期待される結果の全バターンを網羅的にテスト  メソッドを使う機能や画面のシナリオテストで、パターン網羅は現実的でない  VSTS/TFS で動作する必要がある  SQL Server、SharePoint サーバーなどに接続可能なテスト  あるいは接続しないで実行できる設計(依存性の注入)  Fakes(DateTime.Now を置き換える など)  実行順に依存しない・どの単体テストも単独で実行できること 60
  61. 61. 単体テストが作れる開発の方法  単体テスト出来るアプリの作り方を スライド&サンプルで解説しています 「ちゃんとした C# プログラムを書けるようになる実践的な方法 ~ Visual Studio を使った 高品質・低コスト・保守性の高い開発」 http://www.slideshare.net/shinichikoga355/starting-c-sharp  技術イケメン(経験者)にチームに参加してもらって 一緒に2ヶ月程度開発できるとマスターできるはず! 61
  62. 62. ビルドとリリースをこう使う  ビルド定義で自動ビルド・自動テスト (よりDev側)  どのソースコードをビルドするか?  単体テストを実行するか?  パッケージの作成や検証サーバーなどへのデプロイも可能  リリース定義でビルド後に承認ワークフロー・デプロイ(よりOps側)  承認すると検証⇒ステージング⇒本番 62
  63. 63. まとめ  VSTS / TFS で出来るのはDevOps = ウォータフォール or アジャイル(≒Dev)+ 継続的デリバリー(≒Ops)  ウォーターフォールでは Projectをマスターとして Work / Test を使う  アジャイル・スクラムでは Work / Test をマスターとして使う  Work / Test / Code と単体テストを使いこなしている前提で、 Build & Releaseを使うと継続的デリバリーが実現できる 63
  64. 64. 書籍と勉強会のCM  チーム開発の教科書 http://amzn.to/2euUzrW  はじめてのASP.NET SPA開発入門 http://amzn.to/2eQKaUa  第11回 Plus Programming .net 勉強会 「ASP.NET SPA ビギナー&ステップアップ」2016年12月17日(土) https://atnd.org/events/82659 64
  65. 65. Copyright© 2016 Shin-ichi Koga All Rights Reserved. 65

×