Azure DevOps Tokyo, Japan 2nd impact で登壇しました。その時の発表資料です！ 登壇者 Shuhei Eda Masayuki Ota

1. Shuhei Eda
Masayuki Ota
サイドプロジェクトで使う
Azure DevOps
Azure DevOps Tokyo, Japan 2nd impact

2. おことわり
• 本資料はあくまで登壇時点で公開されている情報をもとに作成した資料
であり、実際の製品の動作とずれがある可能性があります。
• 本資料は正確性を必ずしも保証するものではありません。
• 写真は撮っていただいて OK です! 登壇完了後 SlideShare に公開予定
ですの無理して撮っていただく必要はありません。

3. 今日お話しする内容
レベル : 初級
以下のような方向け
• Azure DevOps で一通り基本的使い方を知りたい方
• スモールなアプリケーションを構築中でパイプラインの選定に悩んでいる方
セッションで得られること
• チーム開発のヒント
• Azure DevOps活用のヒント

4. 自己紹介
Shuhei Eda
Software Engineer
C# .NET/TypeScript
「最近歯科矯正はじめました。」
Masayuki Ota
Software Development Engineer
React, TypeScript, C#, Auth
「テストとXDを始めました」

5. サイドプロジェクト: SecretaryWeb
社内外の人との予定調整を最速で終わらせる Web アプリ

6. Demo
https://secretaryweb.net

7. デモのまとめ
実現できていること
• サインイン済ユーザーの空き時間の候補を取得できる
• イベント作成後はカレンダーに仮押さえされる
今後実現したいこと
• Google カレンダーとも連携 (現在は Office 365 カレンダーのみ)
• 投票者がサインインしている場合に、自動で投票される

8. 技術スタック
Frontend
• Framework : React/Redux
• Language : TypeScript
Backend
• Framework : ASP.NET Core 2.1
• Language : C#

9. 技術スタック
フロント エンド バック エンド
Application (.NET Core)
ASP.NET Core
(API提供)
Authentication builder
(API 保護ミドルウェア)
Single Page Application
React + Redux + TypeScript
(SPA提供)
Office UI Fabric
(UI パーツ)
msal.js
(認証・認可ライブラリ)
開発
チーム
Microsoft Graph
(カレンダー連携)
Azure DevOps
Azure AD
(Token 発行)
Web Apps
(アプリホスト)
Key-vault
(キー管理)
Cosmos DB
(Document DB)
(開発コラボレーション)
Application Insights
(アプリ分析)
Power BI
(ユーザー分析)
Microsoft Teams
(コミュニケーション)

10. 何故 SecretaryWeb を作っているのか
大きな理由
• エンジニアとして流行るプロダクトが欲しかった
• 実際に製品を作ることで技術力を上げたかった
よこしまな理由
• 転職する時に見せられるものが欲しかった (江田)
• 普段の業務で売っている Azure のリアルな知見がほしかった（大田）

11. サイドプロジェクトで発生する課題
• 人が抜けたり入ったりする
• 複数のサービスを使っていると ID 管理が大変
• 基本的にリモート開発
• コストに繊細になる
• 人によって開発環境がバラバラ (Windows/Mac)
• プロジェクトに使える時間は、メンバーの本業状況で変動する
• 無給状態なので、どこまで強いコミットを求めるかが難しい

12. サイドプロジェクトで欲しいもの (DevOps編)
課題 要件
人が抜けたり入ったりする タスク、レポ、CI/CD含め ID は一元管理したい
基本的にリモート開発 クラウドベース
コストに繊細になる 無料が良い
Azure と相性が良い
→まさに DevOps を (低価格で) 実現したい!

13. Using Azure DevOps;

14. 小規模プロジェクトなら無料
1. 5 ユーザーまで無料で開始
2. Azure Pipelines: CI/CD 用の 1 個のホスト ジョブ (1,800 分/月)
3. Azure Repos: 無制限のプライベート Git リポジトリ

15. これは使うしかない!

16. Azure DevOps の機能一覧
Azure Boards
Kanban ボード
が利用可能
Azure Repos
容量無制限の
プライベート Git
レポジトリ
Azure Pipelines
CI/CD のパイプラ
インが構築可能
Azure Test Plans
テストプラン作成、
ロードテスト実行
Azure Artifacts
プライベートな
NuGet Serverが構
築可能

17. サイドプロジェクト内利用している機能はこちら
Azure Boards
Kanban ボード
が利用可能
Azure Repos
容量無制限の
プライベート Git
レポジトリ
Azure Pipelines
CI/CD のパイプラ
インが構築可能

18. 利用している機能
▪ Backlogs
▪製品ビジョン共有
▪優先度共有
▪タグでバージョニング
▪ Sprints
▪作業期間/時間の可視化
▪作業のコミット
▪進捗共有
▪ Queries
▪作業可視化の簡易化
Azure Boards

19. 開発フロー
1. プロダクトデザイン・デモを作って、仲間に共有 (PM)
2. BackLogsに長期ユーザーストーリーを書き出す(PM)
3. ユーザーストーリーをバージョニングする (PM)
4. OKRで6ヶ月間くらいの目標をセット (全員)
5. どのバージョンまで作るか決める(全員)
6. XDでデザイン・フローを可視化する (デザイナー)
7. スプリント会議を２週間に１回して、タスク書き出し・コミット範囲策定(全員)
8. 各自のリズムで開発

20. 大切なこと: 人が大事
• 可視化・思いの共有はしつこいほどやる
• 低コスト・緩い作業で連携する
• 自分たちのリズムにツールを合わせる

21. Demo:
作業風景

22. Azure Repos
利用している機能
• コードのレポジトリとしての基本機能
▪ Files
▪ Commits
▪ Pushes
▪ Branches
• Pull Request 完了後のcherry-pick
• Branch Policy
• Pull Request 作成時のテンプレート

23. Branch Strategy
Git Flow ライクな運用
• master, hotfix, dev, feature ブランチ
• feature の作業が完了したら dev に
Merge. 開発環境への CI/CD が走る
• dev ブランチが master に Merge され
ると本番環境への CI/CD が走る
• 不具合が出た場合は dev から hotfix
ブランチを作成。dev にMerge 後、
master に cherry-pick する。
master
dev
feature
Time
hotfix
Merge
Merge Cherry Pick
Merge
Git Branch 運用図

24. Cherry-pick しやすい UI
dev ブランチへの Pull Request 完了後、同じ変更をすぐに master に反
映できる。
https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow

25. Branch Policy
• ローカルからの dev、master ブラン
チへの Push を禁止
• Pull Request が出たら CI が走る
• CI が Pass しないと Merge 不可
• Work Item を必須
https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=vsts

26. Pull Request 作成時のテンプレート
• Pull Request 時のテンプレートを
自動生成できる。
• “<repositoryroot>/.azuredevo
ps/pull_request_template/bra
nches/<branch name>.md” に
配置すれば、特定の branch への
Pull Request 作成時のみテンプ
レートが作成される。
https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-request-templates?view=vsts

27. Demo:
Bugfix の風景

28. Azure Pipelines
利用している機能一覧
• CI 用のパイプライン
▪ dev ブランチ用
▪ master ブランチ用
• CD 用のパイプライン

29. CI 環境 (dev ブランチ用)
• dev ブランチへの Pull Request が
作成された時点で Kickされる
• Build -> Test 成功で Pass
• Artifact は CD 側には渡さない
• Test では Cosmos DB Emulator
を利用 (後で解説)

30. CI 環境 (master ブランチ用)
• master ブランチへの Pull
Request が merge された時点で
Kickされる
• Build -> Test -> Publish 成功
で Pass
• Artifact は CD 側には渡す
• dev ブランチ用のパイプライン同様
Test では Cosmos DB Emulator
を利用 (後で解説)

31. Azure Cosmos DB Emulator
• 今は、CI に Cosmos DB が組み
込める時代！
• Docker コンテナとして追加される
• 無料(タダ)
https://marketplace.visualstudio.com/items?itemName=azure-cosmosdb.emulator-public-preview

32. .NET Core パイプラインで Cosmos DB
Emulator を動かすにはひと手間必要
はまった点
• Test Project 内から外部の接続先
情報を書く場合 .runsettings に 記
載する。しかし、NET Core は、
.runsettings のオーバライドができな
い。(.NET では可能)
• 公式ドキュメントはあるが、ASP.NET
向けの記事
https://docs.microsoft.com/ja-jp/azure/cosmos-db/tutorial-setup-ci-cd
.NET であれば Test Assemblies 上でお手軽
に .runsettings を書き換えられる。

33. .NET Core パイプラインで Cosmos DB
Emulator を動かすにはひと手間必要
解決策
• パイプライン上で専用の .runsettings ファイルを (強引に) PowerShell で作成
https://blog.spectologic.com/2018/10/02/testing-with-azure-cosmosdb-emulator-in-
azure-devops-ci-cd-pipeline-with-asp-net-core/

34. CD 環境 (Production へのデプロイ)
• master ブランチのパイプラインで生
成された Artifact を受け取る
• Azure App Service の Staging
Slot に展開
• 成功したら Staging と
Production を Swap

35. Demo:
Pipeline

36. まとめ
• ツールは大事だけど、まずは人が大事
• Azure DevOps はサイドプロジェクト等のスモールスタートを切るのに最適
• Azure Board では Kanban が使える
• Azure Repos では、branch policy や、Cherry-Pick、Pull Request テ
ンプレートが利用可能
• Azure Pipelines は、お手軽に CI/CD が回せる

37. Next Action
• フロントエンドのテストをJestで充実させる
• スナップショットテスト (UI テスト)
• TypeScriptで拾えないところを中心にユニットテスト
• フロントエンド・バックエンドのレポジトリ・CI/CDを分割する
• 負荷テストの追加

38. Questions?？