ポンコツエンジニアのAZ-400受験期（後編）

ポンコツエンジニアの
AZ-400 受験記
AZ-400 Azure DevOps Engineer Expert
アプリリリースの自動化編

受験までに行ったこと
⚫ Effective DevOpsの本を購入して読む
→DevOpsとは資格のことではない。
→え？（心を折られずに励む、資格に影響なし）
⚫ Azure DevOpsのセミナーに参加
⚫ Azure DevOpsの自習書を行う
→VSTSの画面との違いに戸惑う
⚫ AKSの自習書を行う
⚫ Microsoft Learn にてコンテナのラーニングパスの実施
自習書は下記のサイトからダウンロードしました。
https://www.microsoft.com/ja-jp/cloud-platform/azure-site-usage

Azure DevOpsのサービス群
⚫Boards :
タスク管理
⚫Repos :
ソースコードの変更管理（Git）
⚫Pipline :
ビルドテスト、デプロイの自動化、リリース管理
⚫Artifacts :
Nuget、NPMなどのパッケージ管理
⚫Test Plans :
ソフトウェアの振る舞いやテスト結果を
見ながらテストを行う探索的テスト機能など
→Basic と Test Plan の2つのライセンス形態
→Load Test は2020年3月31日で廃止

今回の構成
WebAppsの後ろにSQL DBのみある簡易的な構成です。
デプロイスロットを利用してステージング環境を作成しています。
運用環境とステージング環境をWebAppsのホットスワップ機能を用いて環境を
入れ替えるブルーグリーンデプロイメントを行います。
内部のロードバランサーの向き先がステージング環境に変わるだけなのでダウン
タイムはほとんどありません。
運用環境
ステージング環境
(デプロイスロット)
ロードバランサー
(WebApps内に
組み込み)

Azure Pipline（リリースの流れ）
ビルド
テスト
リポジトリ
Artifacts
ステージング
環境
オンプレミス
開発端末
本番環境
マネージドサーバ
でのビルドテスト
⇒冪等性の確保
ソースコードを
Repos(Git)に
プッシュビルド出力の保存
ロードテスト
の実行
ステージング
環境へのデプロイ
ステージング環境
と本番の入替
(※ホットスワップ)
本番リリースの前
に承認フローも
設定しておきます。
※ブルーグリーンデプロイメントとも呼ばれる。
リリースパイプライン

Azure Pipline Releases（1）
AzureBoardsにて登録したリリースパイプライン作成のタスクがSprintsに
入っています。
これから、リリースパイプラインを作成するため「リリース定義の作成」タ
スクをIn Progress（進行中）のステータスに移動させます。
実際には、チーム開発になると思いますので、担当者をアサインすると担当
者も表示されます。
※Effective DevOpsの本では1チームあたりのメンバー数は5人程度までに
留めチームを小さく柔軟なものに保つことを検討する旨が記載されている。

①AzurePiplines配下のReleasesを選択
して「New pipline」をクリックして
Release用のPiplineを作成します。
②テンプレートの選択にて「Azure App
Service deployment with tests and
performance tests」を選択します。

④AzurePiplinesが表示されるのでパイ
プラインの名前を任意の名前（分かり
やすいもの）に変更します。
③Stageの設定画面にて「Stage
name」を入力して閉じます。
⑤Artifactsの右側にある「+Add」をク
リックしてAzurePipline（Builds）で生
成されたパッケージを追加します。
Artifa
cts

⑥リリース定義の作成画面のStaging配
下にある「1job 3 tasks」をクリックし
て設定を確認します。
⑦Deployment Process名
が「Staging」になっていることを確認します。
Run on agentにて、Agent Specificationがvs2017-win2016になっている
ことを確認します。
現在、vs2019はプレビュー中です。
Artifa
cts

⑧Deploy先のApp Serviceとして
WebAppsのステージング環境を指定し
ます。
⑨ WebAppsのステージング環境に
かける負荷を調整します。
今回は仮想ユーザー数25、負荷をか
ける時間を60秒としています。
※ロードテストを毎回行う必要はな
いと思いますので、不要な際は
Control Optionsの「Enabled」の
チェックを外すだけで、この処理は
スキップされます。

⑩今回は詳細なテストを行わないため
Run Testsを選択してRemoveをクリッ
クしてタスクを削除します。
⑪Piplineをクリックしてリリースパ
イプラインの定義画面に戻ります。
⑫Stages横の+Addをクリックして
New stageをクリックします。

⑬テンプレートから「Azure App Service
deployment with slot」を選択します。
⑭「Stage name」を”Production”
にして閉じます。
⑮新しく作成したステー
ジ”Production”の中を設定します。

⑯タスク一覧から「Run on agent」を選択
してAgent Specification が”vs2017 –
win2016”になっていることを確認します。
⑱タスク一覧にある「Manage Azure App
Service - Slot Swap 」にて”App Service
name”、”Source Slot”を確認してPiplineに
戻ります。
⑰タスク一覧にある「Deploy Azure App
Service to Slot」にチェックを入れて削除
します。

⑲”Production”（運用環境）にリリースす
る前に承認フローを追加するため、イナズ
マアイコンをクリックします。
⑳トリガーは、そのままで「Pre-
deployment approvals」をEnableにしま
す。

⑳「Approvers」に承認者を指定します。
㉑作成したリリースパイプラインを保存し
ます。

㉒ビルドパイプラインに戻り、最新のビルド
テスト結果をクリックします。
㉓ビルドテストの結果が” Succeeded”に
なっていることを確認して「Release」を
クリックします。
㉔作成したリリースパイプラインが表示されるので
「Create」をクリックします。

㉕リリースパイプラインの履歴画面が表
示されるので、現在実行中のリリース状
況を確認するため「Release-1」をク
リックします。
㉖ステージング環境へのデプロイ及びテ
スト中の段階であることが分かります。
“In progress”をクリックすると実行中
の詳細を確認することが出来ます。
㉘”Run on agent”が実行中であること
が分かります。

㉙ステージング環境へのデプロイ及びテ
ストが完了したことを確認します。
㉚「Test Plans」から「Load test」を
クリックすると負荷試験の結果を確認す
ることが出来ます。
㉛テスト結果一覧から最新の結果をク
テスト

㉜負荷試験の結果詳細を確認することが
出来ます。
仮想ユーザー25人、1分間の負荷をかけ
た際に平均レスポンスが784.1msであ
ることが分かります。
㉝ステージング環境でのデプロイが成功
し、負荷試験も終わったので、本番環境
へのデプロイ承認依頼メールが担当者に
メール通知されています。
テスト

㉜負荷試験の結果詳細を確認することが
出来ます。
仮想ユーザー25人、1分間の負荷をかけ
た際に平均レスポンスが784.1msであ
ることが分かります。
㉝ステージング環境でのデプロイが成功
し、負荷試験も終わったので、本番環境
へのデプロイ承認依頼メールが担当者に
メール通知されています。

㉞リリースパイプラインの画面にて
「Approve」をクリックします。
㉟必要に応じてコメントを入力して
「Approve」をクリックします。
運用環境へのリリースが開始されます。

㊱リリースパイプラインの画面にて運用環
境へのリリースが進行中であることが分か
ります。”In Progress”をクリックすると途
中経過の詳細を表示出来ます。
㊲運用環境へのリリースが完了したこと
を確認出来ます。
本番環境

㊳運用環境のWeb AppsのURLへアクセス
すると計算アプリがリリースされているこ
とが確認出来ます。
㊴いくつか計算を実行してみます。
この時、結果がDBに保存されます。

㊵VisualStudioを起動して計算結果がDBに格
納されていることを確認します。
事前にワークロードに「Azure開発」をイン
ストールしておく必要があります。
「ツール」-「SQL Server」-「新しいクエ
リ」を選択します。
㊶運用環境のDBを選択して「ユーザー名」、
「パスワード」を入力して「接続」をクリック
します。

㊷運用環境用のDBに先程の計算結果が格納
されていることを確認出来ます。
㊸ステージング環境では、計算を行っていな
いため、ステージング用DBに計算結果が格
納されていることを確認出来ます。

Azure Pipline Build失敗（1）
①ビルドパイプラインにてビルドに失敗して
いることが分かります。
「Test」結果を確認します。
③この時、ビルドに失敗したことを知らせる
メールが通知されます。
②テストの結果をクリックすると詳細が表示
されます。

④「Test」の上部にある「Bug」メニューか
ら”Create bug”を選択してチケットを作成
します。
⑥ 「Test」の結果詳細確認画面にて、
「Work items」を選択する”ID”を確認する
ことが出来ます。
この後のコードの修正時に利用するので、こ
こでバグIDを確認出来ることを覚えておき
ます。
⑤チケットの中にはビルドの結果へのリンク
が追加されます。

⑦「Boards」の画面にて”Backlog
items”を選択すると先程登録したバグ
チケットがあることを確認して、
「・・・」からAdd Taskで修正タスク
を追加します。
⑧バグチケットを” Committed”ス
テータスに移動します。
⑨「Sprints」の画面にて登録したタス
クを”In Progress”ステータスに移動し
ます。
※チーム開発では担当者をアサインす
ると良いと思います。

⑩Visual Studio、VS Codeなどでコ
ミットする際にコメントに半角スペース
を空けて「#42」を付けてコミットしま
す。
※今回はAzure Repos上で行っています。
⑪再度、ビルドテストが自動で行われ、
今回はビルドテストに成功していること
を確認出来ます。

⑫ビルドテストの結果画面に
て”Summary”をクリックすると一番
下に”Linked work items”にて修正時
のタスクへのリンクが張られています。
⑬タスクチケットにはビルドテストへ
の履歴リンクと修正したコミット履歴
が確認出来ます。
また、関連のバグIDを確認することが
出来ます。
これはコミット時にバグIDを入力して
おいたためです。
⑭メールには再ビルドテスト
が行われた際の結果が届いて
います。

備考（1）
「Organization settins」では、ユー
ザーの追加やグループルールなどの設
定を行えます。
Azure DevOpsサービスには「Organization settins」と「Project settings」
の2つがあります。
「 Project settings 」では、各メ
ニューの詳細な設定が出来ます。

備考（2）
「Boards」の”Team configuration”
では、Backlog のメニューレベルや稼
働日の設定が出来ます。
「Boards」の”GitHub connections”
では、GitHubと連携させて、「Azure
Pipline Build失敗」のスライドのよう
なタスク管理を行えます。

新機能
2019年12月28日時点
プレビューにて、「Multi-stage piplines」という機能が提供されており、ビルド
パイプラインとリリースパイプラインが統合されています。
パイプラインを作成時にYAMLを書く必要があります。
参考URL：https://bit.ly/2ZxX9m9
①画面右上の自身のアカウン
トアイコンをクリックして
「・・・」から”User
settings”をクリックします。
②メニューが表示されるので
「Preview features」をク
③「Multi-stage-pipline」
を”ON”にします。

AzureDevOps関連情報
Azure | 知って得する DevOps | 初心者向け 13 [#くらでべ]
https://youtu.be/U_w9qBB5pVU
Azure DevOps
https://www.youtube.com/channel/UC-ikyViYMM69joIAv7dlMsA/featured
Microsoft Blog
https://azure.microsoft.com/ja-jp/blog/topics/devops/

AZ-400 受験記
個人的に感じた利点
・JenkinsやOctopusを導入せずに、CI/CD環境構築が
可能なため楽
・WebAppsと組み合わせると、ブルーグリーン
デプロイメントを容易にしてくれる。
・ブルーグリーンデプロイメントにより、ロールバック
も容易になるのでバグ改修、機能追加が行いやすくなる。
・GitHub、PiplineとBoardの連携でタスクの割り当ても
分かりやすくなる。
合わせてWIP制限の導入も検討すると尚良いと思います。
・認証にはAzureADを利用するので、認証及び権限管理
も行いやすい？
⇒O365などを既に導入していればAzureADが存在
するので導入しやすいと思われます。
デプロイ先はAzure以外も指定出来るので、
リリース管理や認証をAzureに纏めてAWSやGCPと
組み合わせも良いのでは？

AZ-400 受験記
DevOpsを使い始める
Azure Boardを使ってタスク管理やソース管理からだけ
初めてみるのも良いかなと。
個人用Wikiを作ってみるのも、オススメとして紹介され
ました。
今週の個人的ステータス状況
→今日時点

AZ-400 受験記
資格取得を検討、勉強中の方へ
落ちることもありますが、諦めずに頑張りましょう！
資格が全てじゃないことも確かですが、決めた目標だったら、周りの声を無視して頑張りましょう！！
（目指す目標が変わる場合もあります。その時は、そこに向かって頑張りましょう！！
ポンコツなので、どれも1回で合格できてない。（涙）
MindhubでExamRetryのバウチャー購入や問題集の購入も検討しましょう。
※私が受験する際はありませんでしたが、AZ-400の問題集も出てきました。
https://jp.mindhub.com/

AZ-400 受験記
結論と目標
働き方改革の目標の一つである生産性の向上
Azure DevOpsなどのCI/CDツールはエンジニアに
とっての生産性向上ツールになり得る？
その結果として残業時間の削減、コストダウンが図
られる可能性あり？
Azure DevOps or UnityとVS App Center を連携さ
せてモバイルのビルドテストの自動化を出来るよう
になりたい！

AZ-400 受験記
Microsoft Ignite The Tour Osaka
https://www.microsoft.com/ja-jp/ignite-the-tour/osaka
第1回 Microsoft Learn もくもく会 @関西（品川同日開催）
https://mslearn.connpass.com/event/159600/
最後に
Microsoft Learnコレクション Advent Calendar 2019
にAZ-400対策コレクションを纏めております。
https://adventar.org/calendars/4507
2020年1月25日(土)にMicrosoft Learn もくもく会 @関西
（日本マイクロソフト関西支店）にて初開催します。
Microsoft Ignite The Tour Osaka の復習なども兼ねて、
もしよかったら、よろしくお願いします。

自己紹介
・2012年4月 : CCNP
・2012年6月 : モバイルシステム技術検定2級
・2017年10月 : LPIC Level2
・2018年10月 : Microsoft Azure Infrastructure Solutions
・2019年4月 : HTML5 Level2
・2019年10月 : Azure Administrator
・2019年11月 : Azure DevOps Engineer Expert
資格
担当領域
インフラ全般、最近はAzureがメイン
Web Apps、SQL Databaseなど
フリーランスエンジニア
東健太郎（ひがしけんたろう）
・某金融機関様のオフサイトセンター構築
・セキュリティ関連製品の検証～構築
・Active Directory 移行支援（2003中間 ⇒ 2012）
・Azure移行支援（データ移行、VM構築など）
・BtoB WEB系システム更改支援（オンプレ⇒Azure）
主な経験

ポンコツエンジニアのAZ-400受験期（後編）

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie ポンコツエンジニアのAZ-400受験期（後編）

Ähnlich wie ポンコツエンジニアのAZ-400受験期（後編） (20)

Mehr von Kentaro Higashi

Mehr von Kentaro Higashi (9)