Azure DevOps Server 2019 Update 1 リリース ノート

| 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 をオンプレミスにインストールして構成する」を参照してください。

---

Azure DevOps Server 2019 から Azure DevOps Server 2020 への安全なアップグレード

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

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

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

Azure DevOps Server 2019 Update 1.2 Patch 8 リリース日: 2024 年 3 月 12 日

ファイル	Sha-256 ハッシュ
devops2019.1.2patch8.exe	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E4E7C7979244FAD20A

Azure DevOps Server 2019 Update 1.2 用パッチ 8 をリリースしました。これには、次の修正プログラムが含まれています。

• パッチ 7 のインストール後にプロキシ サーバーが動作を停止する問題を解決しました。

Azure DevOps Server 2019 Update 1.2 Patch 7 リリース日: 2024 年 2 月 13 日

ファイル	Sha-256 ハッシュ
devops2019.1.2patch7.exe	8C67C72A83C9215302BDEFB752A7C4E3F876D4D17FCFA63A02B955FCFB5455AA

Azure DevOps Server 2019 Update 1.2 用パッチ 7 をリリースしました。これには、次の修正プログラムが含まれています。

• プロキシ キャッシュ フォルダーで使用されているディスク領域が正しく計算されず、フォルダーが正しくクリーンアップされないバグを修正しました。
• CVE-2024-20667: リモート コード実行の脆弱性Azure DevOps Server。

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

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

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

注意

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

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

重要

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

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

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

重要

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

注意

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

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

1. Azure DevOps Server 2019 Update 1.2 パッチ 5 をダウンロードしてインストールします。

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 2019 Update 1.2 Patch 4 リリース日: 2023 年 8 月 8 日

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

• CVE-2023-36869: Azure DevOps Serverスプーフィングの脆弱性。
• SHA2-256 と SHA2-512 をサポートするように SSH サービスを更新します。 RSA を使用するようにハードコーディングされた SSH 構成ファイルがある場合は、SHA2 に更新するか、エントリを削除する必要があります。
• CronScheduleJobExtension の無限ループバグを修正しました。

Azure DevOps Server 2019 Update 1.2 Patch 3 リリース日: 2023 年 6 月 13 日

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

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

Azure DevOps Server 2019 Update 1.2 Patch 2 リリース日: 2022 年 12 月 13 日

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

• "Account Parallelism Sync Analytics Job" のエラーを修正しました。

Azure DevOps Server 2019 Update 1.2 Patch 1 リリース日: 2022 年 7 月 12 日

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

• Test Runs API では、返される継続トークンが、指定された "maxLastUpdatedDate" 値を超えました。
• クラシック パイプラインの編集中、別のタブで変更を破棄した後、保持タブは空白でした。

Azure DevOps Server 2019 Update 1.2 リリース日: 2022 年 5 月 17 日

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

注意

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

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

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

Azure DevOps Server 2019 Update 1.1 Patch 13 リリース日: 2022 年 1 月 26 日

次の修正プログラムを含む、Azure DevOps Server 2019 Update 1.1 のパッチをリリースしました。

• Email通知は、作業項目で コントロールを@mention使用しているときに送信されませんでした。
• ユーザー プロファイルの優先メール アドレスが更新されていませんでした。 これにより、メールが以前のメール アドレスに送信されていました。
• log4j バイナリから jndilookup クラスを削除することにより、Elasticsearch の脆弱性に対処しました。

インストール手順

1. Patch 13 でサーバーをアップグレードします。
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 13 でサーバーをアップグレードします。
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 ハッシュ: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Azure DevOps Server 2019 Update 1.1 Patch 12 リリース日: 2021 年 9 月 15 日

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

• "単語を含む" クエリの作業項目マクロを修正しました。 以前は、クエリは改行を含む値に対して正しくない結果を返していました。
• カスタム作業項目のレイアウト状態に関するローカライズの問題。
• 電子メール通知テンプレートのローカライズの問題。
• フィールドに対して複数の NOTSAMEAS ルールが定義されている場合の NOTSAMEAS ルールの評価に関する問題。

Azure DevOps Server 2019 Update 1.1 Patch 11 リリース日: 2021 年 9 月 14 日

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

• こちらの Developer Community フィードバック チケットで報告された問題を解決しています。

Azure DevOps Server 2019 Update 1.1 Patch 10 リリース日: 2021 年 8 月 10 日

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

• 一部の作業項目の種類の電子メール配信ジョブに関する問題を修正しました。

Azure DevOps Server 2019 Update 1.1 Patch 9 リリース日: 2021 年 6 月 15 日

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

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

Azure DevOps Server 2019 Update 1.1 Patch 8 リリース日: 2021 年 4 月 13 日

Azure DevOps Server 2019 Update 1.1 のパッチをリリースし、以下を修正しました。

• CVE-2021-27067 : 情報の漏えい
• このDeveloper Communityフィードバック チケットで報告された問題を解決する |Azure DevOps Server 2019 でテスト結果のイテレーションの詳細を登録できない

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

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

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

インストールの確認

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

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

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>*

Azure DevOps Server 2019 Update 1.1 Patch 7 リリース日: 2021 年 1 月 12 日

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

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

Azure DevOps Server 2019 Update 1.1 Patch 6 リリース日: 2020 年 12 月 8 日

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

• CVE-2020-1325: Azure DevOps Serverスプーフィングの脆弱性
• CVE-2020-17135: Azure DevOps Serverスプーフィングの脆弱性
• CVE-2020-17145 : Azure DevOps Server と Team Foundation Services のスプーフィングの脆弱性
• TFVC ですべての結果が処理されない問題を修正する

重要

このパッチをインストールする前に、以下の完全な手順をお読みください。

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

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

インストールの確認

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

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

AzurePowerShellV4 タスクのインストール

注意

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

前提条件

1. Az モジュール Azure Powershell Azure PowerShellプライベート エージェント マシンにインストールします。

2. AzurePowerShellV4 タスクを使用してパイプラインを作成します。 タスクに表示される 標準エラーの失敗 数は 1 つだけです。

インストール

1. AzurePowerShellV4.zip パッケージを AzurePowerShellV4 という名前のフォルダーに抽出します。

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. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 抽出されたパッケージのパスは D:\tasks\AzurePowerShellv4 になります。

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

Azure DevOps Server 2019 Update 1.1 Patch 5 リリース日: 2020 年 9 月 8 日

Azure DevOps Server 2019 Update 1.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

• DTS 1713492 - AD グループをセキュリティアクセス許可に追加する際の予期しない動作。

Azure DevOps Server 2019 Update 1.1 Patch 4 リリース日: 2020 年 7 月 14 日

Azure DevOps Server 2019 Update 1.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

• CVE-2020-1326: クロスサイト スクリプティングの脆弱性
• [その他の Git ソース] を選択すると、承認されていないユーザーの接続が正しく表示されていないビルド パイプライン。
• XAML ビルド定義で [継承] を [オン] または [オフ] に変更するときのエラーを修正しました。

Azure DevOps Server 2019 Update 1.1 Patch 3 リリース日: 2020 年 6 月 9 日

Azure DevOps Server 2019 Update 1.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

• CVE-2020-1327: Azure DevOps サーバーがユーザー入力をサニタイズしていることを確認します。

Azure DevOps Server 2019 Update 1.1 Patch 2 リリース日: 2020 年 4 月 14 日

Azure DevOps Server 2019 Update 1.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

• SVN コミットでパイプラインがトリガーされない

• Azure DevOps での SSH での SHA2 のサポートの追加

Azure DevOps Server 2019 Update 1.1 Patch 1 リリース日: 2020 年 3 月 10 日

次のバグを修正するAzure DevOps Server 2019 Update 1.1 のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

• CVE-2020-0700 : クロスサイト スクリプティングの脆弱性

• CVE-2020-0758 : 特権の昇格の脆弱性

• CVE 2020-0815: 特権の昇格の脆弱性

---

Azure DevOps Server 2019 Update 1.1 RTW リリース日: 2019 年 12 月 10 日

Azure DevOps Server 2019 Update 1.1 は、バグ修正とセキュリティ更新プログラムのロールアップです。 これには、以前にリリースされたAzure DevOps Server 2019 Update 1 パッチのすべての修正プログラムが含まれています。 Azure DevOps Server 2019 Update 1.1 を直接インストールすることも、Azure DevOps Server 2019 または Team Foundation Server 2012 以降からアップグレードすることもできます。

注意

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

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

Azure Boards

• 製品バックログから新しい作業項目を作成する場合、[タイトル] フィールドはプロセス テンプレートの既定値で初期化されません。
• Azure Boardsを使用する場合の速度低下とタイムアウト。
• [変更者] の値が、作業項目のリンクに対して正しくありません。

Azure Pipelines

• パイプライン通知では、一部のロケールでは Duration などのフィールドが null になる場合があります。
• テンプレート パスは、Azure リソース グループのデプロイを含むパイプライン内の有効な JSON ファイルを指していない場合があります。
• コレクション レベルの保持設定ページがプロジェクト設定ページに表示されます。

Azure Test Plans

• Test Plansのフィールドの編集が遅い。
• テスト ケースでは、(Test Plansではなく) ボードから開くと、共有ステップの詳細は開かなくなります。

全般

• コレクションはアルファベット順に並べ替えされません。

管理

• メモリ使用率が高い。
• ロード バランサー構成のサーバーでは、パブリックオリジンを AllowedOrigins レジストリ エントリに明示的に追加する必要がありました。
• SQL Azureにインストールしたお客様には、[試用版の完了] ダイアログが表示されません。
• 拡張機能をインストールすると、"エラー メッセージ Missing contribution (ms.vss-dashboards-web.widget-sdk-version-2)" というエラーが表示されます。
• Elastic Search を設定すると、"ユーザーが承認されていません" というエラーが発生します。
• TFS 2018 Update 2 以降からアップグレードするときの Elastic Search でのインデックス作成とクエリの失敗。
• Azure DevOps Serverを構成すると、"ウェアハウスの作成" ステップが失敗します。

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

• SQL Server 2019 のサポート。

---

Azure DevOps Server 2019 Update 1 Patch 1 リリース日: 2019 年 9 月 10 日

次のバグを修正するAzure DevOps Server 2019 Update 1 のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

• CVE-2019-1306 : Wiki でのリモート コード実行の脆弱性

---

Azure DevOps Server 2019 Update 1 リリース日: 2019 年 8 月 20 日

注意

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

---

RC2 リリース日: 2019 年 7 月 23 日

RC2 には RC1 以降のいくつかのバグ修正が含まれており、最終的に計画されているプレリリースです。

---

RC1 リリース日: 2019 年 7 月 2 日

Azure DevOps Server 2019 Update 1 の新機能の概要

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

• 新しい基本プロセス
• 日、週、月、または年の開始日を基準にした作業のクエリ
• Azure Boardsでの計画中に GitHub の問題を受け入れて実行する
• 自動完了 pull request に対して期限切れのビルドを再実行する
• pull request を完了するための新しいマージの種類
• タグを使用して YAML パイプラインをトリガーする
• YAML ファイルを編集するためのタスク アシスタント
• YAML パイプライン用の IntelliSense を使用した Web エディター
• パイプラインを使用して GitHub リリースを管理する
• テスト結果の傾向 (詳細) ウィジェット
• パッケージに関する実証情報
• Python パッケージのサポート
• Maven のアップストリーム ソース
• クエリ結果Azure Boards Wiki に埋め込む
• Wiki ページの Permarinks
• Wiki ページの通知
• Analytics を使用するために Analytics 拡張機能が不要になった

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

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

---

全般

ダーク テーマ

ダーク テーマは、Azure DevOps Servicesで人気のある機能であり、Azure DevOps Serverで使用できるようになりました。 ダーク テーマをオンにするには、すべてのページの右上にあるアバターの下にあるメニューから [ テーマ ] を選択します。

Boards

新しい基本プロセス

これまで、アジャイルは新しいプロジェクトの既定のプロセスであり、さまざまなプロジェクト配信方法に合わせて堅牢で柔軟な作業項目の種類と状態のセットを提供してきました。 一部のチームでは、他のツールに精通しているか、成長していて、より強力なツール セットを採用したい場合は、より使い慣れた用語を使用してすばやく作業を開始したいと考えています。

新しい Basic プロセスでは、作業を計画および追跡するための 3 種類の作業項目 (エピック、問題、タスク) が提供されます。 イシューを使用してユーザー ストーリー、バグ、機能などを追跡し、エピックを使用してイシューをグループ化して大きな作業単位にすることをお勧めします。 作業を進める際に、To Do、Doing、Done の単純な状態ワークフローに沿って項目を移動します。

新しいプロジェクトの開始に役立つ 問題とタスクの追跡 に関するドキュメントを参照してください。

作業項目フォームの状態値の順序

以前は、作業項目フォームの状態値はアルファベット順に並べ替えられていた。 この更新プログラムでは、プロセス設定のワークフローの順序と一致するように状態値を並べ替える方法を変更しました。 状態のカスタマイズ設定で、各カテゴリの状態の順序を変更することもできます。

機能の有効化は使用できなくなりました

お客様は、コレクションをアップグレードした後に新機能を有効にするために、各プロジェクトの XML を手動で更新する必要があります。

特定の機能を有効にする方法については、 ドキュメントを参照してください 。

豊富な作業項目の添付ファイルを使用して参照資料を整理する

作業項目にファイルを添付すると、自分とチームは参照資料を一元化して、必要なときに常に近づけることができます。 作業項目フォーム上の任意の場所にファイルをドラッグ アンド ドロップするだけで、新しい添付ファイルを簡単に追加できるようになりました。 引き続き添付ファイルを一覧として表示したり、グリッド ビューに切り替えてサムネイル プレビューを表示したりできます。 ファイルをダブルクリックしてプレビューを開き、必要な情報をすばやく見つけられるように順番に移動します。

バッジを使用してチームのボードを共有する

リポジトリの README は、多くの場合、ソリューションに貢献して使用する方法に関する情報を得るためにプロジェクト チームがアクセスするホームです。 これで、Azure Pipelines のビルドまたはデプロイの状態と同様に、Azure Boardsでチームのボードのバッジを README に追加できます。 [進行中] 列またはすべての列のみを表示するようにバッジを構成し、プロジェクトがオープンソースされている場合はバッジを公開することもできます。

README が Markdown に基づいている場合は、ステータス バッジの設定ページからサンプルの Markdown をコピーし、ファイルに貼り付けることができます。

日、週、月、または年の開始日を基準にした作業のクエリ

チームは多くの場合、次に予定されている作業やスプリントのイテレーションに基づいて作業に集中しますが、多くの場合、予定表のレンズを通して作業を振り返って、先月または今年の第 1 四半期に発生したすべての作業を報告することが興味深いです。 これで、次の新しい @StartOf マクロセットと日付ベースのフィールドを使用して、日、週、月、または年の開始日に基づいてクエリを実行できます。

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

これらの各マクロでは、データを異なる日付単位でシフトできる新しい修飾子文字列も受け入れられます。 たとえば、今年の第 1 四半期に完了したすべての作業項目を検索するクエリを作成するには、状態変更日 = および状態変更日 ><= @StartOfYear@StartOfYear("+3M" にクエリを実行します。 詳細については、 クエリ マクロ のドキュメントを参照してください。

ディスカッション コメントの編集と削除

高い投票を受けたDeveloper Community機能の利用、Azure Boardsでの作業項目のディスカッションでのコメントの編集と削除を発表することに興奮しています。 コメントを編集するには、所有している任意のコメントにマウス ポインターを合わせると、2 つの新しいボタンが表示されます。 鉛筆アイコンをクリックすると、編集モードに入り、編集を行い、[更新] ボタンを押して編集内容を保存できます。

オーバーフロー メニューをクリックすると、コメントを削除するオプションが表示されます。 これをクリックすると、このコメントを削除することを確認するメッセージが再び表示され、コメントが削除されます。

作業項目フォームの [履歴] タブには、編集および削除されたすべてのコメントの完全なトレースが表示されます。 また、ディスカッション エクスペリエンスの UI を更新して、よりモダンでインタラクティブに感じるようにしました。 コメントの周囲にバブルを追加して、個々のコメントの開始位置と終了位置を明確にしました。

クエリ結果を CSV ファイルにエクスポートする

Web から CSV 形式ファイルにクエリ結果を直接エクスポートできるようになりました。

GitHub コメントのメンションから直接作業項目Azure Boardsに移動します

これで、 構文を使用して GitHub で Issue、pull request、または commit のコメント内に作業項目をAB#{work item ID}メンションすると、それらのメンションがハイパーリンクになり、クリックして、メンションされた作業項目に直接移動できます。

これにより、関連するすべての会話のAzure Boardsで作業項目を乱雑にする正式なリンクは作成されませんが、代わりに、コードや顧客から報告された問題について話し合いながら、作業項目に関するもう少し情報を提供する方法がチームに提供されます。 詳細については、Azure Boards GitHub 統合ドキュメントを参照してください。

Azure Boardsでの計画中に GitHub の問題を受け入れて実行する

Azure Boardsの作業項目を GitHub の関連する問題とリンクできるようになりました。 この新しい種類のリンクを使用すると、他のいくつかのシナリオが可能になりました。 GitHub 内の問題など、ユーザーからのバグ レポートを引き続き受け入れる必要があるが、チームの作業全体をAzure Boardsに関連付けて整理したい場合は、これで可能です。

チームがコミットと pull request に使用するのと同じメンション構文が引き続き適用されます。もちろん、問題の URL を使用してAzure Boardsで手動でリンクできます。 詳細については、GitHub & Azure Boards ドキュメントを参照してください。

かんばんボードからリンクされた GitHub アクティビティをすばやく表示する

かんばんボードを自分でレビューするとき、またはチームとして、"この項目はまだ開発を開始しましたか?"、"このアイテムはまだレビュー中ですか?" など、多くの場合に質問があります。かんばんボード上の新しい GitHub 注釈を使用すると、項目がどこにあるかを簡単に理解し、GitHub コミット、pull request、または issue に直接移動して詳細を確認できるようになりました。 これとタスクとテストのその他の注釈の詳細については、 カードのカスタマイズ に関するドキュメントを参照してください。

Repos

ドラフト プル リクエスト

準備が整う前に pull request が完了するのを防ぎ、すべてのユーザーが関与しない可能性がある進行中の作業を簡単に作成できるようにするために、下書きの pull request をサポートするようになりました。

下書き pull request は、pull request の作成時に [作成] ボタン ドロップダウンから [下書きとして作成] を選択することで作成できます。

下書き pull request を作成すると、タイトルの横にその状態を示すバッジが表示されます。

下書きプル要求には、レビュー担当者や実行ビルドは既定では含まれませんが、レビュー担当者を手動で追加してビルドを実行できます。 pull request を通常の pull request に昇格するには、pull request の詳細ページから [ 発行 ] ボタンをクリックするだけです。

自動完了 pull request に対して期限切れのビルドを再実行する

Azure Repos、pull request ポリシーによってトリガーされた期限切れのビルドが自動的にキューに入れられます。 これは、他のすべてのポリシーに合格し、自動完了に設定されている pull request に適用されます。

以前は、pull request に必要なレビュー担当者などのポリシーがある場合、承認プロセスに時間がかかりすぎるため、関連付けられているビルドが期限切れになり、レビュー担当者が pull request を承認する可能性がありました。 pull request が自動完了に設定されている場合、ユーザーが期限切れのビルドを手動でキューに入れるまでブロックされたままになります。 この変更により、ビルドは自動的にキューに入れられます。これにより、ビルドが成功した後に pull request が自動的に完了します。

注意

この自動化では、pull request ごとに最大 5 つの期限切れのビルドのみがキューに入れられ、各ビルドのキューの再作成が 1 回だけ試行されます。

pull request で左または右のファイルのみを表示する

現在、pull request でファイルの変更を表示する場合は、side-by-side diff モードまたはインライン diff モードを使用できます。 多くのユーザーが、元のファイルまたは変更されたファイルを比較せずに表示したいだけであるというフィードバックを受け取ったので、左側のファイルまたは右のファイルを個別に表示できる新しいオプションを追加しました。

pull request を完了するための新しいマージの種類

pull request からターゲット ブランチに変更をマージするときに、さらに多くのオプションが用意されました。 Developer Communityで最も要求されている機能の 2 つに対するサポートが追加されました。高速転送マージとセミリニア マージ ("リベースとマージ" とも呼ばれます)。

[ Pull Request の完了 ] ダイアログで、次の新しいオプションを使用できるようになります。

更新されたポリシー管理ページを使用すると、管理者はブランチまたはブランチのフォルダーで許可されるマージ戦略を制御できます。

注意

既存のポリシーは引き続き適用されます。 たとえば、ブランチに現在 "squash マージのみ" ポリシーが設定されている場合、新しいマージ戦略を使用するには、そのポリシーを編集する必要があります。

pull request の完了時に再評価できない場合は、いくつかの状況があります。

• ターゲット ブランチのポリシーでリベース戦略の使用が禁止されている場合は、"ブランチ ポリシーをオーバーライドする" アクセス許可が必要です。
• pull request のソース ブランチにポリシーがある場合、それをリベースすることはできません。 リbasingでは、ポリシー承認プロセスを経ずにソース ブランチが変更されます。
• マージ競合拡張機能を使用してマージ競合を解決した場合。 プル要求内のすべてのコミットを一度に 1 つずつ再ベースする場合、3 方向マージに適用される競合解決が成功することはめったにありません (または有効な場合もあります)。

いずれの場合も、ブランチをローカルに再ベースしてサーバーにプッシュするか、pull request を完了するときに変更をsquashマージするオプションがあります。

pull request (PR) でターゲット ブランチでフィルター処理する

pull request を使用すると、コードをレビューし、変更に関するフィードバックを送信してから、メイン ブランチにマージできます。 提案された変更をステップ実行し、コメントを残し、コードの変更を承認または拒否するために投票できるため、多くのチームのワークフローの重要な部分となっています。

pull request を簡単に見つけられるように、ターゲット ブランチを使用して PR を検索できるようにフィルターオプションを追加しました。

ターゲット ブランチのフィルター処理を使用して、[ マイニング ] タブの pull requests ビューをカスタマイズすることもできます。

拡張機能で構文の強調表示とオートコンプリートを追加できるようにする

現在、 Monaco エディターでサポートされている言語のサブセットの構文の強調表示を公開しています。 ただし、多くのユーザーは、サポートされていない言語に対して独自の構文の強調表示を作成したいと考えています。

この更新プログラムでは、拡張機能がエクスプローラーと pull request ビューに構文の強調表示とオートコンプリートを追加できるようにする拡張ポイントを追加しました。

この機能を示す拡張機能の例 については、こちらを参照してください。

さらに、 Kusto 言語 構文の強調表示のサポートを追加しました。

リポジトリ作成拡張機能ポイント

リポジトリ ピッカーに新しい項目を追加できるようにするための拡張ポイントが追加されました。 この拡張ポイントを使用すると、カスタム アクション (リダイレクト、ポップアップなど) をリポジトリ ピッカー メニューに追加し、代替リポジトリ作成シナリオなどのフローを有効にできます。

エンコードのサポートの強化

以前は、Web 上のファイルを編集して保存すると、UTF-8 エンコードとしてのみ保存され、ファイル エンコードが変更されたときにメッセージが表示されませんでした。 ここで、Web 経由で UTF エンコードされていないファイル (UTF エンコードのみをサポート) を保存しようとすると、警告が表示されます。 さらに、Web プッシュ エンドポイントを介した UTF-16 および UTF-32 エンコードのサポートを追加しました。 つまり、エンコードの種類が保持されるため、UTF-8 として書き換える必要はありません。

次のスクリーンショットは、Web プッシュによるエンコード変更を導入するときに表示されるダイアログの例を示しています。

Azure Reposでコマンドのサポートを取得する

Go は、golang とも呼ばれるオープンソースプログラミング言語です。 Go では、 get コマンド を使用してパッケージと依存関係をダウンロードしてインストールできます。 この更新プログラムでは、Azure DevOps リポジトリ内で の go get サポートが追加されました。 go get を使用すると、インポート パスによって名前が付けられた依存関係を含むパッケージをダウンロードできます。 キー ワードを import 使用して、インポート パスを指定できます。

Pipelines

YAML パイプライン用の IntelliSense を使用した Web エディター

YAML を使用してパイプラインを定義する場合は、このリリースで導入された新しいエディター機能を利用できるようになりました。 新しい YAML パイプラインを作成する場合も、既存の YAML パイプラインを編集する場合でも、パイプライン Web エディター内で YAML ファイルを編集できます。 YAML ファイルを編集するときは、Ctrl + Space キーを押して IntelliSense をサポートします。 構文エラーが強調表示され、それらのエラーの修正に関するヘルプも表示されます。

YAML ファイルを編集するためのタスク アシスタント

パイプライン用の YAML ファイルの編集を容易にすることを求める多くのフィードバックを引き続き受け取るので、YAML エディターにタスク アシスタントを追加しています。 これにより、クラシック エディターと同じ使い慣れたエクスペリエンスで、YAML ファイルに新しいタスクを追加できます。 この新しいアシスタントでは、選択リストやサービス接続など、一般的なタスク入力の種類のほとんどがサポートされています。 新しいタスク アシスタントを使用するには、YAML ベースのパイプラインで [編集] を選択し、[タスク] アシスタントを選択します。

タグを使用して YAML パイプラインをトリガーする

YAML パイプラインは、タグがコミットに追加されたときにトリガーできます。 これは、タグを含むワークフローを持つチームにとって重要です。 たとえば、コミットが "最後の既知の良い" としてタグ付けされたときにプロセスを開始できます。

含めるタグと除外するタグを指定できます。 例:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

コンテナー リソースをインラインで宣言する

以前は、YAML パイプラインでコンテナー リソースを宣言し、名前で参照する必要があります。 コンテナーを複数回参照しない場合のインライン構文が提供されるようになりました。

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

pull request が更新されたときに既存のパイプラインを自動キャンセルするように設定する

既定では、新しいコミットが同じ PR にプッシュされた場合、pull requests (PR) によってトリガーされたパイプラインは取り消されます。 これは、通常は古いコードでパイプラインを実行し続けたくないため、ほとんどの場合は望ましいことです。 この動作が不要な場合は、pr トリガーに autoCancel: false を追加できます。

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

YAML パイプラインでチェックアウトされたコードのディレクトリを選択する

以前は、$(Agent.BuildDirectory) の下の s ディレクトリにリポジトリをチェックアウトしました。 これで、YAML パイプラインで使用するために Git リポジトリをチェックアウトするディレクトリを選択できます。

のcheckoutキーワード (keyword)をpath使用すると、フォルダー構造を制御できるようになります。 ディレクトリの指定に使用できる YAML コードの例を次に示します。

steps:
- checkout: self
  path: my-great-repo

この例では、コードはエージェントのワークスペース内の my-great-repo ディレクトリにチェックアウトされます。 パスを指定しない場合、リポジトリは 引き続き という sディレクトリにチェックアウトされます。

YAML 用に最適化された新しいAzure App Service タスク

4 つの新しいタスクがサポートされるようになりました。これにより、最新の開発者を念頭に置いてAzure アプリ Services を簡単かつ強力にデプロイできます。 これらのタスクには最適化された YAML 構文があり、Windows と Linux の両方のプラットフォームで WebApps、FunctionApps、WebApps for Containers、FunctionApp for Containers など、Azure AppServices へのデプロイを簡単かつ直感的に作成できます。

また、XML 形式と JSON 形式のファイル変換と変数置換のための新しいユーティリティ タスクもサポートしています。

新しいプロジェクトの既定のアクセス許可に対する変更

これまで、プロジェクト共同作成者は、明示的に "ビルド定義の作成" アクセス許可が付与されていない限り、パイプラインを作成できませんでした。 新しいプロジェクトの場合、チーム メンバーはパイプラインを簡単に作成して更新できます。 この変更により、Azure Pipelines にオンボードする新しい顧客の摩擦が軽減されます。 共同作成者グループの既定のアクセス許可をいつでも更新し、そのアクセスを制限できます。

パイプラインを使用して GitHub リリースを管理する

GitHub リリースは、ユーザーにソフトウェアをパッケージ化して提供するための優れた方法です。 Azure Pipelines の GitHub リリース タスクを使用して自動化できるようになったことをお知らせします。 タスクを使用すると、新しいリリースの作成、既存のドラフト/発行済みリリースの変更、または古いリリースの破棄を行うことができます。 複数のアセットをアップロードしたり、リリースをプレリリースとしてマークしたり、リリースをドラフトとして保存したりなどの機能をサポートしています。 このタスクは、リリース ノートの作成にも役立ちます。 また、このリリースで行われた変更 (コミットと関連する問題) を自動的に計算し、ユーザー フレンドリな形式でリリース ノートに追加することもできます。

タスクの単純な YAML を次に示します。

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

このタスクを使用して作成された GitHub リリースのサンプル:

ビルド ログ内の特定の行へのリンク

ビルド ログ内の特定の行へのリンクを共有できるようになりました。 これは、ビルド エラーの診断で他のチーム メンバーと共同作業を行うときに役立ちます。 結果ビューからログの行を選択するだけで、リンク アイコンが表示されます。

リソース承認の機能強化

YAML ファイルで参照されている場合は、保護されたリソース (サービス接続、変数グループ、エージェント プール、セキュリティで保護されたファイルなど) のセキュリティを提供する必要があります。 同時に、これらの種類のリソースを非運用シナリオに使用するパイプラインを簡単に設定して使用できるようにしたいと考えました。 以前は、リソースを "すべてのパイプラインでの使用が承認されました" としてマークする設定を追加しました。

この更新プログラムを使用すると、リソースをそのようにマークしていない場合でも、リソース承認の問題を簡単に修正できます。 新しいエクスペリエンスでは、リソース承認エラーが原因でビルドが失敗すると、パイプラインでこれらのリソースの使用を明示的に承認してから続行するオプションが表示されます。 リソースを承認するアクセス許可を持つチーム メンバーは、失敗したビルドから直接このアクションを完了できます。

[パイプライン テスト] タブの新しい拡張機能コントリビューション ポイント

パイプラインの [テスト結果] タブに 2 つの新しいコントリビューション ポイントを追加することで、拡張機能フレームワークをより強力なものにし続けました。 これにより、 Marketplace 拡張機能 を使用して、よりカスタマイズされたレポート エクスペリエンスを提供し、さらに対話機能を追加できます。

2 つのコントリビューション ポイントは次のとおりです。

1. ツール バーの [カスタム アクション] ボタン

   API のデータの更新や、テスト結果のメタデータを使用したカスタム ツールの実行などのアクションを実行したい場合があります。 このコントリビューション ポイントを使用すると、選択したテスト結果の即時コンテキストを使用してカスタム アクションを *Custom Action- ボタンに追加する拡張機能を作成できます。

   

2. 詳細ウィンドウの [カスタム詳細] タブ

   さまざまなテスト レポート消費ワークフローがあり、デバッグと分析のために失敗したテストに対して異なるデータ ポイントを表示したい場合があります。 このコントリビューション ポイントを使用すると、データ グリッドでテスト結果行を選択したときに表示される新しいタブを詳細ウィンドウに追加できます。 この新しいタブでは、内部 API または外部 API を使用してフェッチされた静的コンテンツまたは動的データを含むビューを表示できます。

エージェントを 1 回実行する

Azure Container Instancesなどのインフラストラクチャを使用してエラスティック プライベート エージェントを実行する場合は、多くの場合、各エージェントが 1 つのジョブのみを受け入れてから退席する必要があります。 これまでは、エージェントを終了する (エラーが報告される可能性がある) か、シャットダウンする前にエージェントが別のジョブを受け取る可能性があるリスクを受け入れる必要があるため、これは簡単ではありませんでした。 この更新プログラムでは、エージェント構成に --once フラグを追加しました。 この方法でエージェントを構成すると、1 つのジョブのみが受け入れられ、シャットダウンされます。

エージェント プールのユーザー インターフェイスの更新

プロジェクト設定のエージェント プール管理ページが、新しいユーザー インターフェイスで更新されました。 これで、プールで実行されているすべてのジョブを簡単に確認できます。 さらに、ジョブが実行されていない理由も学習できます。

示すスクリーンショット

デプロイ グループ内の失敗したターゲットにデプロイする

既定では、 Azure Pipelines は、以前に失敗した実行を再デプロイするときに、すべてのジョブを再実行するために使用されます。 これで、デプロイ時に デプロイ オプション を構成することで、この動作をオーバーライドできます。 [ デプロイ グループ内のすべてのジョブと失敗したターゲットに制限 する] オプションを選択すると、再実行はすべてのジョブを実行し、既に最新のターゲットへのデプロイをスキップします。

失敗時に自動的に再デプロイする

ステージへのデプロイが失敗すると、 Azure Pipelines は最後に成功したデプロイを自動的に再デプロイできるようになりました。 デプロイ後の条件で自動再デプロイ トリガーを構成することで、最後に成功したリリースを自動的にデプロイするようにステージを構成できます。 今後のスプリントで、トリガーされたイベントとアクションを自動再デプロイ構成に追加する予定です。 詳細については、 デプロイ グループ のドキュメントを参照してください。

Grafana 注釈サービス フック

デプロイ完了イベントの Grafana 注釈を Grafana ダッシュボードに追加できる新しいサービス フックがサポートされるようになりました。 これにより、Grafana ダッシュボードで視覚化されているアプリケーションまたはインフラストラクチャ メトリックの変更にデプロイを関連付けることができます。

Azure Monitor アラート タスクのクエリを実行する

以前のバージョンの Azure Monitors クエリ タスクでは、 クラシック監視エクスペリエンスでのみアラートのクエリがサポートされました。 この新しいバージョンのタスクを使用すると、Azure Monitor によって最近導入された統合監視エクスペリエンスに関するアラートに対してクエリを実行できます。

Kubernetes へのデプロイ タスクでの spec ファイルのインライン入力

以前は、Kubernetes デプロイ タスクでは、構成のファイル パスを指定する必要があります。 これで、構成をインラインで追加することもできます。

Docker CLI インストーラー タスク

このタスクでは、ユーザーが指定したエージェントに任意のバージョンの Docker CLI をインストールできます。

削除されたリリース パイプラインを復元する

未使用のリリース パイプラインを削除すると、リリース パイプラインの一覧をクリーン維持するのに役立ちますが、誤って何かを削除することがあります。 この更新プログラムでは、過去 30 日以内に削除されたリリース パイプラインを復元できるようになりました。 [リリース] ページの左側のパネルに、削除されたリリース パイプラインの一覧を表示する新しいタブを追加しました。 このビューから削除されたリリース パイプラインを復元するには、一覧からパイプラインを選択し、[ 復元 ] ボタンをクリックします。

リリース作成要求の失敗に関する通知

ビルド、コード ベース、およびその他の操作に対する変更が発生した場合に電子メールを受信するように通知を設定できます。 たとえば、作業項目が割り当てられたときに通知を受け取るようにアラートを設定できます。

この更新プログラムでは、 リリース カテゴリに新しい通知サブスクリプションを追加しました。 この通知は、リリース作成の要求が失敗したときに電子メールを送信します。 これが役立つシナリオの例は、成果物のバージョンが利用できないためにリリースを作成する要求が失敗した場合です。 通知を管理する方法については、 こちらのドキュメントを参照してください。

ソースまたはパイプラインの変更時にリリースをスケジュールする

以前は、スケジュールされたリリース トリガーがあった場合、アップストリーム成果物またはリリース定義で変更が検出されなかった場合でも、リリースがトリガーされていました。 成果物のバージョンまたはリリース定義が変更された場合にのみリリースをスケジュールするオプションが [リリースのスケジュール ] トリガー パネルに追加されました。

リリース作成ダイアログの変数のコントリビューション ポイント

以前は、リリースの作成時に必要な変数値は、ユーザーが支援や提案なしに入力する必要がありました。 リリースの作成時に変数の値を設定するのに役立つ拡張機能をサポートするために、[ 新しいリリース の作成] ダイアログにコントリビューション ポイントを追加しました。

Azure Service Bus セッション キューに発行する

エージェントレス ジョブ のビルド タスクを拡張して、セッション キューにメッセージを発行する機能を含めます。 このオプションは、[Azure Service Busに発行] タスクに追加されました。

Kubernetes サービス接続の新しい Azure サブスクリプション オプション

ビルドとリリースのサービス接続を使用すると、外部サービスとリモート サービスに接続して、ビルドまたはデプロイのタスクを実行できます。 サービス接続は、プロジェクトの管理設定から定義および管理できます。

この更新プログラムでは、Kubernetes サービス接続フォームに認証オプションを追加しました。 これで、 Azure サブスクリプション を選択して接続を認証できます。 これにより、Azure サブスクリプションとクラスター名を使用して Kubernetes 接続を設定することで、特定の名前空間に簡単にデプロイできます。

ロールベースのアクセス制御 (RBAC) が有効なクラスターの場合、選択した名前空間に ServiceAccount オブジェクトと RoleBinding オブジェクトが作成されます。 RoleBinding オブジェクトは、作成されたサービス アカウントの操作を、選択した名前空間のみに制限します。 RBAC が無効になっているクラスターの場合、作成されたサービス アカウントには、名前空間全体にわたるクラスター全体のアクセス許可があります。

Docker レジストリ サービス接続での Azure コンテナー レジストリ

これで、プロジェクトの設定ページから Docker レジストリ サービス接続を作成できます。 接続を作成するには、Azure Active Directory (AAD) ID に関連付けられているサブスクリプションのいずれかで Azure コンテナー レジストリを選択します。 Docker@2やKubernetesManifest@0など、コンテナー レジストリへのサービス接続を必要とするすべてのタスクは、接続を指定する 1 つの方法をサポートします。

リリース定義でフォルダー名で検索する

リリース定義は、フォルダーに格納することで整理できます。 以前は、フォルダーで検索を実行するオプションがありませんでした。 多数のフォルダーを作成していた場合、特定のリリース定義を見つけることは困難でした。 リリース定義でフォルダー名で検索できるようになり、探している定義を簡単に見つけることができます。

ビルドおよびリリース パイプラインのダフル ツール インストーラー タスク

Duffle は、クラウド ネイティブ アプリケーション バンドル (CNAB) をインストールして管理できるコマンド ライン ツールです。 CNAB を使用すると、コンテナーネイティブ アプリとそのサービスをバンドル、インストール、管理できます。

この更新プログラムでは、特定のバージョンの Duffle バイナリをインストールできるビルド パイプラインとリリース パイプラインの新しいタスクを追加しました。

Kubernetes マニフェスト タスク

マニフェスト ファイルを使用して Kubernetes クラスターにデプロイするプロセスを簡略化するために、リリース パイプラインに新しいタスクを追加しました。 このタスクは、スクリプトでの kubectl バイナリの使用と比較して、次の利点を提供します。

• 成果物の置換 - デプロイ アクションは、タグまたはダイジェストと共に指定できるコンテナー イメージの一覧を入力として受け取ります。 これは、適切なバージョンのイメージがクラスターのノードによって確実にプルされるように、マニフェスト ファイルをクラスターに適用する前に、テンプレート以外のバージョンのマニフェスト ファイルに置き換えます。

• マニフェストの安定性 - デプロイされた Kubernetes オブジェクトに対してロールアウトの状態がチェックされ、タスクの状態を成功または失敗として計算しながら安定性チェックが組み込まれます。

• 追跡可能性の注釈 - 注釈は、デプロイされた Kubernetes オブジェクトに追加され、元のorganization、プロジェクト、パイプライン、および実行に関するトレーサビリティ情報が重ね合わされます。

• ベイク マニフェスト - タスクのベイク アクションを使用すると、クラスターに適用できるように Helm チャートを Kubernetes マニフェスト ファイルにベイクできます。

• デプロイ戦略 - デプロイ アクションを使用してカナリア戦略を選択すると、タスクの昇格/拒否アクションを使用して保持するバージョンを最終処理する前に、タスク中ManualInterventionに比較できるように、-baseline と -canary でサフィックスが付いたワークロードの望ましい割合が作成されます。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

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

Docker タスクへのアップグレード

パイプラインの作成エクスペリエンスを簡略化するために Docker タスクをアップグレードしました。 buildAndPush コマンドを使用して、特定のコンテナー リポジトリの複数のタグをビルドし、1 つの手順で複数のコンテナー レジストリにプッシュできるようになりました。 タスクでは、コンテナー レジストリへのログインに Docker レジストリ サービス接続を使用できます。 ソース リポジトリ、コミット、ビルドの実績に関する追跡可能性メタデータは、このタスクを使用してビルドされたイメージにラベルとして追加されます。

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectl ツール インストーラー

特定のバージョンの Kubectl バイナリをエージェントにインストールできる新しいタスクが追加されました。 'v1.14.0' などの 最新 および semver バージョンの文字列は、Kubectl Version Spec 入力の有効な値として受け入れられます。

ServiceNow 統合の機能強化

チーム間コラボレーションの主な機能は、各チームが選択したサービスを使用し、効果的なエンドツーエンドの配信を実現できるようにすることです。 この更新プログラムでは、ServiceNow 統合が強化され、すべての種類の変更 (通常、標準、緊急) がサポートされました。 さらに、organizationの ITSM プロセスに従って、既存のテンプレートを使用して新しい変更要求を作成するために使用するゲートを指定できるようになりました。 最後に、既存の変更要求に基づいてリリースをゲートすることもできます。 これにより、IT チームによって推奨されるプロセスを変更することなく、CD を採用できます。

Red Hat Enterprise Linux 6 のサポート

この更新プログラムでは、Red Hat Enterprise Linux 6 のエージェント サポートが追加されました。 Red Hat Enterprise Linux 6 プラットフォームを対象とするエージェントを構成して、ビルド ジョブとリリース ジョブを実行できるようになりました。

Azure PowerShell Az モジュールのサポート

Azure PowerShellには、コマンド ラインから Azure リソースを管理するために使用できる一連のコマンドレットが用意されています。 昨年 12 月に、Azure PowerShell Az モジュールが利用可能になり、Azure リソースを管理するための目的のモジュールになりました。

以前は、ホストされているエージェントの Azure PowerShell Az モジュールのサポートは提供していませんでした。 ビルド パイプラインとリリース パイプラインの新しいAzure PowerShell タスク バージョン 4.* により、すべてのプラットフォームに対する新しい Az モジュールのサポートが追加されました。 タスク バージョン 3.* Azure PowerShell、AzureRM モジュールは引き続きサポートされます。 ただし、最新の Azure サービスと機能に対応するには、できるだけ早く Azure PowerShell タスク バージョン 4.* に切り替えることをおすすめします。

Az モジュールには、既存のスクリプトを使用するのに役立つ互換性モードがあり、新しい構文を使用するように更新します。 Az モジュールの互換性を有効にするには、 コマンドを Enable-AzureRmAlias 使用します。 エイリアスを使用すると、Az モジュールで古いコマンドレット名を使用できます。 Azure RM モジュールから Azure PowerShell Az モジュールへの移行の詳細については、こちらを参照してください。

注意

プライベート エージェントを使用している場合は、エージェント コンピューターに Az モジュールをインストールする必要があります。

Azure PowerShell Az モジュールの詳細については、こちらのドキュメントを参照してください。

Azure SQL タスクに対する Azure Active Directory (AD) 認証のサポート

Azure SQL タスクは、SQL Server 認証の既存のサポートに加えて、Azure AD (統合 & パスワード) と接続文字列を使用したデータベースへの接続をサポートするように強化されました。

長いファイル パスを使用してビルド成果物を発行する

これまでは、パスが 233 文字を超えるビルド成果物をアップロードできなくなるという制限がありました。 これにより、ファイル パスが制限より長い Linux ビルドと macOS ビルドからコード カバレッジの結果をアップロードできなくなる可能性があります。 この制限は、長いパスをサポートするように更新されました。

コミットの継続的インテグレーション (CI) をスキップする

コミットを無視し、コミットが通常トリガーするパイプラインの実行をスキップするように Azure Pipelines に指示できるようになりました。 HEADコミットのコミット メッセージに を含める[skip ci]だけで、Azure Pipelines は CI をスキップします。 以下に示すバリエーションのいずれかを使用することもできます。 これは、Git と GitHub Enterprise Server へのコミットAzure Reposサポートされています。

• [skip ci] または [ci skip]
• skip-checks: true または skip-checks:true
• [skip azurepipelines] または [azurepipelines skip]
• [skip azpipelines] または [azpipelines skip]
• [skip azp] または [azp skip]
• ***NO_CI***

Test Plans

テスト結果の傾向 (詳細) ウィジェット

テスト結果の傾向 (高度) ウィジェットでは、複数のビルドとリリースのテスト データをほぼリアルタイムで可視化できます。 テスト結果の傾向 (詳細) ウィジェットには、パイプラインまたはパイプライン全体のテスト結果の傾向が表示されます。 これを使用して、テスト、合格率、テスト期間の 1 日の数を追跡できます。 テスト品質を経時的に追跡し、テスト関連情報を改善することは、正常な DevOps パイプラインを維持する上で不可欠です。

テスト結果の傾向 (高度) ウィジェットは、テスト結果の外れ値を見つけ、次のような質問に答えるのに役立ちます。テストの実行に通常よりも時間がかかっていますか? 全体的な合格率に影響を与えるテスト ファイルまたはパイプラインは何ですか? 実行時間の長いテストとは

これらの質問に答えるために、ウィジェットには次の機能が用意されています。

• 合格率の傾向とテスト結果またはテスト期間の数を表示します
• 複数のビルド パイプラインまたはリリース パイプラインに基づいてテスト結果を表示します
• 結合されたグラフ作成オプションを使用して、同じ傾向に対して 2 つのメトリックを表示します
• テスト結果によって時間の経過に伴うテスト数をフィルター処理する
• ブランチまたはテストですべてのテスト結果をフィルター処理する
• 優先度や環境などのテスト属性によってメトリックをスタックする
• テスト ファイル、所有者、またはパイプラインに関するデータをグループ化する

ウィジェットは高度に構成可能であり、さまざまなシナリオで使用できます。

URL を使用してテスト実行結果を共有する

ビルドまたはリリースの一部として実行するように自動テストを構成できます。 発行されたテスト結果は、ビルドまたはリリースの概要の [ テスト ] タブに表示できます。 この更新プログラムでは、1 つのテスト実行結果をチーム内の他のユーザーと共有できるように、 結果 URL のコピー 機能が追加されました。

共有レベルは次のとおりです。

• 実行レベル
• 結果レベル
• テスト実行内で選択された個々のタブ
• 共有は、構成されている拡張機能タブとも互換性があります

URL を共有すると、閲覧者にはテストの実行結果が全画面表示で表示されます。

Artifacts

SemVer 2.0.0 バージョン番号を含む NuGet パッケージ

以前は、Azure Artifacts では、SemVer 2.0.0 バージョン番号を含む NuGet パッケージはサポートされていませんでした (一般に、 によって示 +されるバージョンのビルド メタデータ部分を含むバージョン番号)。 ビルド メタデータを含む nuget.org からパッケージを保存し、ビルド メタデータを使用して独自のパッケージをプッシュできるようになりました。 SemVer 仕様と NuGet.org ポリシーでは、パッケージの順序付けにはビルド メタデータを使用できません。 そのため、 と 1.0.0+build2 の両方1.0.0+build1を Azure Artifacts (または nuget.org) に発行することはできません。これらのバージョンは同等と見なされるため、不変性の制約の対象となります。

パッケージに関する実証情報

この更新プログラムを使用すると、パッケージの証明 (誰または何が発行されたか、ソース コードのコミット元) を少し簡単に理解できるようになりました。 この情報は、Azure Pipelines の NuGet、 npm、 Maven、 Twine Authenticate (Python の場合) タスクを使用して発行されたすべてのパッケージに対して自動的に設定されます。

パッケージの使用状況の統計

これまで、Azure Artifacts はパッケージの使用状況や人気度を測定する方法を提供していませんでした。 この更新プログラムでは、パッケージの一覧とパッケージの詳細ページの両方に ダウンロード と ユーザー の数を追加しました。 どちらのページの右側にも統計が表示されます。

Python パッケージのサポート

Azure Artifacts で Python パッケージをホストできるようになりました。自分で作成するパッケージと、パブリック PyPI から保存されたアップストリーム パッケージの両方。 詳細については、お知らせのブログ投稿とドキュメントを参照 してください。

これで、すべての NuGet、npm、Maven、Python パッケージを同じフィードでホストできるようになりました。

Maven のアップストリーム ソース

Maven フィードでアップストリーム ソースを使用できるようになりました。 これには、プライマリ Maven Central リポジトリと Azure Artifacts フィードが含まれます。 Maven アップストリームを既存のフィードに追加するには、[ フィードの設定] にアクセスし、[ アップストリーム ソース] ピボットを選択し、[ アップストリーム ソースの追加] を選択します。

成果物に関連するタスクのプロキシサポート

これまで、成果物関連のビルド タスクの多くは Azure Pipelines のプロキシ インフラストラクチャを完全にサポートしていなかったため、オンプレミス エージェントのタスクを使用する際の課題が生じていました。 この更新プログラムでは、次のタスクにプロキシのサポートを追加しました。

• Npm@1 (デザイナーの 'npm')
• NuGetCommand@2 (デザイナーの 'NuGet'): 復元コマンドとプッシュ コマンドのみ
• DotNetCoreCLI@2 (デザイナーの '.NET Core'): 復元および nuget プッシュ コマンドのみ
• NpmAuthenticate@0、PipAuthenticate@0、およびTwineAuthenticate@0 (デザイナーで '[種類] 認証'): これらのタスクは、認証トークンの取得中にプロキシをサポートしますが、プロキシを使用するように後続のタスク/スクリプト/ツールを構成する必要があります。 別の言い方をすると、これらのタスクでは、基になるツール (npm、pip、twine) のプロキシは構成されません。
• NuGetToolInstaller@0、NodeTool@0、DotNetCoreInstaller@0 ('[type] Installer' in the designer)

リリースでサポートされているすべての成果物パッケージの種類

これまで、Pipelines リリースの Azure Artifacts 成果物の種類 では、NuGet パッケージのみがサポートされていました。 この更新プログラムでは、Maven、npm、Python のすべての Azure Artifacts パッケージの種類がサポートされています。

リリースでサポートされている成果物ビュー

以前は、Azure Artifacts 成果物の種類は、新しいパッケージ バージョンがフィードに発行されたときにのみトリガーできました。 これで、ビューのサポートも追加されました。フィードに既に含まれているパッケージがビューに昇格されたときにリリースをトリガーできるようになりました。

アイテム保持ポリシーでは、最近ダウンロードしたパッケージをスキップできます

これまで、Azure Artifacts フィードでは、"パッケージあたりの最大バージョン数" に達したときに古いパッケージ バージョンの削除を開始する基本的なアイテム保持ポリシーが提供されていました。 この更新プログラムでは、このクリーンを実行するときに、最近ダウンロードしたパッケージをスキップする機能が追加されました。 有効にするには、フィードを編集し、[最近ダウンロードしたパッケージをスキップする] チェックボックスをチェックします。

フィードを管理できる代理人

Azure Artifacts では、 プロジェクト コレクション管理者 (PCA) は常に Azure DevOps サーバー内のすべてのフィードを管理できました。 この更新プログラムを使用すると、PCA は他のユーザーやグループにもこの機能を提供できるため、フィードを管理する機能を委任できます。

Wiki

数式とビデオ用のマークダウン テンプレート

Wiki を編集するときに 、数式、 ビデオ 、 YAML タグ を追加するためのマークダウン構文を覚える必要がなくなりました。 ツールバーのコンテキスト メニューをクリックし、任意のオプションを選択できるようになりました。

クエリ結果Azure Boards Wiki に埋め込む

これで、クエリ結果Azure Boardsテーブルの形式の Wiki ページに埋め込むことができます。 次の図は、リリースされたすべての機能と、Wiki に埋め込まれている現在のスプリント内のすべてのアクティブなバグの一覧を含む Wiki ページのサンプルを示しています。 ページに表示されるコンテンツは、既存の作業項目クエリを使用しています。 この新機能を使用すると、動的コンテンツを作成でき、Wiki ページの手動更新について心配する必要はありません。

クエリ結果は、次の 2 つの手順で追加できます。

1. 編集ツール バーの [クエリ結果] ボタンをクリックします。

2. 必要なクエリを選択し、[挿入] ボタンをクリックします。

ページを保存した後、クエリの結果をテーブルの形式で表示できるようになりました。

Wiki Markdown エディターのモノスペース フォント

Wiki Markdown エディター用のモノスペース フォントの導入により、読みやすさはもはや課題ではありません。 Markdown ソースはクリーンで読みやすく見えます。 この機能は、 この提案チケットに基づいて優先順位が付けされています。

Wiki ページの Permarinks

これまで、リンクされたページの名前が変更または移動された場合、共有 Wiki ページのリンクが壊れていました。 URL にページ ID を追加することで、永続的なリンクが導入されました。 これにより、Wiki が時間の経過と同時に変化しても、共有するリンクはそのまま残ります。

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

Wiki ページで作業項目の状態を表示する

この更新では、作業項目の状態をページに追加し、その ID とタイトルを追加することで、Wiki ページの作業項目のメンションを強化しました。

Pull Request コメントと Boards ディスカッションの作業項目参照にも、状態が表示されます。

@mention ユーザーとグループ

Wiki ページでユーザーとグループを作成できるようになりました @mention 。 これにより、チームの連絡先ページ、ガイダンス ドキュメント、ナレッジ ドキュメントなどのドキュメントが豊富になります。 次の図は、タスクと責任者を含むスプリントの振り返りを示す例です。

span class=@メンション ユーザーとグループを 。 />

さらに、Wiki の編集ページに「@」と入力して、自動提案からユーザーまたはグループを選択することもできます。 記載されたユーザーには、メールでも通知されます。

@メンション。 />

最後に、ユーザーを@mentionedクリックして、カードプロファイル情報を表示することもできます。 この機能は、 この 機能の提案に基づいて優先順位付けされています。

Wiki ページの通知

これまでは、Wiki ページのコンテンツがいつ変更されたかを知る方法はありませんでした。 ページが編集、削除、または名前変更されたときに、Wiki ページをフォローしてメールで通知を受け取ることができます。 Wiki に加えられた変更を追跡するには、Wiki ページから [ フォロー ] ボタンを選択します。

この機能は、 この 提案チケットに基づいて優先順位が付けされています。 詳細については、 こちらのドキュメントを参照してください。

HTML タグのサポート

これで、HTML タグを使用して Wiki で豊富なコンテンツを作成できるようになりました。 以下の HTML タグでできることをご確認ください。

1. 詳細タグとサマリー タグを使用して、Wiki ページ内に折りたたみ可能なセクションを作成できるようになりました。 open 属性を追加して、詳細を既定で展開したままにすることができます。

   

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

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

   注意

   このタグは、Edge およびインターネット エクスプローラー ブラウザーではサポートされていません。

テーブルの作成と編集の改善

これまで、Wiki でのテーブルの作成と編集は困難でした。 Wiki でテーブルを追加および管理しやすくするために、変更が加えられます。

1. グリッドからテーブルを作成する

   マークダウン テーブルの構文を覚える必要がなくなりました。 これで、15 X 15 グリッドから選択することで、マークダウン テーブルを簡単に作成できます。 1 回のクリックでテーブルを挿入するために必要な列と行の数を選択するだけです。

   

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

   • Wiki のテーブル ビュー
   • Wiki でテーブルを簡単に挿入できるようにする

2. テーブルの読みやすさの向上

   エディターの 折り返し を切り替えて、テーブルの読みやすさを向上できるようになりました。 ワード ラップを無効にすると、スクロール バーが追加され、大きなテーブルの内容を簡単に確認できます。

   

3. マークダウン テーブルのオートフォーマット

   マークダウン列を配置するためにスペースを追加する必要がなくなりました。 [ テーブルの書式設定 ] ボタンを使用すると、マークダウン テーブルは、列を揃えるためにセルにスペースを追加することで自動的に書式設定されます。 大きなテーブルがある場合は、表を読みやすくするために、 ワード ラップを無効 にして使用します。

   

   Ctrl + Shift + F ショートカットを使用して、テーブルの書式を設定することもできます。

レポート

Analytics を使用するために Analytics 拡張機能が不要になった

分析は、Azure DevOps エクスペリエンスの不可欠な部分になりつつあります。 顧客がデータ主導の意思決定を行うのを支援することは重要な機能です。

Update 1 では、お客様が Analytics を使用するために Analytics 拡張機能を必要としなくなることをお知らせします。 お客様は、[プロジェクト コレクションの設定] の下で分析を有効にできるようになりました。 これは、製品内で適切な単純なプロセスです。

お客様が Analytics を有効にする方法を次に示します。

1. [プロジェクト コレクションの設定] に移動します。

2. [ 分析を有効にする] をクリックします

以上で作業は終了です。 分析機能を利用したエクスペリエンスは、コレクションに対して有効になります。

アップグレードされた Analytics 拡張機能がインストールされた Update 1 コレクションと Azure DevOps Server 2019 コレクションで作成された新しいコレクションでは、既定で Analytics が有効になります。

分析とそれが可能にするエクスペリエンスの詳細については、以下を参照してください。

• 詳細については、 Analytics の有効化に関するページを参照してください。
• Analytics の概要に関するドキュメントを参照してください。
• 主な機能については、 分析ウィジェット、 上位失敗テスト レポート、 Power BI 統合、 OData エンドポイントに関するページを参照してください。
• この Channel 9 Video on Azure DevOps Analytics をご覧ください。

---

フィードバック

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

---

ページの先頭へ