解説・参考：
Explanation:
ゲートは、外部サービスからの正常性シグナルの自動収集を可能にし、すべてのシグナルが同時に成功した場合にリリースを促進するか、タイムアウトでデプロイを停止します。通常、ゲートは、インシデント管理、問題管理、変更管理、監視、および外部承認システムに関連して使用されます。
承認とゲートにより、デプロイ パイプラインの開始と完了をさらに制御できます。
リリース パイプラインの各ステージは、デプロイ前およびデプロイ後の条件で構成できます。これには、ユーザーがデプロイを手動で承認または拒否するのを待つことや、特定の条件が検証されるまで他の自動システムでチェックすることが含まれます。
参照: https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates

1 - 拡張子が .ps1 の Desired State Configuration (DSC) 構成ファイルを作成します。
2 - Import-AzureRmAutomationDscConfiguration Azure Powershell コマンドレットを実行します
3 - Start-AzureRmAutomationDscCompilationJob Azure Powershell コマンドレット リファレンスを実行します。
https://docs.microsoft.com/en-us/powershell/module/azurerm.automation/import-azurermautomationdscconfiguration
https://docs.microsoft.com/en-us/powershell/module/azurerm.automation/start-azurermautomationdsccompilationjob
Topic 2、株式会社リトウェア
既存の環境
Litware, Inc. 独立系ソフトウェア ベンダー (ISV) Litware には、本社と 5 つの支社があります。
アプリケーション アーキテクチャ
同社の主なアプリケーションは、V8.NET で記述されたロジックを使用する ASP.NE T Web フォームに基づく単一のモノリシックな退職金管理システムです。アプリケーションのいくつかの新しいセクションは、C# で記述されています。
アプリケーションのバリエーションは、個々の顧客向けに作成されます。現在、アプリケーションのコード ベースには 80 以上のコード ブランチがあります。
アプリケーションは、Microsoft Visual Studio を使用して開発されました。ソース コードは、本社の Team Foundation Server (TFS) に格納されています。ブランチ オフィスは、TFS プロキシ サーバーを使用してソース コードにアクセスします。
アーキテクチャの問題
Litware は、顧客向けの新しいコードの作成に重点を置いています。既存のコードをリファクタリングまたは削除するためのリソースは提供されません。コード ベースの変更には長い時間がかかります。AS の依存関係は、個々の開発者には明らかではありません。
コードのマージ操作には数か月かかることが多く、多くの開発者が関与します。コードのマージにより、見つけて解決するのが難しいバグが頻繁に発生します。
顧客は、退職金管理システムの所有コストが継続的に増加していると報告しています。無関係なコードをマージする必要があるため、小さなコードの変更でもコストがかかります。
要件
変更予定
Litware は、投資計画のための新しいアプリケーション スイートの開発を計画しています。投資計画アプリケーションは、イースティング退職基金管理システムとのわずかな統合のみを必要とします。
投資計画アプリケーション スイートには、1 つの多層 Web アプリケーションと 2 つの iOS モバイル アプリケーションが含まれます。従業員は 1 つのモバイル アプリケーションを使用します。もう 1 つは顧客が使用します。
Litware は、よりアジャイルな開発手法への移行を計画しています。共有コードは、一連のパッケージに抽出されます。
Litware は社内のクラウド変革プロセスを開始しており、適切な場合はいつでもクラウド ベースのサービスを使用する予定です。
Litware は、常に顧客からのバグ レポートを無視するのではなく、障害を検出することでプロアクティブになりたいと考えています。
技術要件
企業の投資計画アプリケーション スイートは、次の技術要件を満たす必要があります。
* ファイアウォールを通過する新しい着信接続を最小限に抑える必要があります。
* Developers という名前のグループのメンバーは、パッケージをインストールできる必要があります。
* すべてのアクセス許可の割り当てには、最小特権の原則を使用する必要があります
* 新しい機能を分離して開発することをサポートする分岐戦略を使用する必要があります。
* チーム リーダーという名前のグループのメンバーは、新しいパッケージを作成し、パッケージ フィードの権限を編集できる必要があります。
* Visual Studio App Center を使用して、モバイル アプリケーションのクラッシュと使用中のデバイス タイプのレポートを一元化する必要があります。
* デフォルトでは、すべての App Center を使用して、モバイル アプリケーションのクラッシュと使用中のデバイス タイプのレポートを一元化する必要があります。
* コードの品質とリリースの品質は非常に重要です。リリース中にアクティブなバグがログに記録されている場合、リリース中に展開をステージ間で進めてはなりません。
* モバイル アプリケーションは、既存の退職金管理システムの株価サービスを呼び出すことができる必要があります。システムがアップグレードされるまで、サービスは HUPS を介した基本認証のみをサポートします。
* テスト サーバーに必要なオペレーティング システムの構成は、毎週変更されます。Azure Automation State Configuration を使用して、サーバーが定期的に作成およびチェックされるときに、各テスト サーバーのオペレーティング システムが同じように構成されていることを確認する必要があります。
現在の技術
テスト サーバーは、最初のデプロイ時には正しく構成されていますが、時間の経過とともに構成のドリフトが発生します。Azure Automation State Configuration は、構成の修正に失敗します。
Azure Automation State Configuration ノードは、次のコマンドを使用して登録されます。

Azure DevOps にインストールされている Azure DevTest Labs タスク拡張機能を使用して、CI/CD のビルドおよびリリース パイプラインを Azure DevTest Labs と簡単に統合できます。この拡張機能は、次の 3 つのタスクをインストールします。
VM を作成する
VM からカスタム イメージを作成する
VM を削除する
このプロセスにより、たとえば、特定のテスト タスクの「ゴールデン イメージ」をすばやく展開し、テストが終了したら削除することが簡単になります。
参考文献:
https://docs.microsoft.com/en-us/azure/lab-services/devtest-lab-integrate-ci-cd-vsts

説明

参照：
https://dev.to/rajikaimal/azure-devops-ci-cd-yaml-pipeline-4glj