Azure DevOps Server 2020 リリース ノート

| Developer Communityシステム要件 | ライセンス条項 | DevOps ブログ | SHA-1 ハッシュ

この記事では、Azure DevOps Serverの最新リリースに関する情報を確認できます。

Azure DevOps Server展開のインストールまたはアップグレードの詳細については、「Azure DevOps Server要件」を参照してください。 Azure DevOps 製品をダウンロードするには、Azure DevOps Serverダウンロード ページを参照してください。

Azure DevOps Server 2020 への直接アップグレードは、Azure DevOps Server 2019 以降または Team Foundation Server 2015 以降でサポートされています。 TFS デプロイが TFS 2010 以前の場合は、Azure DevOps Server 2019 にアップグレードする前に、いくつかの中間手順を実行する必要があります。 詳細については、「オンプレミスでの Azure DevOps のインストールと構成」を参照してください。

---

2019 Azure DevOps Server から Azure DevOps Server 2020 に安全にアップグレードする

Azure DevOps Server 2020 では、プロジェクト レベルの設定に基づいて動作する新しいパイプライン実行 (ビルド) 保持モデルが導入されています。

Azure DevOps Server 2020 では、パイプライン レベルの保持ポリシーに基づいて、ビルドのリテンション期間が異なる方法で処理されます。 特定のポリシー構成では、アップグレード後にパイプラインの実行が削除されます。 手動で保持されているか、リリースによって保持されているパイプラインの実行は、アップグレード後に削除されません。

Azure DevOps Server 2019 から Azure DevOps Server 2020 に安全にアップグレードする方法の詳細については、ブログ記事を参照してください。

Azure DevOps Server 2020 Update 0.2 Patch 6 リリース日: 2023 年 11 月 14 日

Azure DevOps Server 2020 Update 0.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• シェル タスク引数パラメーター検証を有効にするに使用できる文字の一覧を PowerShell タスクで拡張しました。

注意

このパッチの修正プログラムを実装するには、いくつかの手順に従ってタスクを手動で更新する必要があります。

修正プログラムをインストールする

重要

パッチ 4 が 2023 年 9 月 12 日にリリースされた Azure Pipelines エージェントの更新プログラムをリリースしました。 パッチ 4 のリリース ノートで説明されているようにエージェントの更新プログラムをインストールしなかった場合は、パッチ 6 をインストールする前にこれらの更新プログラムをインストールすることをお勧めします。 Patch 4 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

TFX の構成

1. プロジェクト コレクションへのアップロード タスクに関するドキュメントの手順に従って、tfx-cli をインストールしてログインします。

TFX を使用してタスクを更新する

ファイル	Sha-256 ハッシュ
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Tasks20231103.zipをダウンロード して 抽出します。
2. ディレクトリを抽出されたファイルに変更します。
3. 次のコマンドを実行してタスクをアップロードします。

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

パイプラインの要件

新しい動作を使用するには、影響を受けるタスクを使用するパイプラインで変数 AZP_75787_ENABLE_NEW_LOGIC = true を設定する必要があります。

• クラシックの場合:

  パイプラインの変数タブで変数を定義します。

• YAML の例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 リリース日: 2023 年 10 月 10 日

重要

パッチ 4 が 2023 年 9 月 12 日にリリースされた Azure Pipelines エージェントの更新プログラムをリリースしました。 パッチ 4 のリリース ノートで説明されているようにエージェントの更新プログラムをインストールしなかった場合は、パッチ 5 をインストールする前にこれらの更新プログラムをインストールすることをお勧めします。 Patch 4 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

Azure DevOps Server 2020 Update 0.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• パッチ アップグレード マシンで "Analysis Owner" ID が非アクティブ ID と表示されるバグを修正しました。

Azure DevOps Server 2020 Update 0.2 Patch 4 リリース日: 2023 年 9 月 12 日

Azure DevOps Server 2020 Update 0.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• CVE-2023-33136: Azure DevOps Serverリモート コード実行の脆弱性。
• CVE-2023-38155: Azure DevOps Serverと Team Foundation Server の特権の昇格の脆弱性。

重要

テスト環境にパッチをデプロイし、運用環境に修正プログラムを適用する前に、環境のパイプラインが期待どおりに動作することを確認してください。

注意

このパッチの修正プログラムを実装するには、いくつかの手順に従ってエージェントとタスクを手動で更新する必要があります。

修正プログラムをインストールする

1. 2020 Update 0.2 パッチ 4 Azure DevOps Serverダウンロードしてインストールします。

Azure Pipelines エージェントを更新する

1. エージェントのダウンロード元: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. セルフホステッド Windows エージェントのドキュメントに記載されている手順を使用して、エージェントを展開します。  

注意

エージェントがダウングレードされないようにするには、AZP_AGENT_DOWNGRADE_DISABLEDを "true" に設定する必要があります。 Windows では、管理コマンド プロンプトで次のコマンドを使用し、その後に再起動することができます。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX の構成

1. プロジェクト コレクションへのアップロード タスクに関するドキュメントの手順に従って、tfx-cli をインストールしてログインします。

TFX を使用してタスクを更新する

1. Tasks_20230825.zipをダウンロード して 抽出します。
2. ディレクトリを抽出されたファイルに変更します。
3. 次のコマンドを実行してタスクをアップロードします。

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

パイプラインの要件

新しい動作を使用するには、影響を受けるタスクを使用するパイプラインで変数 AZP_75787_ENABLE_NEW_LOGIC = true を設定する必要があります。

• クラシックの場合:

  パイプラインの変数タブで変数を定義します。

• YAML の例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 3 リリース日: 2023 年 8 月 8 日

Azure DevOps Server 2020 Update 0.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• 2018 以前からアップグレードするときにパッケージのプッシュを妨げるバグを修正しました。

Azure DevOps Server 2020 Update 0.2 Patch 2 リリース日: 2023 年 6 月 13 日

Azure DevOps Server 2020 Update 0.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• 2018 以前からアップグレードするときにパッケージのプッシュを妨げるバグを修正しました。

Azure DevOps Server 2020 Update 0.2 Patch 1 リリース日: 2022 年 10 月 18 日

Azure DevOps Server 2020 Update 0.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• 新しく追加された AD ID がセキュリティ ダイアログ ID ピッカーに表示されない問題を解決します。
• Web フック設定の [グループのメンバーによって要求] フィルターに関する問題を修正します。
• パイプラインの組織設定でジョブ承認スコープが [リリースされていないパイプラインの現在のプロジェクトにジョブ承認スコープを制限する] として構成されていた場合の Gated チェックイン ビルド エラーを修正しました。

Azure DevOps Server 2020.0.2 リリース日: 2022 年 5 月 17 日

Azure DevOps Server 2020.0.2 はバグ修正のロールアップです。 Azure DevOps Server 2020.0.2 を直接インストールすることも、Azure DevOps Server 2020 または Team Foundation Server 2013 以降からアップグレードすることもできます。

注意

データ移行ツールは、このリリースから約 3 週間後にAzure DevOps Server 2020.0.2 で使用できるようになります。 インポート用に現在サポートされているバージョンの一覧は、ここで確認できます。

このリリースには、次の修正プログラムが含まれています。

• [次に実行] ボタンを使用してビルド キューをスキップできません。 以前は、プロジェクト コレクション管理者に対してのみ [次に実行] ボタンが有効でした。

• ユーザーの Active Directory アカウントが無効になった後は、すべての個人用アクセス トークンを取り消してください。

Azure DevOps Server 2020.0.1 Patch 9 リリース日: 2022 年 1 月 26 日

Azure DevOps Server 2020.0.1 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

• Email通知は、作業項目で コントロールを@mention使用しているときに送信されませんでした。
• アカウントTF400813切り替えるときのエラーを修正しました。 このエラーは、TFS 2018 から Azure DevOps Server 2020.0.1 にアップグレードされたときに発生しました。
• [プロジェクトの概要] 概要ページの読み込みに失敗する問題を修正しました。
• Active Directory ユーザー同期の機能強化。
• log4j バイナリから jndilookup クラスを削除することにより、Elasticsearch の脆弱性に対処しました。

インストール手順

1. Patch 9 を使用してサーバーをアップグレードします。
2. HKLM:\Software\Elasticsearch\Version でレジストリ値を確認します。 そこにレジストリ値がない場合は、文字列値を追加し、Version を 5.4.1 (Name = Version、Value = 5.4.1) に設定します。
3. readme ファイルに指定されているように更新コマンド PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update を実行します。 次のような警告が返される場合があります: "リモート サーバー に接続できません"。 更新プログラムによって再試行が実行されている場合は、それが完了するまで、ウィンドウを閉じないでください。

注意

Azure DevOps Server と Elasticsearch が異なるマシンにインストールされている場合は、次の手順に従います。

1. Patch 9 を使用してサーバーをアップグレードします。
2. HKLM:\Software\Elasticsearch\Version でレジストリ値を確認します。 そこにレジストリ値がない場合は、文字列値を追加し、Version を 5.4.1 (Name = Version、Value = 5.4.1) に設定します。
3. C:\Program Files\{TFS Version Folder}\Search\zip にある zip という名前のフォルダーの内容を Elasticsearch リモート ファイル フォルダーにコピーします。
4. Elasticsearch サーバー マシンで Configure-TFSSearch.ps1 -Operation update を実行します。

SHA-256 ハッシュ: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 Patch 8 リリース日: 2021 年 12 月 15 日

Azure DevOps Server 2020.0.1 のパッチ 8 には、次の修正プログラムが含まれています。

• カスタム作業項目のレイアウト状態に関するローカライズの問題。
• 電子メール通知テンプレートのローカライズの問題。
• 1 行に同一のリンクが複数ある場合に、コンソール ログが切り捨てられる問題。
• フィールドに対して複数の NOTSAMEAS ルールが定義されている場合の NOTSAMEAS ルールの評価に関する問題。

Azure DevOps Server 2020.0.1 Patch 7 リリース日: 2021 年 10 月 26 日

Azure DevOps Server 2020.0.1 のパッチ 7 には、次の修正プログラムが含まれています。

• 以前は、Azure DevOps Serverは GitHub Enterprise Server への接続のみを作成できました。 このパッチを使用すると、プロジェクト管理者はAzure DevOps Serverと GitHub.com 上のリポジトリ間の接続を作成できます。 この設定は、 GitHub 接続 ページの [プロジェクトの設定] にあります。
• テスト計画ウィジェットに関する問題を解決します。 テスト実行レポートに、結果に正しくないユーザーが表示されていました。
• [プロジェクトの概要] 概要ページの読み込みに失敗する問題を修正しました。
• 製品のアップグレードを確認するために電子メールが送信されない問題を修正します。

Azure DevOps Server 2020.0.1 パッチ 6 リリース日: 2021 年 9 月 14 日

Azure DevOps Server 2020.0.1 のパッチ 6 には、次の修正プログラムが含まれています。

• 成果物のダウンロード/アップロードエラーを修正しました。
• 一貫性のないテスト結果データに関する問題を解決します。

Azure DevOps Server 2020.0.1 Patch 5 リリース日: 2021 年 8 月 10 日

Azure DevOps Server 2020.0.1 のパッチ 5 には、次の修正プログラムが含まれています。

• ビルド定義 UI エラーを修正しました。
• ルート リポジトリの代わりにファイルを表示するように閲覧履歴を変更しました。
• 一部の作業項目の種類の電子メール配信ジョブに関する問題を修正しました。

Azure DevOps Server 2020.0.1 Patch 4 リリース日: 2021 年 6 月 15 日

Azure DevOps Server 2020.0.1 のパッチ 4 には、次の修正プログラムが含まれています。

• データのインポートに関する問題を修正します。 データのインポートには、古いテスト ケースが多数あるお客様に長い時間がかかっていました。 これは、テーブルのサイズ tbl_testCaseReferences を大きくする参照が原因でした。 このパッチでは、データインポートプロセスの高速化に役立つ古いテストケースへの参照を削除しました。

Azure DevOps Server 2020.0.1 Patch 3 リリース日: 2021 年 5 月 11 日

Azure DevOps Server 2020.0.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。

• Microsoft.TeamFoundation.TestManagement.Client を使用する場合、一貫性のないテスト結果データ。

Azure DevOps Server 2020.0.1 をお持ちの場合は、Azure DevOps Server 2020.0.1 Patch 3 をインストールする必要があります。

インストールの確認

• オプション 1: を実行 devops2020.0.1patch3.exe CheckInstalldevops2020.0.1patch3.exe は、上記のリンクからダウンロードされたファイルです。 コマンドの出力には、パッチがインストールされているか、インストールされていないことが示されます。

• オプション 2: ファイルのバージョンを確認します。 [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll Azure DevOps Server 2020.0.1 は既定で にc:\Program Files\Azure DevOps Server 2020インストールされます。 Azure DevOps Server 2020.0.1 Patch 3 をインストールすると、バージョンは 18.170.31228.1 になります。

Azure DevOps Server 2020.0.1 Patch 2 リリース日: 2021 年 4 月 13 日

注意

Azure DevOps Server 2020 を使用している場合は、最初に Azure DevOps Server 2020.0.1 に更新する必要があります。 2020.0.1 に一度、Azure DevOps Server 2020.0.1 Patch 2 をインストールします

Azure DevOps Server 2020.0.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。

• CVE-2021-27067 : 情報の漏えい
• CVE-2021-28459: 特権の昇格

このパッチの修正プログラムを実装するには、一般的な修正プログラムのインストール、AzureResourceGroupDeploymentV2、AzureResourceManagerTemplateDeploymentV3 タスクのインストールについて、以下に示す手順に従う必要があります。

一般的なパッチのインストール

Azure DevOps Server 2020.0.1 をお持ちの場合は、Azure DevOps Server 2020.0.1 Patch 2 をインストールする必要があります。

インストールの確認

• オプション 1: を実行 devops2020.0.1patch2.exe CheckInstalldevops2020.0.1patch2.exe は、上記のリンクからダウンロードされたファイルです。 コマンドの出力には、パッチがインストールされているか、インストールされていないことが示されます。

• オプション 2: ファイルのバージョンを確認します。 [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll Azure DevOps Server 2020.0.1 は既定で にc:\Program Files\Azure DevOps Server 2020インストールされます。 Azure DevOps Server 2020.0.1 Patch 2 をインストールすると、バージョンは 18.170.31123.3 になります。

AzureResourceGroupDeploymentV2 タスクのインストール

注意

以下に説明する手順はすべて、Windows コンピューター上で実行する必要があります。

インストール

1. AzureResourceGroupDeploymentV2.zip パッケージをコンピューター上の新しいフォルダーに展開します。 例: D:\tasks\AzureResourceGroupDeploymentV2。

2. ご利用のコンピューターに合わせて、Node.js 14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

3. 管理者モードでコマンド プロンプトを開き、次のコマンドを実行して tfx-cli をインストールします。

npm install -g tfx-cli

4. "フル アクセス" 特権で個人用アクセス トークンを作成し、それをコピーします。 この個人用アクセス トークンは、tfx login コマンドの実行時に使用されます。

5. コマンド プロンプトから次を実行します。 プロンプトが表示されたら、サービス URL と個人用アクセス トークンを入力します。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 手順 1 で抽出した .zip ファイルのパスを使用します。

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 タスクのインストール

注意

以下に説明する手順はすべて、Windows コンピューター上で実行する必要があります。

インストール

1. AzureResourceManagerTemplateDeploymentV3.zip パッケージをコンピューター上の新しいフォルダーに展開します。 例: D:\tasks\AzureResourceManagerTemplateDeploymentV3。

2. お使いのコンピューター Node.js 必要に応じて、14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

3. 管理者モードでコマンド プロンプトを開き、次のコマンドを実行して tfx-cli をインストールします。

npm install -g tfx-cli

4. "フル アクセス" 特権で個人用アクセス トークンを作成し、それをコピーします。 この個人用アクセス トークンは、tfx login コマンドの実行時に使用されます。

5. コマンド プロンプトから次を実行します。 プロンプトが表示されたら、サービス URL と個人用アクセス トークンを入力します。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 手順 1 で抽出した .zip ファイルのパスを使用します。

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 パッチ 1 リリース日: 2021 年 2 月 9 日

以下を修正するAzure DevOps Server 2020.0.1 用のパッチをリリースしました。 詳細については、ブログ記事を参照してください。

• このDeveloper Communityフィードバック チケットで報告された問題を解決する|[新しいテスト ケース] ボタンが機能しない
• Azure DevOps Server 2020 Patch 2 でリリースされた修正プログラムを含めます。

Azure DevOps Server 2020 Patch 3 リリース日: 2021 年 2 月 9 日

以下を修正するAzure DevOps Server 2020 のパッチをリリースしました。 詳細については、ブログ記事を参照してください。

• このDeveloper Communityフィードバック チケットで報告された問題を解決する|[新しいテスト ケース] ボタンが機能しない

Azure DevOps Server 2020.0.1 リリース日: 2021 年 1 月 19 日

Azure DevOps Server 2020.0.1 はバグ修正のロールアップです。 Azure DevOps Server 2020.0.1 を直接インストールすることも、既存のインストールからアップグレードすることもできます。 アップグレードでサポートされているバージョンは、Azure DevOps Server 2020、Azure DevOps Server 2019、および Team Foundation Server 2012 以降です。

このリリースには、次のバグの修正プログラムが含まれています。

• アップグレード後に Git プロキシが動作しなくなる可能性がある、Azure DevOps Server 2019 からのアップグレードの問題を解決します。
• Azure DevOps Server 2020 にアップグレードするときに、Team Foundation Server 2017 より前の ENU 以外のコレクションに対する System.OutOfMemoryException 例外を修正します。 このDeveloper Community フィードバック チケットで報告された問題を解決します。
• 不足している Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll が原因で発生したサービスエラー。 このDeveloper Community フィードバック チケットで報告された問題を解決します。
• Azure DevOps Server 2020 へのアップグレード中に Analytics で無効な列名エラーが修正されました。 このDeveloper Community フィードバック チケットで報告された問題を解決します。
• テスト ケースの結果にテスト ケースステップを表示するときに XSS を格納しました。
• ポイントの結果データを TCM に移行中のアップグレード 手順の失敗。

Azure DevOps Server 2020 Patch 2 リリース日: 2021 年 1 月 12 日

以下を修正するAzure DevOps Server 2020 のパッチをリリースしました。 詳細については、ブログ記事を参照してください。

• テスト実行の詳細に、OpsHub Migration を使用して移行されたテスト データのテスト ステップの詳細が表示されない
• 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger' の初期化子の例外
• Azure DevOps Server 2020 への移行後すぐに、未削除のビルドが削除されます
• データ プロバイダーの例外を修正する

Azure DevOps Server 2020 パッチ 1 日付: 2020 年 12 月 8 日

以下を修正するAzure DevOps Server 2020 のパッチをリリースしました。 詳細については、ブログ記事を参照してください。

• CVE-2020-17145 : Azure DevOps Server と Team Foundation Services のスプーフィングの脆弱性

Azure DevOps Server 2020 リリース日: 2020 年 10 月 6 日

Azure DevOps Server 2020 はバグ修正のロールアップです。 これには、以前にリリースされた Azure DevOps Server 2020 RC2 のすべての機能が含まれています。

注意

Azure DevOps 2020 Server には、Git Virtual File System (GVFS) で使用されるアセンブリの 1 つをインストールする際に問題があります。

Azure DevOps 2019 (任意のリリース) または Azure DevOps 2020 リリース候補からアップグレードし、以前のリリースと同じディレクトリにインストールする場合、アセンブリ Microsoft.TeamFoundation.Git.dll はインストールされません。 、および <Install Dir>\Tools フォルダーを探 <Install Dir>\Application Tier\TFSJobAgentMicrosoft.TeamFoundation.Git.dll<Install Dir>\Version Control Proxy\Web Services\binして、問題が発生したことを確認できます。 ファイルが見つからない場合は、修復を実行して、見つからないファイルを復元できます。

修復を実行するには、Azure DevOps Serverマシン/VM で にSettings -> Apps & Features移動し、Azure DevOps 2020 Server で修復を実行します。 修復が完了したら、マシン/VM を再起動できます。

Azure DevOps Server 2020 RC2 リリース日: 2020 年 8 月 11 日

Azure DevOps Server 2020 RC2 はバグ修正のロールアップです。 これには、以前にリリースされた Azure DevOps Server 2020 RC1 のすべての機能が含まれています。

Azure DevOps Server 2020 RC1 の再リリース日: 2020 年 7 月 10 日

このDeveloper Communityフィードバック チケットを修正するために、Azure DevOps Server 2020 RC1 を再リリースしました。

以前は、Azure DevOps Server 2019 Update 1.1 から Azure DevOps Server 2020 RC1 にアップグレードした後、Web UI の Repos、Pipelines、Wiki でファイルを表示できませんでした。 ページのこの領域内で予期しないエラーが発生したことを示すエラー メッセージが表示されました。このコンポーネントを再読み込みするか、ページ全体を更新してみてください。 このリリースでは、この問題を修正しました。 詳細については、ブログ記事を参照してください。

Azure DevOps Server 2020 RC1 リリース日: 2020 年 6 月 30 日

Azure DevOps Server 2020 の新機能の概要

Azure DevOps Server 2020 では、多くの新機能が導入されています。 主な特徴:

• マルチステージ パイプライン
• YAML での継続的デプロイ
• Boards のロールアップ バックログを使用して親アイテムの進行状況を追跡する
• タスク ボードに "親作業項目" フィルターを追加し、バックログをスプリントする
• Azure Repos ランディング ページ用の新しい Web UI
• リポジトリ間ブランチ ポリシーの管理
• [新しいテスト 計画] ページ
• コード Wiki ページの豊富な編集
• パイプラインエラーと期間レポート

個々のセクションに移動して、各サービスのすべての新機能を確認することもできます。

• 全般
• Boards
• Repos
• パイプライン
• Test Plans
• アイテム
• Wiki
• レポート

---

全般

Azure DevOps CLI の一般提供

2 月には、Azure CLI 用の Azure DevOps 拡張機能が導入されました。 拡張機能を使用すると、コマンド ラインから Azure DevOps と対話できます。 拡張機能の改善とコマンドの追加に役立ったフィードバックを収集しました。 この拡張機能が一般公開されたことをお知らせします。

Azure DevOps CLI の詳細については、 こちらのドキュメントを参照してください。

発行プロファイルを使用してデプロイ センターから Windows 用 Azure WebApps をデプロイする

これで、プロファイルベースの発行認証を使用して、デプロイ センターから Azure WebApps for Windows をデプロイできます。 発行プロファイルを使用して Azure WebApp for Windows にデプロイするアクセス許可がある場合は、Deployment Center ワークフローでこのプロファイルを使用してパイプラインを設定できます。

Boards

タスク ボードに "親作業項目" フィルターを追加し、バックログをスプリントする

スプリント ボードとスプリント バックログの両方に新しいフィルターを追加しました。 これにより、要件レベルのバックログ項目 (左側の最初の列) を親でフィルター処理できます。 たとえば、次のスクリーン ショットでは、ビューをフィルター処理して、親が "マイ ビッグ 機能" であるユーザー ストーリーのみを表示しています。

エラー処理エクスペリエンスの向上 – バグ/タスクの必須フィールド

これまで、かんばんボードから、ある列から別の列に作業項目を移動した場合、状態変更によってフィールド ルールがトリガーされた場合、カードには赤いエラー メッセージが表示され、作業項目を開いて根本原因を理解する必要がありました。 スプリント 170 では、作業項目自体を開く必要なく、赤いエラー メッセージをクリックしてエラーの詳細を表示できるように、エクスペリエンスが向上しました。

作業項目のライブ リロード

以前は、作業項目を更新し、2 番目のチーム メンバーが同じ作業項目に変更を加えた場合、2 番目のユーザーは変更を失っていました。 これで、両方とも異なるフィールドを編集している限り、作業項目に加えられた変更のライブ更新が表示されます。

コマンド ラインから反復パスとエリア パスを管理する

コマンド ラインから、 コマンドと コマンドを使用して反復パスとaz boards areaエリア パスをaz boards iteration管理できるようになりました。 たとえば、CLI から対話形式でイテレーションパスとエリア パスを設定および管理したり、スクリプトを使用してセットアップ全体を自動化したりできます。 コマンドと構文の詳細については、 こちらのドキュメントを参照してください。

列オプションとしての作業項目の親列

これで、製品バックログまたはスプリント バックログ内のすべての作業項目の親を表示するオプションが追加されました。 この機能を有効にするには、目的のバックログの [列のオプション] に移動し、[ 親 ] 列を追加します。

する

プロジェクトで使用されるプロセスを変更する

チームが行うとおりにツールを変更する必要があります。プロジェクトをすぐに使用できるプロセス テンプレートから、すぐに使用できるその他のプロセスに切り替えることができます。 たとえば、プロジェクトをアジャイルからスクラムに、Basic から Agile に変更できます。 詳細な手順については、 こちらを参照してください。

ユーザー設定フィールドをレイアウトから非表示にする

プロセスをカスタマイズするときに、フォーム レイアウトからユーザー設定フィールドを非表示にできるようになりました。 このフィールドは、クエリと REST API から引き続き使用できます。 これは、他のシステムと統合するときに追加のフィールドを追跡する場合に便利です。

3 つの新しいAzure Boards レポートを使用して、チームの正常性に関する分析情報を取得する

表示できない内容は修正できません。 そのため、作業プロセスの状態と正常性を注意深く把握する必要があります。 これらのレポートを使用すると、Azure Boardsでの最小限の労力で重要なメトリックを簡単に追跡できるようになります。

3 つの新しい対話型レポートは、 バーンダウン、 累積フロー ダイアグラム (CFD) と 速度です。 レポートは、新しい [分析] タブで確認できます。

スプリントバーンダウン、仕事の流れ、チームの速度などのメトリックは、チームの進捗状況を可視化し、次のような質問に答えるのに役立ちます。

• このスプリントにはどのくらいの作業が残っていますか? 私たちはそれを完了するために軌道に乗っていますか?
• 開発プロセスで最も時間がかかっているステップは何ですか? 私たちはそれについて何かを行うことができますか?
• 以前のイテレーションに基づいて、次のスプリントに対してどのくらいの作業を計画する必要がありますか?

注意

ヘッダーに表示されていたグラフは、これらの拡張レポートに置き換えられました。

新しいレポートは完全に対話型であり、ニーズに合わせて調整できます。 新しいレポートは、各ハブの [分析] タブ にあります。

• バーンダウン チャートは Sprints ハブにあります。

  

• CFD レポートと速度レポートには、関連するカードをクリックして、[ボードとバックログ] の [分析] タブからアクセスできます。

  

新しいレポートを使用すると、チームに関するより多くの制御と情報を得ることができます。 次に例をいくつか示します。

• スプリントバーンダウンレポートとベロシティレポートは、作業項目の数または残存作業時間の合計を使用するように設定できます。
• プロジェクトの日付に影響を与えることなく、スプリントバーンダウンの時間枠を調整できます。 そのため、チームが通常、各スプリント計画の最初の日を費やしている場合は、グラフを照合して反映できるようになりました。
• バーンダウン チャートに、週末を示す透かしが表示されるようになりました。
• CFD レポートを使用すると、Design などのボード列を削除して、チームが制御するフローに集中できます。

ここでは、過去 30 日間のストーリー バックログのフローを示す CFD レポートの例を示します。

ベロシティ チャートをすべてのバックログ レベルで追跡できるようになりました。 たとえば、前のグラフが要件のみをサポートする前に、Features と Epics の両方を追加できるようになりました。 フィーチャー バックログの最後の 6 回のイテレーションのベロシティ レポートの例を次に示します。

タスクボード列のカスタマイズ

タスクボードの列をカスタマイズするためのオプションが追加されたことをお知らせします。 列の追加、削除、名前変更、並べ替えができるようになりました。

タスクボードで列を構成するには、[ 列のオプション] に移動します。

のスクリーンショット。

この機能は、Developer Communityからの提案に基づいて優先順位が付けられました。

バックログで完了した子作業項目を表示または非表示に切り替える

多くの場合、バックログを絞り込むときに、完了していない項目のみを表示する必要があります。 これで、完了した子項目をバックログに表示または非表示にすることができます。

トグルがオンの場合は、完了した状態のすべての子項目が表示されます。 トグルがオフの場合、完了状態のすべての子項目はバックログから非表示になります。

作業項目にタグを付けるときに表示される最新のタグ

作業項目にタグを付けると、オートコンプリート オプションに、最近使用したタグのうち最大 5 個が表示されるようになりました。 これにより、作業項目に適切な情報を簡単に追加できます。

グループ メンバーシップの読み取り専用ルールと必須ルール

作業項目ルールを使用すると、作業項目フィールドに特定のアクションを設定して動作を自動化できます。 グループ メンバーシップに基づいて、フィールドを読み取り専用または必須に設定するルールを作成できます。 たとえば、製品所有者に、他のすべてのユーザーに対して読み取り専用にしながら、機能の優先順位を設定できるようにする必要がある場合があります。

システム選択リストの値をカスタマイズする

重大度、アクティビティ、優先度などのシステム選択リスト (理由フィールドを除く) の値をカスタマイズできるようになりました。選択リストのカスタマイズの範囲は、作業項目の種類ごとに同じフィールドに対して異なる値を管理できるように設定されます。

新しい作業項目 URL パラメーター

新しい作業項目 URL パラメーターを使用して、ボードまたはバックログのコンテキストで作業項目へのリンクを共有します。 パラメーター ?workitem=[ID] を URL に追加することで、ボード、バックログ、またはスプリント エクスペリエンスで作業項目ダイアログを開くようになりました。

リンクを共有したユーザーは、リンクを共有したときと同じコンテキストで移動します。

テキスト フィールドでユーザー、作業項目、PR をメンションする

フィードバックを聞くと、コメントだけでなく、作業項目の説明領域 (およびその他の HTML フィールド) にユーザー、作業項目、PR をメンションする機能が必要であると聞きました。 作業項目で他のユーザーと共同作業している場合や、作業項目の説明で PR を強調表示したいが、その情報を追加する方法がなかった場合があります。 これで、作業項目のすべての長いテキスト フィールドにユーザー、作業項目、PR をメンションできるようになりました。

こちらで例を参照できます。

• ユーザーのメンションを使用するには、記号と、メンションするユーザーの名前を入力@します。 @mentions 作業項目フィールドでは、コメントの場合と同様に電子メール通知が生成されます。
• 作業項目のメンションを使用するには、記号の後に # 作業項目 ID またはタイトルを入力します。 #mentions は、2 つの作業項目間にリンクを作成します。
• PR メンションを使用するには、 ! を追加し、その後に PR ID または名前を追加します。

ディスカッション コメントに対する反応

メイン目標の 1 つは、チームの作業項目をより共同作業にすることです。 最近、 Twitter で投票 を行い、作業項目に関するディスカッションで必要なコラボレーション機能を確認しました。 コメントに反応を持ち込むことは投票に勝ったので、私たちはそれらを追加しました! Twitter 投票の結果を次に示します。

任意のコメントにリアクションを追加できます。リアクションを追加するには、コメントの右上隅にあるスマイリー アイコンと、既存のリアクションの横にあるコメントの下部にあるスマイリー アイコンの 2 つの方法があります。 必要に応じて 6 つのリアクションをすべて追加することも、1 つまたは 2 つのみを追加することもできます。 リアクションを削除するには、コメントの下部にあるリアクションをクリックすると削除されます。 以下では、リアクションを追加するエクスペリエンスと、コメント上の反応の外観を確認できます。

Azure Boardsレポートをダッシュボードにピン留めする

Sprint 155 Update には、 CFD レポートと速度レポートの更新バージョンが含まれていました。 これらのレポートは、[ボード] と [バックログ] の [分析] タブで使用できます。 これで、レポートをダッシュボードに直接ピン留めできます。 レポートをピン留めするには、レポートの上にカーソルを合わせ、省略記号 "..." を選択します。メニューの [ ダッシュボードにコピー] を選択します。

Boards のロールアップ バックログを使用して親アイテムの進行状況を追跡する

ロールアップ列には、階層内の数値フィールドまたは子孫項目の進行状況バーや合計が表示されます。 子孫項目は、階層内のすべての子項目に対応します。 製品またはポートフォリオのバックログに 1 つ以上のロールアップ列を追加できます。

たとえば、ここで紹介する作業項目別の進行状況では、終了した子孫項目の割合に基づいて祖先作業項目の進行状況バーが表示されます。 Epics の子孫アイテムには、すべての子フィーチャーとその子またはグランド子の作業項目が含まれます。 フィーチャーの子孫アイテムには、すべての子ユーザー ストーリーとその子作業項目が含まれます。

タスクボードのライブ更新

変更が発生すると、タスクボードが自動的に更新されるようになりました。 他のチーム メンバーがタスクボード上のカードを移動または並べ替える場合、ボードはこれらの変更で自動的に更新されます。 F5 キーを押して最新の変更を確認する必要がなくなりました。

ロールアップ列でのユーザー設定フィールドのサポート

ロールアップは、ユーザー設定フィールドを含む任意のフィールドで実行できるようになりました。 ロールアップ列を追加する場合でも、[クイック] ボックスの一覧から [ロールアップ] 列を選択できますが、すぐに使用できるプロセス テンプレートに含まれていない数値フィールドをロールアップする場合は、次のように独自のフィールドを構成できます。

1. バックログで[列オプション]をクリックします。 次に、パネルで [ロールアップ列の追加] をクリックし 、[カスタム ロールアップの構成] をクリックします。

   

2. 進行状況バーと合計を選択します。
3. 作業項目の種類またはバックログ レベルを選択します (通常、バックログは複数の作業項目の種類を集計します)。
4. 集計の種類を選択します。 作業項目の数 または 合計。 [合計] では、集計するフィールドを選択する必要があります。
5. [OK] ボタンをクリックすると、列オプション パネルに戻り、新しいカスタム列の順序を変更できます。

[OK] をクリックした後は、カスタム列を編集できないことに注意してください。 変更する必要がある場合は、カスタム列を削除し、必要に応じて別の列を追加します。

条件に基づいて作業項目フォームのフィールドを非表示にする新しいルール

作業項目フォームのフィールドを非表示にできるように、継承されたルール エンジンに新しいルールが追加されました。 このルールでは、ユーザー グループのメンバーシップに基づいてフィールドが非表示になります。 たとえば、ユーザーが "製品所有者" グループに属している場合は、開発者固有のフィールドを非表示にすることができます。 詳細については、こちらのドキュメントを参照 してください。

カスタム作業項目の通知設定

自分やチームに関連する作業項目を常に最新の状態に保つのは非常に重要です。 チームが共同作業を行い、プロジェクトを追跡し、すべての適切な関係者が関与することを確認するのに役立ちます。 ただし、さまざまな利害関係者がさまざまな取り組みに対して異なるレベルの投資を行っており、作業項目の状態に従う能力に反映される必要があると考えています。

以前は、作業項目をフォローし、加えられた変更に関する通知を受け取る場合は、作業項目に加えられたすべての変更に関する電子メール通知を受け取っていました。 フィードバックを検討した後、すべての利害関係者に対して作業項目のフォローの柔軟性を高めています。 これで、作業項目の右上隅にある [フォロー ] ボタンの横に新しい設定ボタンが表示されます。 これにより、次のオプションを構成できるポップアップが表示されます。

[ 通知の設定] から、3 つの通知オプションから選択できます。 最初に、完全に登録を解除できます。 次に、完全にサブスクライブして、すべての作業項目の変更に関する通知を受け取ることができます。 最後に、上位の重要な作業項目変更イベントの一部について通知を受け取ることを選択できます。 1 つだけ、または 3 つのオプションすべてを選択できます。 これにより、チーム メンバーは、より高いレベルで作業項目をフォローし、行われるすべての変更に気を取られるのを回避できます。 この機能を使用すると、不要なメールを排除し、手元の重要なタスクに集中できるようになります。

作業項目を配置にリンクする

作業項目フォームで展開コントロールをリリースすることに興奮しています。 このコントロールは、作業項目をリリースにリンクし、作業項目が展開された場所を簡単に追跡できるようにします。 詳細については、こちらのドキュメントを参照 してください。

CSV ファイルから作業項目をインポートする

これまで、CSV ファイルから作業項目をインポートすることは、Excel プラグインの使用に依存していました。 この更新プログラムでは、新しい作業項目をインポートしたり、既存の作業項目を更新したりできるように、Azure Boardsから直接ファースト クラスのインポート エクスペリエンスを提供しています。 詳細については、 こちらのドキュメントを参照してください。

作業項目カードに親フィールドを追加する

作業項目カードの新しいフィールドとして、かんばんボード内で親コンテキストを使用できるようになりました。 カードに [親] フィールドを追加できるようになりました。タグやプレフィックスなどの回避策を使用する必要はありません。

親フィールドをバックログとクエリに追加する

親フィールドは、バックログとクエリ結果を表示するときに使用できるようになりました。 親フィールドを追加するには、 列オプション ビューを使用します。

Repos

pull request のコード カバレッジ メトリックとブランチ ポリシー

pull request (PR) ビュー内の変更に関するコード カバレッジ メトリックを確認できるようになりました。 これにより、自動テストを通じて変更を適切にテストできます。 カバレッジの状態は、PR の概要にコメントとして表示されます。 ファイル diff ビューで変更されたすべてのコード行のカバレッジ情報の詳細を表示できます。

さらに、リポジトリ所有者はコード カバレッジ ポリシーを設定し、テストされていない大きな変更がブランチにマージされるのを防ぐことができます。 必要なカバレッジしきい値は、リポジトリのルートでチェックインされる設定ファイルでazurepipelines-coverage.yml定義できます。また、カバレッジ ポリシーは、Azure Reposの追加サービス機能用にブランチ ポリシーを構成する既存の構成を使用して定義できます。

pull request からコメント通知をフィルター処理する

pull request のコメントは、多くの場合、通知のために多くのノイズを生成する可能性があります。 コメントの有効期間、コメント作成者、削除されたコメント、メンションされたユーザー、pull request 作成者、ターゲット ブランチ、スレッド参加者によってサブスクライブするコメント通知をフィルター処理できるカスタム サブスクリプションが追加されました。 これらの通知サブスクリプションを作成するには、右上隅にあるユーザー アイコンをクリックし 、[ユーザー設定] に移動します。

pull request コメントのサービス フック

リポジトリとターゲット ブランチに基づいて、pull request にコメントのサービス フックを作成できるようになりました。

指定したパターンのファイルをブロックするポリシー

管理者は、ファイルの種類とパスに基づいてコミットがリポジトリにプッシュされないようにポリシーを設定できるようになりました。 ファイル名の検証ポリシーでは、指定されたパターンに一致するプッシュがブロックされます。

キーワードを使用してコミットを使用して作業項目を解決する

修正、修正、修正などのキーワードを使用して、既定のブランチに対するコミットを使用して作業項目を解決できるようになりました。 たとえば、コミット メッセージで "この変更固定 #476" を記述すると、コミットが既定のブランチにプッシュまたはマージされると、作業項目 #476 が完了します。 詳細については、こちらのドキュメントを参照 してください。

自動レビュー担当者の粒度

以前は、pull request にグループ レベルのレビュー担当者を追加するときに、追加されたグループからの承認が 1 つだけ必要でした。 自動レビュー担当者を追加するときに、チームから複数のレビュー担当者が pull request を承認する必要があるポリシーを設定できるようになりました。 さらに、要求者が独自の変更を承認できないようにするポリシーを追加できます。

サービス アカウントベースの認証を使用して AKS に接続する

以前は、AKS デプロイ センターから Azure Pipelines を構成するときに、Azure Resource Manager 接続を使用しました。 この接続は、パイプラインが構成された名前空間だけでなく、クラスター全体にアクセスしていました。 この更新により、パイプラインはサービス アカウントベースの認証を使用してクラスターに接続し、パイプラインに関連付けられている名前空間にのみアクセスできるようにします。

pull request で Markdown ファイルをサイド バイ サイドでプレビュー diff

新しい [プレビュー] ボタンを使用して、マークダウン ファイルの外観の プレビュー を確認できるようになりました。 さらに、[表示] ボタンを選択すると、サイド バイ サイド diffからファイルの完全なコンテンツを確認できます。

手動ビルドのビルド ポリシーの有効期限

ポリシーによって、チームのコード品質と変更管理の基準が適用されます。 以前は、自動ビルドのビルド有効期限ポリシーを設定できました。 ビルドの有効期限ポリシーを手動ビルドに設定できるようになりました。

コミット作成者の電子メールに基づいてコミットをブロックするポリシーを追加する

管理者は、コミット作成者の電子メールが指定されたパターンと一致しないリポジトリにコミットがプッシュされないようにプッシュ ポリシーを設定できるようになりました。

この機能は、同様のエクスペリエンスを提供するために、Developer Communityからの提案に基づいて優先順位が付けられました。 引き続きチケットを開いたままにし、他の種類のプッシュ ポリシーをユーザーに伝えることをお勧めします。

pull request でファイルをレビュー済みとしてマークする

場合によっては、多数のファイルに対する変更を含む pull request を確認する必要があり、既に確認したファイルを追跡することが困難な場合があります。 これで、pull request でファイルをレビュー済みとしてマークできます。

ファイル名の横にあるドロップダウン メニューを使用するか、ポイントしてファイル名をクリックすると、ファイルをレビュー済みとしてマークできます。

注意

この機能は、pull request を確認するときに進行状況を追跡することのみを目的としています。 pull request に対する投票を表すわけではないため、これらのマークはレビュー担当者にのみ表示されます。

この機能は、Developer Communityからの提案に基づいて優先順位が付けられました。

Azure Repos ランディング ページ用の新しい Web UI

Azure Repos内で、最新かつ高速でモバイルに対応した新しいランディング ページを試すことができます。 これらのページは 、[新しいリポジトリ] ランディング ページとして使用できます。 ランディング ページには、pull request の詳細、コミットの詳細、ブランチの比較を除くすべてのページが含まれます。

Web

モバイル

リポジトリ間ブランチ ポリシーの管理

ブランチ ポリシーは、重要なブランチを保護するのに役立つAzure Reposの強力な機能の 1 つです。 プロジェクト レベルでポリシーを設定する機能は REST API に存在しますが、ユーザー インターフェイスはありませんでした。 管理者は、プロジェクト内のすべてのリポジトリで特定のブランチまたは既定のブランチにポリシーを設定できるようになりました。 たとえば、管理者は、プロジェクト内のすべてのリポジトリにわたってすべてのメインブランチに対するすべての pull request に対して 2 つの最小レビュー担当者を要求できます。 ブランチの追加保護機能は、Repos プロジェクトの設定で確認できます。

新しい Web プラットフォーム変換ランディング ページ

Repos ランディング ページのユーザー エクスペリエンスが更新され、モダンで高速でモバイルに対応できるようになりました。 更新されたページの 2 つの例を次に示します。今後の更新では、引き続き他のページを更新します。

Web エクスペリエンス:

モバイル エクスペリエンス:

Kotlin 言語のサポート

ファイル エディターで Kotlin 言語の強調表示がサポートされるようになりました。 強調表示により、Kotlin テキスト ファイルの読みやすさが向上し、エラーをすばやくスキャンしてエラーを検出するのに役立ちます。 この機能は、Developer Communityからの提案に基づいて優先されました。

下書きプル要求のカスタム通知サブスクリプション

pull request からの電子メール通知の数を減らすために、 下書き状態で作成または更新された pull request のカスタム通知サブスクリプションを作成できるようになりました。 下書きプル要求専用のメールを取得したり、下書き pull request からメールを除外したりして、pull request をレビューする準備が整う前にチームに通知を受け取らないようにすることができます。

PR の実行可能性の向上

レビューする pull request が多数ある場合、最初にアクションを実行する場所を理解するのは難しい場合があります。 pull request の操作性を向上させるために、pull request リスト ページに複数のカスタム クエリを作成し、下書き状態などによってフィルター処理するいくつかの新しいオプションを作成できるようになりました。 これらのクエリでは、"Created by me" と "Assigned to me" に加えて、pull request ページに個別の折りたたみ可能なセクションが作成されます。 [投票] メニューまたは pull request リスト ページのコンテキスト メニューを使用して、追加した pull request の確認を拒否することもできます。 カスタム セクションには、レビューを行った、またはレビューを拒否した pull request の個別のタブが表示されます。 これらのカスタム クエリは、コレクション ホーム ページの [My pull requests] タブにあるリポジトリ間で機能します。 pull request に戻りたい場合は、それにフラグを設定すると、リストの一番上に表示されます。 最後に、自動完了に設定されている pull request には、一覧に "オートコンプリート" と表示されるピルが付きます。

Pipelines

マルチステージ パイプライン

パイプラインを管理するために 、更新されたユーザー エクスペリエンス に取り組んでいます。 これらの更新により、パイプラインエクスペリエンスが最新になり、Azure DevOps の方向と一致します。 さらに、これらの更新により、クラシック ビルド パイプラインとマルチステージ YAML パイプラインが 1 つのエクスペリエンスにまとめられます。 これはモバイルに対応しており、パイプラインの管理方法にさまざまな改善をもたらします。 ドリルダウンすると、パイプラインの詳細、実行の詳細、パイプラインの分析、ジョブの詳細、ログなどを表示できます。

新しいエクスペリエンスには、次の機能が含まれています。

• 複数のステージの表示と管理
• パイプラインの実行の承認
• パイプラインがまだ進行中にログに戻ってスクロールする
• パイプラインのブランチごとの正常性。

YAML での継続的デプロイ

Azure Pipelines YAML CD 機能を提供することに興奮しています。 CI、CD、または CI と CD を一緒に実行するように各パイプラインを構成できるように、統合された YAML エクスペリエンスが提供されるようになりました。 YAML CD 機能には、マルチステージ YAML パイプラインを使用するすべてのコレクションで使用できるいくつかの新しい高度な機能が導入されています。 主な特徴:

• マルチステージ YAML パイプライン (CI および CD 用)
• リソースの承認とチェック
• 環境 と デプロイ戦略
• 環境内の Kubernetes リソースと 仮想マシン リソース
• コラボレーションのためにアプリを確認する
• サービス接続の更新された UX
• YAML パイプラインのリソース

ビルドを開始する準備ができたら、マルチステージ CI/CD パイプラインを構築するためのドキュメントまたはブログをチェックします。

YAML エディターでパイプライン変数を管理する

YAML エディターでパイプライン変数を管理するためのエクスペリエンスを更新しました。 YAML パイプラインで変数を追加または更新するために、クラシック エディターに移動する必要がなくなりました。

リリース ハブからリリースを直接承認する

保留中の承認に対する対応が容易になりました。 以前は、リリースの詳細ページからリリースを承認することが可能でした。 リリース ハブから直接リリースを承認できるようになりました。

パイプラインの概要に関する機能強化

開始ウィザードでの一般的な質問は、生成されたファイルの名前を変更する機能でした。 現在、リポジトリのルートに として azure-pipelines.yml チェックインされています。 パイプラインを保存する前に、これを別のファイル名または場所に更新できるようになりました。

最後に、そのブランチからの pull request の作成を azure-pipelines.yml スキップできるため、ファイルを別のブランチにチェックインする際の制御が増えます。

パイプラインをコミットまたは実行せずに、完全に解析された YAML ドキュメントをプレビューする

プレビューは追加 されましたが、 YAML パイプラインのモードは実行しません。 これで、リポジトリにコミットしたり実行したりすることなく、YAML パイプラインを試すことができます。 既存のパイプラインとオプションの新しい YAML ペイロードを指定すると、この新しい API によって完全な YAML パイプラインが返されます。 今後の更新では、この API は新しいエディター機能で使用されます。

開発者の場合: 次のような JSON 本文を使用して に dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview POST します。

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

応答には、レンダリングされた YAML が含まれます。

YAML での Cron スケジュール

以前は、UI エディターを使用して、YAML パイプラインのスケジュールされたトリガーを指定できました。 このリリースでは、YAML ファイルで cron 構文を使用してビルドをスケジュールし、次の利点を活用できます。

1. コードとしての構成: コードの一部として、パイプラインと共にスケジュールを追跡できます。
2. 表現力: UI を使用した場合よりも、スケジュールを定義する際の表現力が高くなります。 たとえば、1 時間ごとに実行を開始する 1 つのスケジュールを指定する方が簡単です。
3. 業界標準: 多くの開発者と管理者は、cron 構文に既に精通しています。

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

また、cron スケジュールに関する問題を簡単に診断できるようにしました。 [パイプラインの実行] メニューの [スケジュールされた実行] には、cron スケジュールでエラーを診断するのに役立つ、パイプラインに対して予定されているいくつかのスケジュールされた実行のプレビューが表示されます。

サービス接続 UI へのUpdates

サービス接続を管理するために、更新されたユーザー エクスペリエンスに取り組んでいます。 これらの更新により、サービス接続エクスペリエンスが最新になり、Azure DevOps の方向と一致します。 今年の初めに、サービス接続用の新しい UI をプレビュー機能として導入しました。 新しいエクスペリエンスを試し、貴重なフィードバックを提供してくださった皆様に感謝します。

ユーザー エクスペリエンスの更新に加えて、YAML パイプラインでサービス接続を使用するために重要な 2 つの機能 (パイプラインの承認と承認とチェック) も追加しました。

この更新プログラムでは、新しいユーザー エクスペリエンス が既定で有効になります 。 プレビューをオプトアウトすることもできます。

注意

新しい機能として、サービス Connectionsのプロジェクト間共有を導入する予定です。 共有エクスペリエンスとセキュリティ ロールの詳細については、 こちらを参照してください。

YAML パイプラインでのステージのスキップ

手動実行を開始するときに、パイプラインのいくつかのステージをスキップすることが必要な場合があります。 たとえば、運用環境にデプロイしない場合や、運用環境のいくつかの環境へのデプロイをスキップする場合などです。 これで、YAML パイプラインでこれを行うことができます。

更新された実行パイプライン パネルには、YAML ファイルからステージの一覧が表示され、これらのステージを 1 つ以上スキップするオプションがあります。 ステージをスキップする場合は注意が必要です。 たとえば、最初のステージで後続のステージに必要な特定の成果物が生成される場合、最初のステージをスキップしないでください。 ダウンストリーム依存関係を持つステージをスキップするたびに、実行パネルに一般的な警告が表示されます。 これらの依存関係が実際の成果物の依存関係であるかどうか、またはデプロイのシーケンス処理にだけ存在するかどうかは、ユーザーに任されます。

ステージをスキップすることは、ステージ間の依存関係を再調整することと同じです。 スキップされたステージの即時ダウンストリーム依存関係は、スキップされたステージの上流の親に依存するように行われます。 実行が失敗し、失敗したステージを再実行しようとすると、その試行も同じスキップ動作になります。 スキップするステージを変更するには、新しい実行を開始する必要があります。

既定のエクスペリエンスとしてのサービス接続の新しい UI

新しいサービス接続 UI があります。 この新しい UI は、最新の設計標準に基づいて構築されており、承認、承認、プロジェクト間共有などの複数ステージの YAML CD パイプラインをサポートするためのさまざまな重要な機能が付属しています。

サービス接続の詳細については、こちらを参照してください。

実行の作成ダイアログのパイプライン リソース バージョン ピッカー

実行の作成ダイアログでパイプライン リソースのバージョンを手動で取得する機能が追加されました。 パイプラインを別の パイプラインのリソースとして 使用する場合は、実行の作成時にそのパイプラインのバージョンを選択できるようになりました。

az Azure Pipelines の CLI の機能強化

パイプライン変数グループと変数管理コマンド

パイプライン変数と変数グループを手動で設定する必要があるため、YAML ベースのパイプラインを 1 つのプロジェクトから別のプロジェクトに移植するのは困難な場合があります。 ただし、パイプライン 変数グループ と 変数 管理コマンドを使用すると、パイプライン変数と変数グループの設定と管理をスクリプト化できるようになりました。これにより、あるプロジェクトから別のプロジェクトにパイプラインを移動および設定する手順を簡単に共有できます。

PR ブランチのパイプラインを実行する

PR を作成するときに、変更によってターゲット ブランチでのパイプラインの実行が中断される可能性があるかどうかを検証するのは困難な場合があります。 ただし、PR ブランチのビルドをパイプライン実行またはキューに入れる機能を使用して、ターゲット パイプラインに対して実行することで、変更を検証して視覚化できるようになりました。 詳細については、 az pipelines run と az pipelines build queue コマンドのドキュメントを参照してください。

最初のパイプライン実行をスキップする

パイプラインを作成するときに、YAML ファイルを作成してコミットし、パイプラインの実行をトリガーしないことが必要な場合があります。これは、さまざまな理由で実行が失敗する可能性があるためです。インフラストラクチャの準備ができていないか、変数/変数グループを作成および更新する必要があります。Azure DevOps CLI を使用すると、--skip-first-run パラメーターを含めることで、パイプラインの作成時に最初の自動パイプライン実行をスキップできるようになりました。 詳細については、 az pipeline create コマンドのドキュメント を参照してください。

サービス エンドポイント コマンドの機能強化

サービス エンドポイント CLI コマンドでは、azure rm と github サービス エンドポイントの設定と管理のみがサポートされています。 ただし、このリリースでは、サービス エンドポイント コマンドを使用すると、ファイルを介して構成を指定して任意のサービス エンドポイントを作成でき、最適化されたコマンド (az devops service-endpoint github と az devops service-endpoint azurerm) が提供されます。このコマンドは、これらの種類のサービス エンドポイントを作成するための最初のクラスのサポートを提供します。 詳細については、 コマンドのドキュメント を参照してください。

デプロイ ジョブ

デプロイ ジョブは、アプリを環境にデプロイするために使用される特殊な種類の ジョブ です。 この更新プログラムでは、デプロイ ジョブでの ステップ参照 のサポートが追加されました。 たとえば、1 つのファイルに一連の手順を定義し、デプロイ ジョブで参照できます。

また、デプロイ ジョブに追加のプロパティのサポートも追加しました。 たとえば、現在設定できるデプロイ ジョブのプロパティをいくつか次に示します。

• timeoutInMinutes - 自動的に取り消されるまでのジョブの実行時間
• cancelTimeoutInMinutes - タスクを終了する前に、"取り消されたタスクでも常に実行する" 時間
• condition - ジョブを条件付きで実行する
• variables - ハードコーディングされた値は、Azure キー コンテナーによってサポートされる変数グループを直接追加することも、変数グループを参照することも、ファイルで定義されている一連の変数を参照することもできます。
• continueOnError - このデプロイ ジョブが失敗した場合でも、将来ジョブを実行する必要がある場合。既定値は 'false' です

デプロイ ジョブと、デプロイ ジョブを指定するための完全な構文の詳細については、「 デプロイ ジョブ」を参照してください。

CI パイプラインに関連する CD パイプライン情報を表示する

CI パイプラインがパイプライン リソースと呼ばれる CD YAML パイプラインの詳細にサポートを追加しました。 CI パイプラインの実行ビューに、新しい [関連付けられたパイプライン] タブが表示されます。このタブには、パイプラインと成果物を使用するすべてのパイプライン実行が表示されます。

YAML パイプラインでの GitHub パッケージのサポート

最近、YAML パイプラインのリソースとして GitHub から NuGet パッケージと npm パッケージを使用するためのサポートを追加する packages という新しいリソースの種類が導入されました。 このリソースの一部として、GitHub から使用するパッケージの種類 (NuGet または npm) を指定できるようになりました。 新しいパッケージ バージョンのリリース時に、自動化されたパイプライン トリガーを有効にすることもできます。 現在、サポートは GitHub からのパッケージを使用する場合にのみ利用できますが、今後は、 NuGet、 npm、 AzureArtifacts などの他のパッケージ リポジトリからパッケージを使用するようにサポートを拡張する予定です。 詳細については、以下の例を参照してください。

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

注意

現在、GitHub パッケージでは PAT ベースの認証のみがサポートされています。つまり、パッケージ リソース内の GitHub サービス接続は PAT 型である必要があります。 この制限が解除されると、他の種類の認証のサポートが提供されます。

既定では、パッケージはジョブに自動的にダウンロードされないため、リソースで定義されているパッケージを使用できる getPackage マクロが導入されました。 詳細については、以下の例を参照してください。

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Kubernetes 環境リソース ビューでのクラスター リンクのAzure Kubernetes Service

対応するクラスターの Azure ブレードに移動できるように、Kubernetes 環境のリソース ビューへのリンクを追加しました。 これは、Azure Kubernetes Service クラスター内の名前空間にマップされている環境に適用されます。

通知サブスクリプションのフォルダー フィルターを解放する

フォルダーを使用すると、見つけやすさとセキュリティ制御を容易にするためにパイプラインを整理できます。 多くの場合、フォルダーの下にあるすべてのパイプラインによって表される、すべてのリリース パイプラインに対してカスタム電子メール通知を構成することが必要になる場合があります。 以前は、複数のサブスクリプションを構成するか、サブスクリプションで複雑なクエリを実行して、優先メールを取得する必要がありました。 この更新プログラムを使用すると、リリース フォルダー句を デプロイ完了 イベントと 承認保留中 イベントに追加し、サブスクリプションを簡略化できるようになりました。

複数ステージの YAML パイプラインを使用して作業項目をリンクする

現時点では、作業項目をクラシック ビルドと自動的にリンクできます。 ただし、これは YAML パイプラインでは不可能でした。 この更新プログラムでは、このギャップに対処しました。 指定したブランチのコードを使用してパイプラインを正常に実行すると、Azure Pipelines によって、すべての作業項目 (そのコード内のコミットによって推論される) に実行が自動的に関連付けられます。 作業項目を開くと、その作業項目のコードがビルドされた実行を確認できます。 これを構成するには、パイプラインの設定パネルを使用します。

複数ステージの YAML パイプライン実行でステージを取り消す

マルチステージ YAML パイプラインを実行するときに、ステージの実行中にステージの実行を取り消すようになりました。 これは、ステージが失敗することがわかっている場合や、開始する別の実行がある場合に役立ちます。

失敗したステージを再試行する

マルチステージ パイプラインで最も要求される機能の 1 つは、最初から開始しなくても失敗したステージを再試行できることです。 この更新プログラムでは、この機能の大部分を追加しています。

実行が失敗したときにパイプライン ステージを再試行できるようになりました。 最初の試行で失敗したジョブと、失敗したジョブに推移的に依存するジョブはすべて再試行されます。

これは、いくつかの方法で時間を節約するのに役立ちます。 たとえば、1 つのステージで複数のジョブを実行する場合、各ステージで異なるプラットフォームでテストを実行できます。 1 つのプラットフォームでテストが失敗し、他のプラットフォームで合格した場合は、合格したジョブを再実行しないことで時間を節約できます。 別の例として、ネットワーク接続が不安定なため、デプロイ ステージが失敗した可能性があります。 このステージを再試行すると、別のビルドを生成しなくても時間を節約できます。

この機能には、いくつかの既知のギャップがあります。 たとえば、明示的に取り消したステージを再試行することはできません。 今後の更新プログラムでは、これらのギャップを埋めるために取り組んでいます。

マルチステージ YAML パイプラインでの承認

YAML CD パイプラインには手動承認が含まれている場合があります。 インフラストラクチャ所有者は、環境を保護し、パイプラインデプロイのステージの前に手動承認を求めることができます。 インフラストラクチャ (環境) とアプリケーション (パイプライン) の所有者の間でロールを完全に分離することで、特定のパイプラインでのデプロイに対する手動サインオフを確保し、すべてのデプロイで同じチェックを環境に適用する際に集中管理できます。

開発にデプロイするパイプラインの実行は、ステージの開始時に承認のために停止します。

ゲートのタイムアウト制限と頻度の増加

以前は、リリース パイプラインのゲート タイムアウト制限は 3 日間でした。 この更新プログラムでは、期間が長いゲートを許可するために、タイムアウト制限が 15 日 に引き上げされました。 また、ゲートの周波数を 30分に増やしました。

Dockerfile 用の新しいビルド イメージ テンプレート

以前は、新しいパイプラインの作成で Dockerfile 用の新しいパイプラインを作成する場合、テンプレートはイメージをAzure Container Registryにプッシュし、Azure Kubernetes Serviceにデプロイすることをお勧めします。 コンテナー レジストリにプッシュする必要なく、エージェントを使用してイメージをビルドできるように、新しいテンプレートを追加しました。

Azure App Service アプリ設定を構成するための新しいタスク

Azure App Serviceでは、アプリの設定、接続文字列、その他の一般的な構成設定など、さまざまな設定を使用して構成できます。 これで、Web アプリまたはそのデプロイ スロットの JSON 構文を使用してこれらの設定を一括で構成できる[設定] Azure App Service新しい Azure Pipelines タスクが作成されました。 このタスクは、他の App Service タスクと共に使用して、Web アプリ、関数アプリ、またはその他のコンテナー化された App Services を デプロイ、 管理 、構成できます。

Azure App Serviceでプレビューとのスワップがサポートされるようになりました

Azure App Serviceでは、デプロイ スロットでプレビューとのスワップがサポートされるようになりました。 これは、アプリが実際にステージング スロットから運用スロットにスワップされる前に、運用構成でアプリを検証する良い方法です。 これにより、ターゲット/運用スロットにダウンタイムが発生しないようにすることもできます。

Azure App Service タスクでは、次の新しいアクションを通じてこのマルチフェーズ スワップがサポートされるようになりました。

• プレビューでスワップを開始 する - プレビュー (マルチフェーズ スワップ) を使用してスワップを開始し、ターゲット スロット (運用スロットなど) の構成をソース スロットに適用します。
• [プレビューでスワップを完了 する] - 保留中のスワップを完了する準備ができたら、[プレビューでスワップを完了する] アクションを選択します。
• [プレビューでスワップを取り消す ] - 保留中のスワップを取り消すには、[プレビューでスワップを取り消す] を選択します。

Azure Container RegistryおよびDocker Hub成果物のステージ レベル フィルター

以前は、Azure Container RegistryおよびDocker Hub成果物の正規表現フィルターは、リリース パイプライン レベルでのみ使用できます。 ステージ レベルでも追加されました。

YAML パイプラインでの承認の機能強化

サービス接続とエージェント プールに対する承認の構成を有効にしました。 承認のために、インフラストラクチャ所有者と開発者の間の役割の分離に従います。 環境、サービス接続、エージェント プールなどのリソースに対する承認を構成することで、リソースを使用するすべてのパイプライン実行で最初に承認が必要であることが保証されます。

このエクスペリエンスは、環境の承認の構成と似ています。 ステージで参照されているリソースで承認が保留中の場合、パイプラインの実行はパイプラインが手動で承認されるまで待機します。

Azure Pipelines でのコンテナー構造テストのサポート

アプリケーションでのコンテナーの使用が増加しているため、堅牢なテストと検証の必要性が高まっています。 Azure Pipelines では、 コンテナー構造テストのサポートが提供されるようになりました。 このフレームワークは、コンテナーの内容と構造を検証するための便利で強力な方法を提供します。

コマンド テスト、ファイル存在テスト、ファイル コンテンツ テスト、メタデータ テストという 4 つのカテゴリのテストに基づいて、イメージの構造を検証できます。 パイプラインの結果を使用して、go/no go の決定を行うことができます。 テスト データは、エラーのトラブルシューティングを改善するために、エラー メッセージと共にパイプライン実行で使用できます。

構成ファイルとイメージの詳細を入力する

テスト データと概要

リリース パイプラインのパイプライン デコレーター

パイプライン デコレーターを使用すると、すべてのジョブの開始と終了にステップを追加できます。 これは、コレクション内のすべてのパイプラインに適用されるため、1 つの定義にステップを追加する場合とは異なります。

ビルドと YAML パイプラインのデコレーターをサポートしており、お客様はそれらを使用してジョブのステップを一元的に制御しています。 現在、パイプラインもリリースするようにサポートを拡張しています。 拡張機能を作成して、新しいコントリビューション ポイントを対象とするステップを追加すると、リリース パイプライン内のすべてのエージェント ジョブに追加されます。

Azure Resource Manager (ARM) をサブスクリプションおよび管理グループ レベルにデプロイする

以前は、リソース グループ レベルへのデプロイのみをサポートしました。 この更新プログラムでは、ARM テンプレートをサブスクリプション レベルと管理グループ レベルの両方にデプロイするためのサポートが追加されました。 これは、一連のリソースを一緒にデプロイするが、異なるリソース グループまたはサブスクリプションに配置する場合に役立ちます。 たとえば、Azure Site Recoveryのバックアップ仮想マシンを別のリソース グループと場所にデプロイします。

マルチステージ YAML パイプラインの CD 機能

CI パイプラインによって発行された成果物を使用し、パイプライン完了トリガーを有効にできるようになりました。 マルチステージ YAML パイプラインでは、リソースとして を導入しています pipelines 。 YAML では、別のパイプラインを参照し、CD トリガーも有効にできるようになりました。

パイプライン リソースの詳細な YAML スキーマを次に示します。

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

さらに、 タスクを使用して、パイプライン リソースによって発行された成果物を - download ダウンロードできます。

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

詳細については、成果物のダウンロードに関するドキュメント を参照してください。

Kubernetes の環境でカナリアデプロイ戦略を調整する

アプリケーション更新プログラムの継続的デリバリーの主な利点の 1 つは、特定のマイクロサービスの運用環境に更新プログラムをすばやくプッシュできることです。 これにより、ビジネス要件の変化に迅速に対応できます。 環境 は、デプロイ戦略のオーケストレーションを可能にし、ダウンタイムゼロのリリースを容易にする、ファースト クラスの概念として導入されました。 以前は、手順を順番に 1 回実行する runOnce 戦略をサポートしました。 マルチステージ パイプラインでのカナリア戦略のサポートにより、変更を小さなサブセットに徐々にロールアウトすることでリスクを軽減できるようになりました。 新しいバージョンに対する信頼度が高まるにつれて、インフラストラクチャ内のより多くのサーバーへのロールアウトを開始し、より多くのユーザーをそれにルーティングできます。

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kuberenetes のカナリア戦略では、 postRouteTraffic 中に正常性を監視しながら、最初に 10% のポッドで変更をデプロイし、その後に 20% をデプロイします。 すべてがうまくいけば、100%に昇格します。

環境での VM リソースのサポートと、複数のマシン間でのローリング デプロイ戦略の実行に関する早期のフィードバックを求めています。 登録については、お問い合わせください 。

YAML パイプラインの承認ポリシー

YAML パイプラインでは、リソース所有者が制御する承認構成に従います。 リソース所有者は、リソースの承認を構成し、リソースを使用するステージの開始前に、承認のためにリソースの一時停止を使用するすべてのパイプラインを構成します。 SOX ベースのアプリケーション所有者は、展開の要求者が独自のデプロイを承認できないように制限するのが一般的です。

高度な承認オプションを使用して、要求者が承認しない、ユーザーのサブセットからの承認を要求する、承認タイムアウトなどの承認ポリシーを構成できるようになりました。

ファースト クラスのパイプライン リソースとしての ACR

パイプラインの一部として ACR (Azure Container Registry) に発行されたコンテナー イメージを使用し、新しいイメージが発行されるたびにパイプラインをトリガーする必要がある場合は、ACR コンテナー リソースを使用できます。

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

さらに、定義済みの変数を使用して、ACR イメージのメタデータにアクセスできます。 次の一覧には、パイプラインで ACR コンテナー リソースを定義するために使用できる ACR 変数が含まれています。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

パイプラインで成果物チェック ポリシーを評価するための機能強化

評価成果物のチェックを強化して、すぐに使用できるポリシー定義の一覧からポリシーを追加しやすくしました。 ポリシー定義が自動的に生成され、必要に応じて更新できるチェック構成に追加されます。

デプロイ ジョブでの出力変数のサポート

これで、デプロイ ジョブの ライフサイクル フック で出力変数を定義し、同じステージ内の他のダウンストリーム ステップとジョブで使用できるようになりました。

デプロイ戦略の実行中に、次の構文を使用してジョブ間で出力変数にアクセスできます。

• runOnce 戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• カナリア戦略の場合: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• ローリング戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

マルチジョブ出力変数を設定する方法の詳細

重要な変更のロールバックを回避する

クラシック リリース パイプラインでは、通常の更新にスケジュールされたデプロイに依存するのが一般的です。 ただし、重要な修正プログラムがある場合は、帯域外での手動デプロイを開始することを選択できます。 その場合、古いリリースは引き続きスケジュールされた状態を維持します。 これは、スケジュールに従ってデプロイが再開されたときに手動デプロイがロールバックされるため、課題を引き起こしました。 多くのユーザーがこの問題を報告し、修正しました。 この修正により、手動でデプロイを開始すると、以前にスケジュールされた環境へのデプロイがすべて取り消されます。 これは、キュー オプションが [最新のデプロイと他のユーザーの取り消し] として選択されている場合にのみ適用されます。

YAML パイプラインでのリソース承認の簡素化

リソースとは、パイプラインの外部にあるパイプラインで使用されるあらゆるものです。 リソースを使用できるようにするには、その前にそれを承認する必要があります。 以前は、YAML パイプラインで未承認のリソースを使用すると、リソース承認エラーで失敗しました。 失敗した実行の概要ページからリソースを承認する必要がありました。 さらに、承認されていないリソースを参照する変数を使用していた場合、パイプラインは失敗しました。

リソース承認の管理が容易になりました。 実行は、実行に失敗するのではなく、リソースを使用するステージの開始時にリソースに対するアクセス許可を待機します。 リソース所有者は、パイプラインを表示し、[セキュリティ] ページからリソースを承認できます。

成果物のチェックを評価する

一連のポリシーを定義し、コンテナー イメージ成果物の環境でポリシー評価をチェックとして追加できるようになりました。 パイプラインを実行すると、環境を使用するステージを開始する前に実行が一時停止します。 指定されたポリシーは、デプロイされるイメージの使用可能なメタデータに対して評価されます。 チェックは、ポリシーが成功したときに成功し、チェックが失敗した場合にステージを失敗としてマークします。

ARM テンプレートのデプロイ タスクにUpdatesする

以前は、ARM テンプレートのデプロイ タスクでサービス接続をフィルター処理しませんでした。 これにより、より広範なスコープへの ARM テンプレートのデプロイを実行するために、より低いスコープのサービス接続を選択すると、デプロイが失敗する可能性があります。 ここで、選択したデプロイ スコープに基づいて、より低いスコープのサービス接続を除外するサービス接続のフィルター処理を追加しました。

環境での ReviewApp

ReviewApp は、Git リポジトリから動的な環境リソースにすべての pull request をデプロイします。 レビュー担当者は、メイン ブランチにマージして運用環境にデプロイする前に、それらの変更がどのように見えるかを確認したり、他の依存サービスと連携したりできます。 これにより、 reviewApp リソースを簡単に作成および管理でき、環境機能のすべての追跡可能性と診断機能の恩恵を受けることができます。 reviewApp キーワード (keyword)を使用すると、リソースの複製を作成し (環境内の既存のリソースに基づいて新しいリソースを動的に作成する)、新しいリソースを環境に追加できます。

環境で reviewApp を使用するサンプル YAML スニペットを次に示します。

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

パイプラインから自動およびユーザー指定のメタデータを収集する

パイプライン タスクから、自動およびユーザー指定のメタデータ収集を有効にできるようになりました。 メタデータを使用して、評価成果物チェックを使用して、環境に成果物ポリシーを適用できます。

環境を使用した VM のデプロイ

環境で最も要求された機能の 1 つは、VM のデプロイです。 この更新プログラムでは、環境で仮想マシン リソースを有効にします。 複数のマシン間でデプロイを調整し、YAML パイプラインを使用して ローリング 更新を実行できるようになりました。 また、各ターゲット サーバーにエージェントを直接インストールし、それらのサーバーへのローリング デプロイを推進することもできます。 さらに、ターゲット マシンで完全なタスク カタログを使用することもできます。

ローリング デプロイは、アプリケーションの以前のバージョンのインスタンスを、各イテレーションの一連のマシン (ローリング セット) 上の新しいバージョンのアプリケーションのインスタンスに置き換えます。

たとえば、次のローリング デプロイでは、各イテレーションで最大 5 つのターゲットが更新されます。 maxParallel は、並列にデプロイできるターゲットの数を決定します。 選択は、デプロイ先のターゲットを除き、いつでも使用可能な状態を維持する必要があるターゲットの数を考慮します。 それはまた、デプロイの間に成功と失敗の条件を判断するためにも使用されます。

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

注意

この更新プログラムでは、現在のパイプラインと関連するパイプライン リソースから使用可能なすべての成果物は、ライフサイクル フックでのみ deploy ダウンロードされます。 ただし、[パイプライン成果物のダウンロード] タスクを指定して 、ダウンロードを選択できます。 この機能には、いくつかの既知のギャップがあります。 たとえば、ステージを再試行すると、失敗したターゲットだけでなく、すべての VM でデプロイが再実行されます。 今後の更新プログラムでは、これらのギャップを埋めるために取り組んでいます。

デプロイの追加制御

Azure Pipelines では、しばらくの間、手動承認で制御されたデプロイがサポートされています。 最新の機能強化により、デプロイをさらに制御できるようになりました。 承認に加えて、リソース所有者は自動化を checks 追加して、セキュリティポリシーと品質ポリシーを確認できるようになりました。 これらのチェックを使用して、操作をトリガーし、完了するまで待機できます。 追加のチェックを使用して、複数のソースに基づいて正常性基準を定義できるようになり、デプロイを実行する YAML パイプラインに関係なく、リソースを対象とするすべてのデプロイが安全であることが保証されます。 各チェックの評価は、チェックの指定された再試行間隔に基づいて定期的に繰り返すことができます。 次の追加チェックを使用できるようになりました。

• REST API を呼び出し、応答本文または外部サービスからのコールバックに基づいて検証を実行する
• Azure 関数を呼び出し、関数からの応答またはコールバックに基づいて検証を実行する
• アクティブなアラートに対して Azure Monitor ルールのクエリを実行する
• パイプラインが 1 つ以上の YAML テンプレートを拡張していることを確認する

承認通知

環境またはサービス接続に承認を追加すると、リソースを使用するすべてのマルチステージ パイプラインは、ステージの開始時に承認を自動的に待機します。 指定された承認者は、パイプラインを続行する前に承認を完了する必要があります。

この更新プログラムでは、承認者には保留中の承認に関する電子メール通知が送信されます。 ユーザーとチーム所有者は、 通知設定を使用してカスタム サブスクリプションをオプトアウトまたは構成できます。

Azure portalからデプロイ戦略を構成する

この機能により、好みのデプロイ戦略 ( ローリング、 カナリア、 Blue-Green など) を使用するパイプラインを簡単に構成できるようになりました。 これらのすぐに使用できる戦略を使用すると、安全な方法で更新プログラムをロールアウトし、関連する展開リスクを軽減できます。 これにアクセスするには、Azure 仮想マシンの [継続的デリバリー] 設定をクリックします。 構成ウィンドウで、パイプラインが作成される Azure DevOps プロジェクト、デプロイ グループ、デプロイするパッケージを発行するビルド パイプライン、および任意のデプロイ戦略に関する詳細を選択するように求められます。 先に進んで、選択したパッケージをこの仮想マシンにデプロイする完全に機能するパイプラインを構成します。

詳細については、デプロイ戦略の構成に関するドキュメントをチェック。

ランタイム パラメーター

ランタイム パラメーターを使用すると、パイプラインに渡すことができる値をより細かく制御できます。 変数とは異なり、ランタイム パラメーターにはデータ型があり、自動的には環境変数になりません。 ランタイム パラメーターを使用すると、次のことができます。

• 実行時にスクリプトとタスクに異なる値を指定する
• パラメーターの型、使用できる範囲、既定値を制御する
• テンプレート式を使用してジョブとステージを動的に選択する

ランタイム パラメーターの詳細については、 こちらのドキュメントを参照してください。

パイプラインで拡張キーワード (keyword)を使用する

現時点では、パイプラインをテンプレートに組み込み、再利用を促進し、定型句を減らすことができます。 パイプラインの全体的な構造は、ルート YAML ファイルによってまだ定義されていました。 この更新プログラムでは、パイプライン テンプレートを使用するためのより構造化された方法を追加しました。 ルート YAML ファイルは、 拡張キーワード (keyword)を使用して、メイン パイプライン構造が別のファイルで見つかることを示すようになりました。 これにより、拡張または変更できるセグメントと固定されるセグメントを制御できます。 また、提供できるフックを明確にするために、データ型を使用してパイプライン パラメーターを強化しました。

この例では、パイプライン作成者が使用する単純なフックを提供する方法を示します。 テンプレートは常にビルドを実行し、必要に応じてパイプラインによって提供される追加の手順を実行し、オプションのテスト 手順を実行します。

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

キュー時にオーバーライドできる制御変数

以前は、UI または REST API を使用して、新しい実行を開始する前に変数の値を更新できました。 パイプラインの作成者は特定の変数を として _settable at queue time_マークできますが、システムはこれを強制せず、他の変数が設定されるのを妨げませんでした。 言い換えると、この設定は、新しい実行を開始するときに追加の入力を求めるためにのみ使用されました。

パラメーターを適用する新しいコレクション設定が _settable at queue time_ 追加されました。 これにより、新しい実行を開始するときに変更できる変数を制御できます。 今後、作成者によって として _settable at queue time_マークされていない変数を変更することはできません。

注意

この設定は、既存のコレクションでは既定ではオフになっていますが、新しい Azure DevOps コレクションを作成すると既定でオンになります。

YAML パイプラインの新しい定義済み変数

変数を使うと、パイプラインのさまざまな部分に重要なデータを簡単に取り込むことができます。 この更新プログラムでは、いくつかの定義済みの変数をデプロイ ジョブに追加しました。 これらの変数は、システムによって自動的に設定され、特定のデプロイ ジョブにスコープが設定され、読み取り専用です。

• Environment.Id - 環境の ID。
• Environment.Name - デプロイ ジョブの対象となる環境の名前。
• Environment.ResourceId - デプロイ ジョブの対象となる環境内のリソースの ID。
• Environment.ResourceName - デプロイ ジョブの対象となる環境内のリソースの名前。

複数のリポジトリをチェックアウトする

パイプラインは、多くの場合、複数のリポジトリに依存しています。 ソース、ツール、スクリプト、またはコードをビルドするために必要なその他の項目を使用して、さまざまなリポジトリを作成できます。 以前は、これらのリポジトリをサブモジュールとして追加するか、 Git チェックアウトを実行する手動スクリプトとして追加する必要がありました。 これで、YAML パイプラインの格納に使用するリポジトリに加えて、他のリポジトリをフェッチしてチェックできるようになりました。

たとえば、YAML パイプラインを含む MyCode というリポジトリと Tools という 2 つ目のリポジトリがある場合、YAML パイプラインは次のようになります。

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

3 番目の手順では、ソース ディレクトリに MyCode と Tools という 2 つのディレクトリが表示されます。

Azure Repos Git リポジトリがサポートされています。 詳細については、「 複数リポジトリのチェックアウト」を参照してください。

実行時に複数のリポジトリに関する詳細を取得する

パイプラインが実行されている場合、Azure Pipelines は、実行をトリガーしたリポジトリ、ブランチ、コミットに関する情報を追加します。 YAML パイプラインで複数のリポジトリのチェックアウトがサポートされたので、他のリポジトリでチェックアウトされたリポジトリ、ブランチ、コミットを知ることもできます。 このデータはランタイム式を介して使用できます。これにより、変数にマップできるようになりました。 例:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

他のAzure Repos コレクションへのリポジトリ参照を許可する

以前は、YAML パイプラインでリポジトリを参照する場合、すべてのAzure Reposリポジトリがパイプラインと同じコレクションに存在する必要がありました。 これで、サービス接続を使用して、他のコレクション内のリポジトリをポイントできるようになりました。 例:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection は別の Azure DevOps コレクションを指し、別のプロジェクトのリポジトリにアクセスできる資格情報を持っています。 リポジトリ self と otherrepoの両方がチェックアウトされます。

重要

MyServiceConnectionは、Azure Repos/Team Foundation Server サービス接続である必要があります。下の図を参照してください。

定義済み変数としてのパイプライン リソースのメタデータ

パイプラインに YAML パイプライン リソースの定義済み変数を追加しました。 使用できるパイプライン リソース変数の一覧を次に示します。

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

KubernetesManifest タスクでのベイク オプションとしての kustomize と kompose

kustomize (Kubernetes sig-cli の一部) を使用すると、未加工のテンプレートなしの YAML ファイルを複数の目的でカスタマイズでき、元の YAML はそのまま残します。 KubernetesManifest タスクのベイク アクションに kustomize のオプションが追加され、kustomization.yaml ファイルを含むフォルダーを KubernetesManifest タスクの配置アクションで使用されるマニフェスト ファイルの生成に使用できるようにしました。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose は、Docker Compose ファイルを Kubernetes リソースに変換します。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

HelmDeploy タスクでのクラスター管理者資格情報のサポート

以前は、 HelmDeploy タスクはデプロイにクラスター ユーザー資格情報を使用しました。 その結果、対話型のログイン プロンプトが表示され、Azure Active Directory ベースの RBAC 対応クラスターのパイプラインが失敗しました。 この問題に対処するために、クラスター ユーザーの資格情報ではなくクラスター管理者の資格情報を使用できるチェック ボックスを追加しました。

Docker Compose タスクでの引数の入力

などの引数を追加できるように、Docker Compose タスクに新しいフィールドが --no-cache導入されました。 引数は、ビルドなどのコマンドを実行するときにタスクによって渡されます。

GitHub リリース タスクの機能強化

GitHub リリース タスクに対していくつかの機能強化が行われました。 タグの正規表現を指定することで、タグ パターン フィールドを使用してリリースの作成をより適切に制御できるようになりました。リリースは、トリガーするコミットが一致する文字列でタグ付けされている場合にのみ作成されます。

また、変更ログの作成と書式設定をカスタマイズする機能も追加されました。 changelog 構成の新しいセクションで、現在のリリースを比較するリリースを指定できるようになりました。 比較リリースには、最後の完全リリース (プレリリースを除く)、最後のドラフト以外のリリース、または指定したリリース タグに一致する以前のリリースを指定できます。 さらに、タスクには、変更ログの書式を設定するための changelog 型フィールドが用意されています。 選択内容に基づいて、変更ログには、コミットの一覧またはラベルに基づいて分類された issue/PR の一覧が表示されます。

ポリシー エージェント インストーラー タスクを開く

Open Policy Agent は、統合されたコンテキスト対応ポリシーの適用を可能にする、オープンソースの汎用ポリシー エンジンです。 Open Policy Agent インストーラー タスクが追加されました。 これは、コード プロバイダーとしてのインフラストラクチャに関するパイプライン内ポリシーの適用に特に役立ちます。

たとえば、Open Policy Agent では、パイプラインで Rego ポリシー ファイルと Terraform プランを評価できます。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Azure CLI タスクでの PowerShell スクリプトのサポート

以前は、Azure CLI タスクの一部としてバッチ スクリプトと bash スクリプトを実行できました。 この更新プログラムでは、PowerShell と PowerShell コア スクリプトのサポートをタスクに追加しました。

KubernetesManifest タスクでの Service Mesh Interface ベースのカナリア デプロイ

以前は、KubernetesManifest タスクでカナリア戦略が指定されていた場合、このタスクでは、安定したワークロードに使用されるレプリカの割合と等しいレプリカを持つベースラインワークロードとカナリア ワークロードが作成されていました。 これは、要求レベルでトラフィックを目的の割合に分割するのとまったく同じではありません。 これに取り組むために、KubernetesManifest タスクに Service Mesh Interface ベースのカナリア デプロイのサポートを追加しました。

Service Mesh Interface の抽象化により、Linkerd や Istio などのサービス メッシュ プロバイダーとのプラグ アンド プレイ構成が可能になります。 これで、KubernetesManifest タスクは、デプロイ戦略のライフサイクル中に、SMI の TrafficSplit オブジェクトを安定したベースラインおよびカナリア サービスにマッピングするというハード作業を取り除きます。 サービス メッシュ プレーン内の要求に対してトラフィック分割の割合が制御されるため、安定した、ベースライン、カナリア間のトラフィックの必要な割合分割の精度が高くなります。

SMI ベースのカナリア デプロイをローリング方式で実行する例を次に示します。

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure ファイル コピー タスクで AzCopy V10 がサポートされるようになりました

Azure ファイル コピー タスクは、ビルドまたはリリース パイプラインで使用して、Microsoft ストレージ BLOB または仮想マシン (VM) にファイルをコピーできます。 このタスクでは、Azure ストレージ アカウントとの間でデータを高速にコピーするためのコマンド ライン ユーティリティ ビルドである AzCopy を使用します。 この更新プログラムでは、 AzCopy の最新バージョンである AzCopy V10 のサポートが追加されました。

コマンドは azcopy copy 、それに関連付けられている 引数 のみをサポートします。 AzCopy の構文が変更されたため、既存の機能の一部は AzCopy V10 では使用できません。 具体的な内容は次のとおりです。

• ログの場所の指定
• コピー後のログ ファイルとプラン ファイルのクリーニング
• ジョブが失敗した場合にコピーを再開する

このバージョンのタスクでサポートされる追加機能は次のとおりです。

• ソースのファイル名/パス内のワイルドカード 記号
• 引数が指定されていない場合に、ファイル拡張子に基づいてコンテンツ タイプを推論する
• 引数を渡してログ ファイルのログの詳細度を定義する

アクセス トークンのスコープを制限することでパイプラインのセキュリティを強化する

Azure Pipelines で実行されるすべてのジョブは、アクセス トークンを取得します。 アクセス トークンは、タスクとスクリプトによって Azure DevOps にコールバックするために使用されます。 たとえば、アクセス トークンを使用して、ソース コードの取得、ログのアップロード、テスト結果、成果物、または Azure DevOps への REST 呼び出しを行います。 ジョブごとに新しいアクセス トークンが生成され、ジョブが完了すると有効期限が切れます。 この更新プログラムでは、次の機能強化が追加されました。

• トークンがチーム プロジェクトの外部のリソースにアクセスできないようにする

  これまで、すべてのパイプラインの既定のスコープはチーム プロジェクト コレクションでした。 スコープを従来のビルド パイプラインのチーム プロジェクトに変更できます。 ただし、クラシック リリースまたは YAML パイプラインに対しては、そのコントロールがありませんでした。 この更新プログラムでは、パイプラインで構成されている内容に関係なく、すべてのジョブがプロジェクト スコープのトークンを取得するように強制するコレクション設定を導入します。 また、プロジェクト レベルで設定を追加しました。 これで、作成するすべての新しいプロジェクトとコレクションで、この設定が自動的に有効になります。

  注意

  コレクション設定は、プロジェクト設定をオーバーライドします。

  既存のプロジェクトとコレクションでこの設定をオンにすると、アクセス トークンを使用してチーム プロジェクトの外部にあるリソースにパイプラインがアクセスすると、特定のパイプラインが失敗する可能性があります。 パイプラインの障害を軽減するために、目的のリソースへのアクセス権を Project Build Service Account に明示的に付与できます。 これらのセキュリティ設定を有効にすることを強くお勧めします。

• ビルド サービス リポジトリのスコープ アクセスを制限する

  Azure Pipelines では、アクセス トークンのスコープを制限することで、パイプラインのセキュリティを強化することで、 YAML ベースのパイプラインに必要なリポジトリのみにリポジトリ アクセスのスコープを設定できるようになりました。 つまり、パイプラインのアクセス トークンがリークした場合、パイプラインで使用されているリポジトリのみが表示されます。 以前は、アクセス トークンは、プロジェクト内の任意のAzure Repos リポジトリ、またはコレクション全体に適していました。

  この機能は、新しいプロジェクトとコレクションに対して既定でオンになります。 既存のコレクションの場合は、[コレクションの設定][パイプライン>の設定]> で有効にする必要があります。 この機能を使用する場合は、ビルドで必要なすべてのリポジトリ (スクリプトを使用して複製したものも含む) をパイプラインの リポジトリ リソース に含む必要があります。

• アクセス トークンの特定のアクセス許可を削除する

  既定では、アクセス トークンに対して多数のアクセス許可が付与されます。このアクセス許可の 1 つは キュー ビルドです。 この更新プログラムでは、アクセス トークンに対するこのアクセス許可を削除しました。 パイプラインにこのアクセス許可が必要な場合は、使用するトークンに応じて、 プロジェクト ビルド サービス アカウント または プロジェクト コレクション ビルド サービス アカウント に明示的に付与できます。

サービス接続のプロジェクト レベルのセキュリティ

サービス接続のハブ レベルのセキュリティが追加されました。 これで、すべてのサービス接続の一元的な場所で、ユーザーの追加と削除、ロールの割り当て、アクセスの管理を行うことができます。

ステップ のターゲット設定とコマンドの分離

Azure Pipelines では、コンテナーまたはエージェント ホストでのジョブの実行がサポートされています。 以前は、ジョブ全体がこれら 2 つのターゲットのいずれかに設定されていました。 これで、選択したターゲットで個々のステップ (タスクまたはスクリプト) を実行できるようになりました。 ステップは他のコンテナーをターゲットにすることもできます。そのため、パイプラインは専用の専用コンテナーで各ステップを実行できます。

コンテナーは分離境界として機能し、コードがホスト コンピューターで予期しない変更を行うのを防ぐことができます。 ステップがエージェントと通信してサービスにアクセスする方法は、コンテナー内のステップを分離しても影響を受けません。 そのため、ステップ ターゲットで使用できるコマンド制限モードも導入されています。 これをオンにすると、ステップでエージェントに要求できるサービスが制限されます。 ログのアタッチ、成果物のアップロード、およびその他の特定の操作はできなくなります。

ジョブ コンテナー内のホストと別のコンテナーでの実行手順を示す包括的な例を次に示します。

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

読み取り専用変数

システム変数は不変として文書化されていましたが、実際にはタスクによって上書きされる可能性があり、ダウンストリーム タスクは新しい値を取得します。 この更新プログラムでは、パイプライン変数に関するセキュリティを強化して、システム変数とキュー時間変数を読み取り専用にします。 さらに、YAML 変数を次のようにマークすることで、読み取り専用にすることができます。

variables:
- name: myVar
  value: myValue
  readonly: true

サービス接続のロールベースのアクセス

サービス接続のロールベースのアクセスが追加されました。 以前は、サービス接続のセキュリティは、エンドポイント管理者やエンドポイント作成者などの定義済みの Azure DevOps グループでのみ管理できました。

この作業の一環として、閲覧者、ユーザー、作成者、管理者の新しいロールを導入しました。 これらのロールは、プロジェクトのサービス接続ページを使用して設定でき、これらは個々の接続によって継承されます。 また、各サービス接続では、継承をオンまたはオフにし、サービス接続のスコープ内のロールをオーバーライドするオプションがあります。

サービス接続のセキュリティの詳細については 、こちらを参照してください。

サービス接続のプロジェクト間共有

プロジェクト間でのサービス接続共有のサポートを有効にしました。 これで、サービス接続をプロジェクトと安全かつ安全に共有できるようになりました。

サービス接続の共有の詳細については 、こちらを参照してください。

パイプラインと ACR リソースの追跡可能性

パイプラインと ACR コンテナー リソースがパイプラインで使用される場合、完全な E2E 追跡可能性を確保します。 YAML パイプラインによって消費されるすべてのリソースについて、コミット、作業項目、成果物までトレースバックできます。

パイプライン実行の概要ビューには、次の情報が表示されます。

• 実行をトリガーしたリソースのバージョン。 これで、別の Azure パイプラインの実行が完了したとき、またはコンテナー イメージが ACR にプッシュされたときに、パイプラインをトリガーできます。

  

• パイプラインによって使用される コミット 。 また、パイプラインによって使用される各リソースによるコミットの内訳を確認することもできます。

  

• パイプラインによって使用される各リソースに関連付けられている 作業項目 。

• 実行で使用できる 成果物 。

  

環境のデプロイ ビューでは、環境にデプロイされた各リソースのコミットと作業項目を確認できます。

大規模なテスト添付ファイルのサポート

Azure Pipelines のテスト結果の発行タスクを使用すると、テストの実行時にテスト結果を発行して、包括的なテスト レポートと分析エクスペリエンスを提供できます。 これまで、テストの実行結果とテスト結果の両方に対して、テスト添付ファイルの上限は 100 MB でした。 これにより、クラッシュ ダンプやビデオなどの大きなファイルのアップロードが制限されます。 この更新プログラムでは、大きなテスト添付ファイルのサポートが追加され、失敗したテストのトラブルシューティングに使用できるすべてのデータを取得できるようになりました。

VSTest タスクまたはテスト結果の発行タスクがログに 403 または 407 エラーを返す場合があります。 送信要求をフィルター処理するファイアウォールの背後でセルフホステッド ビルドまたはリリース エージェントを使用している場合は、この機能を使用できるようにいくつかの構成変更を行う必要があります。 ​

この問題を解決するには、 へのhttps://*.vstmrblob.vsassets.io送信要求のファイアウォールを更新することをお勧めします。 トラブルシューティング情報については、こちらのドキュメントを参照 してください。 ​

注意

これは、セルフホステッド Azure Pipelines エージェントを使用していて、送信トラフィックをフィルター処理しているファイアウォールの背後にある場合にのみ必要です。 クラウドで Microsoft でホストされているエージェントを使用している場合、または送信ネットワーク トラフィックをフィルター処理していない場合は、何も行う必要はありません。

各ジョブに正しいプール情報を表示する

以前は、マトリックスを使用してジョブを展開したり、変数を使用してプールを識別したりすると、ログ ページ内の不適切なプール情報が解決される場合があります。 これらの問題は解決されました。

新しいブランチの CI トリガー

新しいブランチが作成されたとき、およびそのブランチに変更がない場合に CI ビルドをトリガーしない要求は、長い保留中でした。 次に例を示します。

• Web インターフェイスを使用して、既存のブランチに基づいて新しいブランチを作成します。 これにより、ブランチ フィルターが新しいブランチの名前と一致する場合、新しい CI ビルドが直ちにトリガーされます。 これは、新しいブランチの内容が既存のブランチと比較して同じであるため、望ましくないです。
• アプリとドキュメントの 2 つのフォルダーを持つリポジトリがあります。"アプリ" と一致するように CI のパス フィルターを設定します。 つまり、変更がドキュメントにプッシュされた場合は、新しいビルドを作成する必要はありません。新しいブランチをローカルで作成し、ドキュメントに変更を加えてから、そのブランチをサーバーにプッシュします。 以前は、新しい CI ビルドをトリガーしました。 docs フォルダーで変更を検索しないように明示的に要求したので、これは望ましくないです。 ただし、新しいブランチ イベントの処理方法により、アプリ フォルダーにも変更が加えられたように見えます。

これで、これらの問題に対処するための新しいブランチの CI をより適切に処理する方法が得られます。 新しいブランチを発行すると、そのブランチで新しいコミットが明示的に検索され、パス フィルターと一致するかどうかをチェックします。

ジョブは、前のステージの出力変数にアクセスできます

出力変数は、YAML ベースのパイプライン内のステージ間で使用できるようになりました。 これにより、go/no-go の決定や、生成された出力の ID などの有用な情報を 1 つのステージから次のステージに渡すことができます。 前のステージとそのジョブの結果 (状態) も使用できます。

出力変数は、ジョブ内のステップによって引き続き生成されます。 を参照する代わりに、 dependencies.jobName.outputs['stepName.variableName']ステージは を参照します stageDependencies.stageName.jobName.outputs['stepName.variableName']。

注意

既定では、パイプライン内の各ステージは、YAML ファイル内の直前のステージによって異なります。 したがって、各ステージでは、前のステージの出力変数を使用できます。 依存関係グラフを変更できます。これにより、使用可能な出力変数も変更されます。 たとえば、ステージ 3 にステージ 1 の変数が必要な場合は、ステージ 1 に明示的な依存関係を宣言する必要があります。

プール レベルでエージェントの自動アップグレードを無効にする

現在、パイプライン エージェントは、必要に応じて最新バージョンに自動的に更新されます。 これは通常、新しいエージェント バージョンを正しく機能させる必要がある新しい機能またはタスクがある場合に発生します。 この更新プログラムでは、プール レベルで自動アップグレードを無効にする機能が追加されています。 このモードでは、正しいバージョンのエージェントがプールに接続されていない場合、パイプラインはエージェントに更新を要求するのではなく、明確なエラー メッセージで失敗します。 この機能は、セルフホステッド プールと非常に厳密な変更制御要件を持つお客様にとって、主に関心があります。 自動更新は既定で有効になっており、ほとんどのお客様が自動更新を無効にすることはお勧めしません。

エージェント 診断

多くのネットワークの問題やアップグレード エラーの一般的な原因など、エージェントに関連する多くの一般的な問題に対する診断を追加しました。 診断の使用を開始するには、Windows run.sh --診断 または run.cmd --診断 を使用します。

YAML パイプラインのサービス フック

サービスと YAML パイプラインの統合が簡単になりました。 YAML パイプラインのサービス フック イベントを使用して、パイプラインの実行の進行状況に基づいてカスタム アプリまたはサービスでアクティビティを実行できるようになりました。 たとえば、承認が必要なときにヘルプデスク チケットを作成したり、ステージの完了後に監視ワークフローを開始したり、ステージが失敗したときにチームのモバイル デバイスにプッシュ通知を送信したりできます。

パイプライン名とステージ名のフィルター処理は、すべてのイベントでサポートされています。 承認イベントは、特定の環境でもフィルター処理できます。 同様に、状態変更イベントは、パイプライン実行またはステージの新しい状態でフィルター処理できます。

統合を最適化する

Optimizely は、製品チーム向けの強力な A/B テストおよび機能フラグプラットフォームです。 Azure Pipelines と Optimizely 実験プラットフォームの統合により、製品チームは、Azure Pipelines からすべての DevOps のメリットを得ながら、迅速にテスト、学習、デプロイできるようになります。

Azure DevOps の Optimizely 拡張機能では、実験と機能フラグのロールアウト手順がビルド パイプラインとリリース パイプラインに追加されるため、Azure Pipelines を使用して継続的に反復処理、機能のロールアウト、ロールバックを行うことができます。

Azure DevOps Optimizely 拡張機能の詳細については、 こちらを参照してください。

GitHub リリースを成果物ソースとして追加する

これで、Azure DevOps リリース パイプラインで GitHub リリースを成果物ソースとしてリンクできます。 これにより、デプロイの一部として GitHub リリースを使用できるようになります。

リリース パイプライン定義で [成果物の追加 ] をクリックすると、新しい GitHub リリース ソースの種類が表示されます。 サービス接続と GitHub リポジトリを指定して、GitHub リリースを使用できます。 GitHub リリースの既定のバージョンを選択して、最新の特定のタグ バージョンとして使用したり、リリース作成時に選択したりすることもできます。 GitHub リリースがリンクされると、自動的にダウンロードされ、リリース ジョブで使用できるようになります。

する

Terraform と Azure Pipelines の統合

Terraform は、インフラストラクチャを安全かつ効率的に開発、変更、バージョン管理するためのオープンソース ツールです。 Terraform は API を宣言型構成ファイルに変換し、高度な構成言語を使用してインフラストラクチャを定義およびプロビジョニングできるようにします。 Terraform 拡張機能を使用すると、Azure、アマゾン ウェブ サービス (AWS)、Google Cloud Platform (GCP) のすべての主要なインフラストラクチャ プロバイダーにわたってリソースを作成できます。

Terraform 拡張機能の詳細については、 こちらのドキュメントを参照してください。

Google Analytics との統合

Google Analytics 実験フレームワークを使用すると、Web サイトやアプリに対するほぼすべての変更やバリエーションをテストして、特定の目的への影響を測定できます。 たとえば、ユーザーが完了するアクティビティ (購入、ニュースレターへのサインアップなど) や、改善するメトリック (収益、セッション期間、バウンス率など) があるとします。 これらのアクティビティを使用すると、機能のパフォーマンスに与える直接的な影響に基づいて、実装する価値のある変更を特定できます。

Azure DevOps の Google Analytics 実験拡張機能では、ビルド パイプラインとリリース パイプラインに実験手順が追加されるため、Azure Pipelines から DevOps のすべての利点を得ながら、実験を継続的に管理することで、継続的に反復、学習、デプロイを迅速に行うことができます。

Google Analytics の実験拡張機能は、Marketplace からダウンロードできます。

ServiceNow と Azure Pipelines の統合を更新しました

ServiceNow 用 Azure Pipelines アプリは、Azure Pipelines と ServiceNow Change Management の統合に役立ちます。 この更新プログラムを使用すると、ニューヨークバージョンの ServiceNow と統合できます。 OAuth と基本認証を使用して、2 つのサービス間の認証を行えるようになりました。 さらに、任意の変更プロパティを使用してゲートの結果を決定できるように、高度な成功条件を構成できるようになりました。

VSCode から Azure Pipelines をCreateする

VSCode 用の Azure Pipelines 拡張機能に新しい機能が追加されました。 これで、IDE から離れることなく、VSCode から直接 Azure Pipelines を作成できるようになります。

不安定なバグの管理と解決

検出、レポート、解決によるエンド ツー エンドのライフサイクルをサポートする、不安定なテスト管理を導入しました。 さらに強化するために、薄いテストバグの管理と解決を追加しています。

薄いテストの調査中に、 バグ アクションを使用してバグを作成できます。このアクションを開発者に割り当てて、フラキー テストの根本原因をさらに調査できます。 バグ レポートには、エラー メッセージ、スタック トレース、テストに関連付けられているその他の情報などのパイプラインに関する情報が含まれています。

バグ レポートが解決または閉じられると、テストのマークが自動的に解除されます。

テストの最小数が実行されない場合に VSTest タスクを失敗するように設定する

VSTest タスクは、ユーザー入力 (テスト ファイル、フィルター条件など) と、使用されているテスト フレームワークに固有のテスト アダプターを使用して、テストを検出して実行します。 ユーザー入力またはテスト アダプターを変更すると、テストが検出されず、予想されるテストのサブセットのみが実行される場合があります。 これにより、コードの品質が十分に高いためではなく、テストがスキップされるためにパイプラインが成功する状況が発生する可能性があります。 この状況を回避するために、VSTest タスクに新しいオプションを追加しました。これにより、タスクが合格するために実行する必要があるテストの最小数を指定できます。

VSTest TestResultsDirectory オプションは、タスク UI で使用できます

VSTest タスクは、テスト結果と関連ファイルを フォルダーに $(Agent.TempDirectory)\TestResults 格納します。 テスト結果を格納するように別のフォルダーを構成できるように、タスク UI にオプションが追加されました。 これで、特定の場所にあるファイルを必要とする後続のタスクで、それらを使用できるようになりました。

自動テスト エラー メッセージでの Markdown のサポート

自動テストのエラー メッセージにマークダウンのサポートが追加されました。 これで、テスト実行とテスト結果の両方のエラー メッセージを簡単に書式設定して、読みやすさを向上させ、Azure Pipelines でのテスト エラーのトラブルシューティング エクスペリエンスを容易にすることができます。 サポートされているマークダウン構文については、 こちらを参照してください。

パイプライン デコレーターを使用してデプロイ ジョブにステップを自動的に挿入する

パイプライン デコレーターをデプロイ ジョブに追加できるようになりました。 任意のカスタム ステップ (脆弱性スキャナーなど) を、すべてのデプロイ ジョブのすべての ライフ サイクル フック 実行に自動的に挿入できます。 パイプライン デコレーターはコレクション内のすべてのパイプラインに適用できるため、これは安全なデプロイ プラクティスの実施の一環として活用できます。

さらに、デプロイ ジョブは、定義されている場合、サービス サイド カーと共にコンテナー ジョブとして実行できます。

Test Plans

[新しいテスト 計画] ページ

新しいTest Plans ページ (Test Plans *) は、すべての Azure DevOps コレクションで使用できます。 新しいページでは、目の前のタスク (テスト計画、作成、または実行) に集中するのに役立つ合理化されたビューが提供されます。 また、低優先で、Azure DevOps オファリングの残りの部分と一致しています。

新しいページを理解する

新しいTest Plans ページには合計 6 つのセクションがあり、そのうち最初の 4 つのセクションは新しく、グラフ & 機能拡張セクションは既存の機能です。

1. テスト 計画ヘッダー: これを使用して、テスト 計画の検索、お気に入り、編集、コピー、または複製を行います。
2. テスト スイート ツリー: テスト スイートの追加、管理、エクスポート、または順序付けには、これを使用します。 これを利用して、構成を割り当て、ユーザー受け入れテストを実行します。
3. [定義] タブ: このタブを使用して、選択したテスト スイートでテスト ケースを照合、追加、管理します。
4. [実行] タブ: このタブを使用してテストを割り当てて実行するか、ドリルインするテスト結果を見つけます。
5. [グラフ] タブ: ダッシュボードにピン留めすることもできますが、グラフを使用してテストの実行と状態を追跡します。
6. 機能拡張: 製品内の 現在の機能拡張ポイント をサポートします。

以下のこれらの新しいセクションの幅広いストローク ビューを見てみましょう。

1. テスト 計画ヘッダー

タスク

Test Plan ヘッダーを使用すると、次のタスクを実行できます。

• テスト計画をお気に入りに設定する
• お気に入りのテスト 計画のマークを解除する
• お気に入りのテスト 計画間を簡単に移動
• テスト 計画のイテレーション パスを表示します。これは、テスト 計画が [現在] か [過去] かを明確に示します。
• レポートに移動するためのリンクを含むテストの進行状況レポートの簡単な概要を表示する
• [すべて]/[鉱山] Test Plans ページに戻ります

コンテキスト メニューのオプション

Test Plan ヘッダーのコンテキスト メニューには、次のオプションがあります。

• テスト 計画のコピー: これは、現在のテスト 計画をすばやくコピーできる新しいオプションです。 詳しくは、以下をご覧ください。
• テスト 計画の編集: このオプションを使用すると、[テスト計画作業項目] フォームを編集して作業項目フィールドを管理できます。
• テスト 計画の設定: このオプションを使用すると、テスト実行設定 (ビルドまたはリリース パイプラインを関連付けるために) とテスト結果の設定を構成できます

テスト 計画のコピー (新機能)

スプリント/リリースごとに新しいテスト 計画を作成することをお勧めします。 この場合、一般に、前のサイクルのテスト計画をコピーできます。また、ほとんど変更を加えると、コピーされたテスト 計画は新しいサイクルに対応できます。 このプロセスを簡単にするために、新しいページで "テスト計画のコピー" 機能を有効にしました。 これを活用することで、テスト 計画をコピーまたは複製できます。 そのバッキング REST API についてはこちらを参照 してください。API を使用すると、プロジェクト間でテスト計画をコピーまたは複製することもできます。
Test Plansの使用に関するその他のガイドラインについては、こちらを参照してください。

2. テスト スイート ツリー

タスク

Test suite ヘッダーを使用すると、次のタスクを実行できます。

• 展開/折りたたみ: このツール バー オプションを使用すると、スイート階層ツリーを展開または折りたたみることができます。
• 子スイートからのテスト ポイントを表示する: このツール バー オプションは、[実行] タブに表示されている場合にのみ表示されます。これにより、特定のスイートとその子のすべてのテスト ポイントを 1 つのビューで表示できるため、個々のスイートに一度に 1 つずつ移動することなく、テスト ポイントを簡単に管理できます。
• スイートの順序: スイートをドラッグ/ドロップして、スイートの階層を並べ替えるか、テスト 計画内のスイート階層間で移動することができます。

コンテキスト メニューのオプション

[テスト スイート] ツリーのコンテキスト メニューには、次のオプションがあります。

• Create新しいスイート: 次のように 3 種類のスイートを作成できます。
  • 静的スイートまたはフォルダー スイートを使用してテストを整理します。
  • 要件ベースのスイートを使用して、シームレスなトレーサビリティのために要件/ユーザー ストーリーに直接リンクします。
  • クエリベースを使用して、クエリ条件を満たすテスト ケースを動的に整理します。
• 構成の割り当て: スイートの構成 (Chrome、Firefox、EdgeChromium など) を割り当てることができます。これらは、このスイートに後で追加するすべての既存のテスト ケースまたは新しいテスト ケースに適用されます。
• pdf/email としてエクスポート: テスト 計画のプロパティ、テスト スイートのプロパティ、テスト ケースとテスト ポイントの詳細を "電子メール" または "pdf に印刷" としてエクスポートします。
• [テスト スイート作業項目を開く]: このオプションを使用すると、[テスト スイート作業項目] フォームを編集して作業項目フィールドを管理できます。
• すべてのテストを実行するようにテスト担当者を割り当てる: このオプションは、同じテストを複数のテスト担当者が実行または実行する必要があるユーザー受け入れテスト (UAT) シナリオ (通常は異なる部門に属する) に非常に役立ちます。
• 名前の変更/削除: これらのオプションを使用すると、スイート名を管理したり、スイートとその内容をテスト 計画から削除したりできます。

3. [定義] タブ

[定義] タブを使用すると、テスト スイートのテスト ケースを照合、追加、管理できます。 [実行] タブはテスト ポイントを割り当てて実行するためのタブです。

[定義] タブと特定の操作は、Basic + Test Plans アクセス レベルまたはそれと同等のユーザーのみが使用できます。 それ以外はすべて、"Basic" アクセス レベルのユーザーが実行できる必要があります。

タスク

[定義] タブでは、次のタスクを実行できます。

• 作業項目フォームを使用して新しいテスト ケースを追加する: このオプションを使用すると、作業項目フォームを使用して新しいテスト ケースを作成できます。 作成されたテスト ケースがスイートに自動的に追加されます。
• グリッドを使用して新しいテスト ケースを追加する: このオプションを使用すると、テスト ケース グリッド ビューを使用して 1 つ以上のテスト ケースを作成できます。 作成されたテスト ケースがスイートに自動的に追加されます。
• クエリを使用して既存のテスト ケースを追加する: このオプションを使用すると、クエリを指定して既存のテスト ケースをスイートに追加できます。
• ドラッグ/ドロップでテスト ケースを並べ替える: 特定のスイート内の 1 つ以上のテスト ケースをドラッグ アンド ドロップして、テスト ケースを並べ替えることができます。 テスト ケースの順序は手動テスト ケースにのみ適用され、自動テストには適用されません。
• あるスイートから別のスイートにテスト ケースを移動する: ドラッグ/ドロップを使用すると、テスト ケースをテスト スイート間で移動できます。
• グリッドの表示: グリッド モードを使用すると、テスト ステップと共にテスト ケースを表示/編集できます。
• 全画面表示: このオプションを使用すると、[定義] タブ全体の内容を全画面表示モードで表示できます。
• フィルター処理: フィルター バーを使用すると、"テスト ケースのタイトル"、"割り当て先"、および "状態" のフィールドを使用して、テスト ケースの一覧をフィルター処理できます。 列ヘッダーをクリックしてリストを並べ替えることもできます。
• 列オプション: [列オプション] を使用して、[定義] タブに表示される列の一覧を管理できます。 選択できる列の一覧は、主にテスト ケース作業項目フォームのフィールドです。

コンテキスト メニュー のオプション

[定義] タブの [テスト ケース] ノードのコンテキスト メニューには、次のオプションがあります。

• テスト ケース作業項目フォームを開く/編集する: このオプションを使用すると、テスト ステップを含む作業項目フィールドを編集する作業項目フォームを使用してテスト ケースを編集できます。
• テスト ケースの編集: このオプションを使用すると、テスト ケースの作業項目フィールドを一括編集できます。 ただし、このオプションを使用してテストステップを一括編集することはできません。
• グリッドでテスト ケースを編集する: このオプションを使用すると、グリッド ビューを使用したテスト ステップを含む、選択したテスト ケースを一括編集できます。
• 構成の割り当て: このオプションを使用すると、スイート レベルの構成をテスト ケース レベルの構成でオーバーライドできます。
• テスト ケースの削除: このオプションを使用すると、特定のスイートからテスト ケースを削除できます。 ただし、基になるテスト ケース作業項目は変更されません。
• テスト ケースのコピー/複製をCreateする: このオプションを使用すると、選択したテスト ケースのコピー/複製を作成できます。 詳細については、以下を参照してください。
• リンクされたアイテムを表示する: このオプションを使用すると、特定のテスト ケースのリンクされたアイテムを確認できます。 詳細については、以下を参照してください。

テスト ケースのコピー/複製 (新機能)

テスト ケースをコピー/複製するシナリオでは、"テスト ケースのコピー" オプションを使用できます。 コピー/複製されたテスト ケースを作成する対象プロジェクト、移行先テスト計画、およびコピー先テスト スイートを指定できます。 さらに、複製されたコピーに流れ込む既存のリンク/添付ファイルを含めるかどうかを指定することもできます。

リンクされたアイテムを表示する (新機能)

テスト成果物、要件、バグ間の追跡可能性は、Test Plans製品の重要な価値提案です。 [リンクされた項目の表示] オプションを使用すると、このテスト ケースがリンクされているすべてのリンクされた要件、このテスト ケースが使用されているすべてのテスト スイート/テスト プラン、およびテスト実行の一部として提出されたすべてのバグを簡単に確認できます。

4. [実行] タブ

[定義] タブを使用すると、テスト スイートのテスト ケースを照合、追加、管理できます。 [実行] タブはテスト ポイントを割り当てて実行するためのタブです。

テスト ポイントとは テスト ケース自体は実行可能ではありません。 テスト スイートにテスト ケースを追加すると、テスト ポイントが生成されます。 テスト ポイントは、テスト ケース、テスト スイート、構成、テスターの一意の組み合わせです。 例: "テスト ログイン機能" としてテスト ケースがあり、Edge と Chrome として 2 つの構成を追加すると、2 つのテスト ポイントが作成されます。 これで、これらのテスト ポイントを実行できるようになりました。 実行すると、テスト結果が生成されます。 テスト結果ビュー (実行履歴) を使用すると、テスト ポイントのすべての実行を確認できます。 テスト ポイントの最新の実行は、[実行] タブに表示されます。
そのため、テスト ケースは再利用可能なエンティティです。 それらをテスト 計画またはスイートに含めることで、テスト ポイントが生成されます。 テスト ポイントを実行することで、開発する製品またはサービスの品質を決定します。

新しいページの主な利点の 1 つは、主にテストの実行/追跡を行うユーザー ("Basic" アクセス レベルのみを持つ必要があります)、スイート管理の複雑さに圧倒されることはありません (このようなユーザーにはタブを定義することは非表示です)。

[定義] タブと特定の操作は、Basic + Test Plans アクセス レベルまたはそれと同等のユーザーのみが使用できます。 [実行] タブを含む他のすべてのものは、"Basic" アクセス レベルのユーザーが実行できる必要があります。

タスク

[実行] タブでは、次のタスクを実行できます。

• テスト ポイントの一括マーク: このオプションを使用すると、テスト ランナーを介してテスト ケースを実行しなくても、合格、失敗、ブロック、または適用不可のテスト ポイントの結果をすばやくマークできます。 結果は、一度に 1 つまたは複数のテスト ポイントに対してマークできます。
• テスト ポイントの実行: このオプションを使用すると、各テスト ステップを個別に実行し、テスト ランナーを使用して合格/不合格にマークすることで、テスト ケースを実行できます。 テストするアプリケーションに応じて、"Web アプリケーション" をテストするために "Web ランナー" を使用するか、デスクトップ アプリケーションや Web アプリケーションをテストするための "デスクトップ ランナー" を使用できます。 また、"オプションを指定して実行" を呼び出して、テストを実行するビルドを指定することもできます。
• 列オプション: [実行] タブに表示される列の一覧は、"列オプション" を使用して管理できます。 選択できる列の一覧は、Run by、Assigned Tester、Configuration などのテスト ポイントに関連付けられます。
• 全画面表示: このオプションを使用して、全画面表示モードで [実行] タブ全体の内容を表示できます。
• フィルター処理: フィルター バーを使用すると、"test case title"、"assigned to"、"state"、"test outcome"、"Tester"、"Configuration" の各フィールドを使用して、テスト ポイントの一覧をフィルター処理できます。 列ヘッダーをクリックしてリストを並べ替えることもできます。

コンテキスト メニュー のオプション

[実行] タブの [テスト ポイント] ノードのコンテキスト メニューには、次のオプションがあります。

• テスト結果をマークする: 上記と同じように、合格、失敗、ブロック、または適用できないテスト ポイントの結果をすばやくマークできます。
• テスト ポイントの実行: 上記と同様に、テスト ランナーを使用してテスト ケースを実行できます。
• テストをアクティブにリセットする: このオプションを使用すると、テスト結果をアクティブにリセットし、テスト ポイントの最後の結果を無視できます。
• テスト ケース作業項目フォームを開く/編集する: このオプションを使用すると、テスト ステップを含む作業項目フィールドを編集する作業項目フォームを使用してテスト ケースを編集できます。
• テスト担当者の割り当て: このオプションを使用すると、テストの実行のためにテスト ポイントをテスト担当者に割り当てることができます。
• テスト結果の表示: このオプションを使用すると、各テスト ステップの結果、追加されたコメント、提出されたバグなど、最新のテスト結果の詳細を表示できます。
• 実行履歴の表示: このオプションを使用すると、選択したテスト ポイントの実行履歴全体を表示できます。 選択したテスト ポイントだけでなく、テスト ケース全体の実行履歴を表示するようにフィルターを調整できる新しいページが開きます。

Test Plans進行状況レポート

このすぐに使用できるレポートは、プロジェクト内の 1 つ以上のTest Plansの実行と状態を追跡するのに役立ちます。 Test Plans>進行状況レポート* にアクセスして、レポートの使用を開始します。

レポートの 3 つのセクションには、次のものが含まれます。

1. 概要: 選択したテスト 計画の統合ビューが表示されます。
2. 結果の傾向: 毎日のスナップショットをレンダリングして、実行と状態の近似曲線を表示します。 14 日間 (既定値)、30 日間、またはカスタム範囲のデータを表示できます。
3. 詳細: このセクションでは、各テスト 計画をドリルダウンし、各テスト スイートの重要な分析を提供します。

Artifacts

注意

Azure DevOps Server 2020 では、データのインポート中にごみ箱にあるフィードはインポートされません。 ごみ箱にあるフィードをインポートする場合は、データのインポートを開始する前にごみ箱から復元してください。

ライセンス式と埋め込みライセンス

Visual Studio でパッケージを参照しているときに、Azure Artifacts に格納されている NuGet パッケージのライセンス情報の詳細を確認できるようになりました。 これは、ライセンス式または埋め込みライセンスを使用して表されるライセンスに適用されます。 これで、Visual Studio パッケージの詳細ページ (下の図の赤い矢印) にライセンス情報へのリンクが表示されます。

リンクをクリックすると、ライセンスの詳細を表示できる Web ページが表示されます。 このエクスペリエンスは、ライセンス式と埋め込みライセンスの両方で同じであるため、Azure Artifacts に格納されているパッケージのライセンスの詳細を 1 か所で確認できます (ライセンス情報を指定し、Visual Studio でサポートされているパッケージの場合)。

軽量認証タスク

軽量の認証タスクを使用して、Azure Pipelines の一般的なパッケージ マネージャーで認証できるようになりました。 これには、NuGet、npm、PIP、Twine、Maven が含まれます。 以前は、パッケージを発行およびダウンロードする機能など、大量の機能を提供するタスクを使用して、これらのパッケージ マネージャーに対して認証を行うことができました。 ただし、パッケージ マネージャーと対話するすべてのアクティビティに対してこれらのタスクを使用する必要があります。 パッケージの発行やダウンロードなどのタスクを実行するために実行する独自のスクリプトがある場合は、パイプラインで使用できません。 これで、パイプライン YAML で独自の設計のスクリプトを使用し、これらの新しい軽量タスクで認証を実行できるようになりました。 npm を使用する例:

この図の "ci" コマンドと "publish" コマンドの使用は任意です。Azure Pipelines YAML でサポートされている任意のコマンドを使用できます。 これにより、コマンド呼び出しを完全に制御でき、パイプライン構成で共有スクリプトを簡単に使用できます。 詳細については、 NuGet、 npm、 PIP、 Twine、 Maven 認証タスクのドキュメントを参照してください。

フィード ページの読み込み時間の改善

フィード ページの読み込み時間が改善されたことをお知らせします。 フィード ページの読み込み時間は平均で 10% 減少しました。 最大のフィードでは、99 パーセンタイル フィード ページの読み込み時間 (すべてのフィードの中で最も高い 99% の読み込み時間) が 75% 減少した点が最も改善されています。

パブリック フィードでパッケージをパブリックに共有する

これで、パブリック フィード内にパッケージを作成して格納できるようになりました。 パブリック フィードに格納されているパッケージは、コレクション内にあるかどうかに関係なく、認証なしでインターネット上のすべてのユーザーが利用でき、Azure DevOps コレクションにログインすることもできます。 パブリック フィードの詳細については、 フィードのドキュメントを参照 するか、 パッケージをパブリックに共有するためのチュートリアルに進んでください。

AAD テナント内のさまざまなコレクション内のアップストリームを構成する

これで、Azure Active Directory (AAD) テナントに関連付けられている別のコレクションに、成果物フィードのアップストリーム ソースとしてフィードを追加できるようになりました。 フィードでは、アップストリーム ソースとして構成されているフィードからパッケージを検索して使用できるため、AAD テナントに関連付けられているコレクション間でパッケージを簡単に共有できます。 これを設定する方法については 、ドキュメントを参照してください。

Python 資格情報プロバイダーを使用して、Azure Artifacts フィードで pip と twine を認証する

Python 資格情報プロバイダー (artifacts-keyring) をインストールして使用して、Azure Artifacts フィードとの間で Python パッケージを発行または使用するための認証を自動的に設定できるようになりました。 資格情報プロバイダーを使用すると、構成ファイル (/pip.conf/.pypirc pip.ini) を設定する必要はありません。pip または twine を初めて呼び出すときに、Web ブラウザーの認証フローを使用するだけです。 詳細については、ドキュメントを参照してください。

Visual Studio パッケージ マネージャーの Azure Artifacts フィード

次に、Azure Artifacts フィードから提供されるパッケージのパッケージアイコン、説明、作成者を Visual Studio NuGet パッケージ マネージャーに表示します。 以前は、このメタデータのほとんどは VS に提供されていませんでした。

フィードへの接続エクスペリエンスが更新されました

[フィードに接続] ダイアログは、Azure Artifacts を使用するための入口です。これには、Azure DevOps のフィードからパッケージをプッシュおよびプルするようにクライアントとリポジトリを構成する方法に関する情報が含まれています。 ダイアログを更新して詳細なセットアップ情報を追加し、指示に従ってツールを展開しました。

パブリック フィードがアップストリーム サポートで一般提供されるようになりました

パブリック フィードのパブリック プレビューでは、優れた導入とフィードバックを受け取っています。 このリリースでは、追加機能を一般提供に拡張しました。 これで、パブリック フィードをプライベート フィードのアップストリーム ソースとして設定できるようになりました。 プライベートフィードとプロジェクトスコープフィードの両方をアップストリームにできるため、構成ファイルをシンプルに保つことができます。

ポータルからプロジェクト スコープフィードをCreateする

パブリック フィードをリリースすると、 プロジェクト スコープのフィードもリリースされました。 これまでは、プロジェクト スコープのフィードは、REST API を使用して作成することも、パブリック フィードを作成してからプロジェクトをプライベートにすることで作成することもできます。 これで、必要なアクセス許可がある場合は、任意のプロジェクトからポータルでプロジェクト スコープフィードを直接作成できます。 また、どのフィードがプロジェクトで、どのフィードがコレクション スコープであるかをフィード ピッカーで確認することもできます。

npm のパフォーマンスの向上

Azure Artifacts フィードに npm パッケージを格納して配信する方法を改善するために、コア 設計を変更しました。 これにより、npm で最も使用されている一部の API の待機時間を最大 10 倍削減できます。

アクセシビリティの機能強化

フィード ページでアクセシビリティの問題に対処するための修正プログラムをデプロイしました。 修正には、次のものが含まれます。

• Create フィード エクスペリエンス
• グローバル フィード設定エクスペリエンス
• フィード エクスペリエンスに接続する

Wiki

コード Wiki ページの豊富な編集

以前は、コード Wiki ページを編集するときに、編集のために Azure Repos ハブにリダイレクトされていました。 現在、Repo ハブはマークダウン編集用に最適化されていません。

Wiki 内のサイド バイ サイド エディターでコード Wiki ページを編集できるようになりました。 これにより、リッチ マークダウン ツール バーを使用してコンテンツを作成し、編集エクスペリエンスをプロジェクト Wiki のコンテンツと同じにできます。 コンテキスト メニューの [リポジトリで編集] オプションを選択すると 、リポジトリで編集 することもできます。

Wiki ページから作業項目をCreateして埋め込む

フィードバックを聞くと、Wiki を使用して、ブレーンストーミング ドキュメント、計画ドキュメント、機能に関するアイデア、仕様ドキュメント、会議の議事録をキャプチャすると聞きました。 Wiki ページを離れることなく、計画ドキュメントから機能とユーザー ストーリーを直接簡単に作成できるようになりました。

作業項目を作成するには、作業項目を埋め込む Wiki ページのテキストを選択し、[ 新しい作業項目] を選択します。 これにより、作業項目を最初に作成し、編集に移動し、埋め込む作業項目を見つける必要がないため、時間が節約されます。 また、Wiki のスコープから外れないため、コンテキストの切り替えも減ります。

Wiki からの作業項目の作成と埋め込みの詳細については、 こちらのドキュメントを参照してください。

Wiki ページのコメント

以前は、Wiki 内の他の Wiki ユーザーと対話する方法はありませんでした。 これにより、メールやチャット チャネルを介して会話が行われなければならなかったため、コンテンツで共同作業を行い、質問に答えました。 コメントを使用すると、Wiki 内で他のユーザーと直接共同作業できるようになりました。 コメント内のユーザー機能を @mention 利用して、他のチーム メンバーの注意を引くことができます。 この機能は、 この提案チケットに基づいて優先順位が付けられました。 コメントの詳細については、 こちらのドキュメントを参照してください。

"" で始まるフォルダーとファイルを非表示にします。 wiki ツリー

これまで、Wiki ツリーには、Wiki ツリーのドット (.) で始まるすべてのフォルダーとファイルが表示されました。 コード Wiki のシナリオでは、これにより、非表示にする .vscode などのフォルダーが Wiki ツリーに表示されます。 これで、ドットで始まるすべてのファイルとフォルダーが Wiki ツリーで非表示のままになり、不要な煩雑さが軽減されます。

この機能は、 この提案チケットに基づいて優先順位が付けられました。

短く読み取り可能な Wiki ページ URL

Wiki ページのリンクを共有するために、複数行の URL を使用する必要がなくなりました。 URL のページ ID を利用してパラメーターを削除し、URL を短くして読みやすくしています。

URL の新しい構造は次のようになります。

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

これは、 Azure DevOps Wiki へようこそページの新しい URL の例です。

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

これは、Developer Communityからのこの機能提案チケットに基づいて優先順位が付けられました。

Wiki ページを編集するための同期スクロール

編集ウィンドウとプレビュー ウィンドウ間の同期スクロールにより、Wiki ページの編集が簡単になりました。 一方の側をスクロールすると、もう一方の側が自動的にスクロールされ、対応するセクションがマップされます。 トグル ボタンを使用して同期スクロールを無効にすることができます。

注意

同期スクロール トグルの状態は、ユーザーとアカウントごとに保存されます。

Wiki ページのページ アクセス数

Wiki ページのページ アクセスに関する分析情報を取得できるようになりました。 REST API を使用すると、過去 30 日間のページアクセス情報にアクセスできます。 このデータを使用して、Wiki ページのレポートを作成できます。 さらに、このデータをデータ ソースに格納し、ダッシュボードを作成して、 最も閲覧数の多い上位 n ページなどの特定の分析情報を取得できます。

また、すべてのページで過去 30 日間のページ アクセス数の集計も表示されます。

Note

ページ アクセスは、15 分間隔で特定のユーザーによってページ ビューとして定義されます。

レポート

パイプラインエラーと期間レポート

メトリックと分析情報は、パイプラインのスループットと安定性を継続的に向上させるのに役立ちます。 パイプラインに関する分析情報を提供するために、2 つの新しいレポートが追加されました。

1. パイプラインエラーレポートには、ビルドパス率と失敗傾向が表示されます。 さらに、タスクの失敗傾向も表示され、パイプライン内のどのタスクがエラーの最大数に寄与しているのかを分析する分析情報が提供されます。

2. パイプライン期間レポートには、パイプラインの実行に要した時間の傾向が表示されます。 また、パイプライン内のどのタスクに最も時間がかかっているのも示しています。

クエリ結果ウィジェットの改善

クエリ結果ウィジェットは、最も人気のあるウィジェットの 1 つであり、正当な理由があります。 ウィジェットは、クエリの結果をダッシュボードに直接表示し、多くの状況で役立ちます。

この更新プログラムには、待望の多くの機能強化が含まれています。

• ウィジェットに表示する列の数を選択できるようになりました。 5 列の制限はもうありません。
• ウィジェットは、1x1 から 10x10 までのすべてのサイズをサポートしています。
• 列のサイズを変更すると、 列の幅が保存されます。
• ウィジェットを全画面表示に展開できます。 展開すると、クエリによって返されるすべての列が表示されます。

リードタイムウィジェットとサイクルタイムウィジェットの高度なフィルタリング

チームは、リードとサイクル時間 を使用して、作業が開発パイプラインを通過するのにかかる時間を確認し、最終的に顧客に価値を提供します。

これまで、 リードタイムウィジェットとサイクルタイムウィジェット は、高度なフィルター条件をサポートして、「チームが優先度の高いアイテムを閉じるのにどれくらいの時間がかかっているか」などの質問をしました。

この更新プログラムでは、ボード スイムレーンでフィルター処理することで、このような質問に回答できます。

グラフに表示される作業項目を制限するために、作業項目フィルターも含まれています。

ストーリー ポイントを使用したインライン スプリント バーンダウン

スプリントバーンダウンがストーリー別にバーンダウンできるようになりました。 これは、Developer Communityからのフィードバックに対応します。

[スプリント] ハブから [分析] タブを選択します。次に、次のようにレポートを構成します。

1. ストーリーのバックログを選択する
2. [ストーリー ポイントの合計] を選択してバーンダウンする

あなたが求めてきたすべてのものを含むスプリントバーンダウンウィジェット

新しいスプリント バーンダウン ウィジェットでは、ストーリー ポイント、タスクの数、またはユーザー設定フィールドの合計による書き込みをサポートしています。 フィーチャーやエピックのスプリント バーンダウンを作成することもできます。 ウィジェットには、平均バーンダウン、達成率、スコープの増加が表示されます。 チームを構成して、同じダッシュボードに複数のチームのスプリント バーンダウンを表示できます。 この優れた情報をすべて表示して、ダッシュボードで最大 10x10 のサイズを変更できます。

これを試すには、ウィジェット カタログから追加するか、既存の Sprint Burndown ウィジェットの構成を編集し、[ 今すぐ新しいバージョンを試す ] ボックスをオンにします。

注意

新しいウィジェットでは Analytics が使用されます。 Analytics にアクセスできない場合に備えて、従来のスプリント バーンダウンを維持しました。

インライン スプリントバーンダウンサムネイル

スプリントバーンダウンが帰ってきた! 少し前に、スプリント バーンダウンヘッダーとタスクボードヘッダーからコンテキスト内スプリントバーンダウンを削除しました。 フィードバックに基づいて、スプリントバーンダウンサムネイルが改善され、再導入されました。

サムネイルをクリックすると、すぐに大きなバージョンのグラフが表示され、[分析] タブの下に完全なレポートを表示するオプションが表示されます。レポート全体に加えられた変更は、ヘッダーに表示されるグラフに反映されます。 そのため、残りの作業量だけでなく、ストーリー、ストーリー ポイント、またはタスクの数に基づいてバーンダウンするように構成できるようになりました。

チームなしでダッシュボードをCreateする

チームに関連付けずにダッシュボードを作成できるようになりました。 ダッシュボードを作成するときに、 プロジェクト ダッシュボード の種類を選択します。

プロジェクト ダッシュボードはチーム ダッシュボードに似ていますが、チームに関連付けられていないため、ダッシュボードを編集または管理できるユーザーを決定できます。 チーム ダッシュボードと同様に、プロジェクト内のすべてのユーザーに表示されます。

チーム コンテキストを必要とするすべての Azure DevOps ウィジェットが更新され、構成でチームを選択できるようになりました。 これらのウィジェットをプロジェクト ダッシュボードに追加し、目的の特定のチームを選択できます。

注意

カスタムまたはサードパーティのウィジェットの場合、プロジェクト ダッシュボードは既定のチームのコンテキストをそれらのウィジェットに渡します。 チーム コンテキストに依存するカスタム ウィジェットがある場合は、チームを選択できるように構成を更新する必要があります。

---

フィードバック

皆様のご意見をお待ちしております。 問題を報告したり、アイデアを提供したり、Developer Communityで追跡したり、Stack Overflow に関するアドバイスを得ることができます。

---

ページの先頭へ