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

開発者コミュニティ | システム要件 | ライセンス条項 | DevOps ブログ | SHA-1 ハッシュ

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

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

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 9 リリース日: 2024 年 5 月 28 日

ファイル	Sha-256 ハッシュ
devops2019.1.2patch9.exe	4A3F41BBE00174DE964667878766EBF7F4D292526CBC1D885180B55D994B4D81

以下を含む Azure DevOps Server 2019 Update 1.2 用のパッチ 9 がリリースされました。

• 以前のパッチ (パッチ 5 と 6) からのエージェントとタスクの更新プログラムのデプロイを効率化します。

Note

パッチ5と6の手順に従う必要はありません。これらはスキップでき、代わりにこのパッチを適用できます。

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

重要

 このパッチは利用可能な Pipeline エージェントを更新します。Patch 9 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

パイプラインの要件

新しい動作を適用してコマンド ライン引数を検証するには、影響を受けるタスクを使用するパイプラインで変数 AZP_75787_ENABLE_NEW_LOGIC = true を設定する必要があります。 有効な動作の詳細については、こちらを参照してください。

• クラシックの場合:

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

• YAML の例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

ファイル	Sha-256 ハッシュ
devops2019.1.2patch8.exe	67E78EA7D67A09A6 Enterprise Edition 06309614F92E6D8495DEF52FF442E4E7C7979244FAD20A

次の修正プログラムを含む、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 タスク許可リストを拡張しました。

Note

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

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

重要

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

TFX を構成する

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

TFX を使ってタスクを更新する

ファイル	Sha-256 ハッシュ
Tasks20231103.zip	389BA66 Enterprise Edition BC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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 の特権の昇格の脆弱性。

重要

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

Note

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

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

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 エージェントのドキュメントに記載されている手順を使って、エージェントを展開します。  

Note

エージェントがダウングレードされないようにするには、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 ジョブ" のエラーを修正しました。

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

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

• テスト実行 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 以降からアップグレードできます。

Note

データ移行ツールは、このリリースから約 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 のパッチをリリースしました。

• 作業項目でコントロールを使用しているときに、 @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 を実行します。 次のような警告が返される場合があります: "リモート サーバー に接続できません"。 更新プログラムによって再試行が実行されている場合は、それが完了するまで、ウィンドウを閉じないでください。

Note

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 には、次の修正プログラムが含まれています。

• "Contains Words" を使用したクエリの作業項目マクロを修正しました。 以前は、クエリは改行を含む値に対して正しくない結果を返していました。
• カスタム作業項目のレイアウト状態のローカライズの問題。
• 電子メール通知テンプレートのローカライズの問題。
• 1 つのフィールドに対して複数の 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: 情報の漏えい
• この開発者コミュニティのフィードバック チケットで報告された問題を解決する |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 タスクのインストール

Note

以下に説明する手順はすべて、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 サーバーのスプーフィングの脆弱性
• 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 タスクのインストール

Note

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

前提条件

1. プライベート エージェント マシンに Azure PowerShell Az モジュール 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 以降からアップグレードできます。

Note

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

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

Azure Boards

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

Azure Pipelines

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

Azure Test Plans

• テスト 計画のフィールドの編集が遅い。
• テスト ケースでは、ボードから (テスト 計画ではなく) 開くと、共有ステップの詳細は開かないでください。

全般

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

管理

• メモリ使用量が多い。
• ロード バランサー構成を持つサーバーは、パブリックオリジンを AllowedOrigins レジストリ エントリに明示的に追加する必要がありました。
• SQL Azure にインストールするユーザーには、[試用版の完了] ダイアログが表示されません。
• 拡張機能をインストールすると、"エラー メッセージの投稿がありません (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 日

Note

データ移行ツールは、このリリースから約 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 向けアップストリーム ソース
• Wiki に Azure Boards クエリ結果を埋め込む
• Wiki ページ用のパーマリンク
• Wiki ページに関する通知
• Analytics 拡張機能で Analytics を使用する必要がなくなりました

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

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

---

全般

濃いテーマ

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

Boards

新しい基本プロセス

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

新しい基本プロセスでは、作業を計画および追跡するための 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" でクエリを実行します。 詳細については、 クエリ マクロ のドキュメントを参照してください。

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

高い投票を受けた 開発者コミュニティ 機能の提供、Azure Boards での作業項目のディスカッションでのコメントの編集と削除をお知らせします。 コメントを編集するには、所有しているコメントの上にマウス ポインターを置くと、2 つの新しいボタンが表示されます。 鉛筆アイコンをクリックすると、編集モードに入り、編集を行い、[更新] ボタンを押して編集を保存できます。

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

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

CSV ファイルへのクエリ結果のエクスポート

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

GitHub の任意のコメント内のメンションから直接 Azure Boards 作業項目に移動する

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

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

Azure Boards で計画を立てながら GitHub で問題を受け入れて対処する

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

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

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

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

Repos

ドラフト プル リクエスト

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

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

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

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

オートコンプリート pull request のために期限切れビルドを再実行する

Azure Repos は、pull request ポリシーによってトリガーされた期限切れのビルドを自動的にキューに入れるようになりました。 これは、他のすべてのポリシーに合格し、オートコンプリートに設定されているプル要求に適用されます。

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

Note

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

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

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

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

プル要求からターゲット ブランチに変更をマージするときに、さらに多くのオプションが追加されました。 開発者コミュニティ で最も要求されている 2 つの機能のサポートが追加されました。高速マージ と セミリニア マージ ("Rebase and Merge" とも呼ばれます)。

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

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

Note

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

プル要求の完了時にリベースできない状況がいくつかあります。

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

いずれの場合も、ブランチをローカルにリベースしてサーバーにプッシュするか、プル要求を完了するときに変更をスカッシュマージするかを選択できます。

pull request (PR) のターゲット ブランチによるフィルター

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

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

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

構文の強調表示およびオートコンプリートを追加する拡張機能の許可

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

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

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

さらに、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 ファイルを編集するときは、IntelliSense のサポートに Ctrl + Space キーを使用します。 構文エラーが強調表示され、それらのエラーの修正に関するヘルプも表示されます。

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 にプッシュされた場合、プル要求 (PR) によってトリガーされたパイプラインは取り消されます。 これは、通常は古いコードでパイプラインを実行し続けたくないため、ほとんどの場合に望ましいことです。 この動作が不要な場合は、PR トリガーに autoCancel: false を追加できます。

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

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

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

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

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

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

YAML 用に最適化された新しい Azure アプリ サービス タスク

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

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

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

Pipelines のテスト タブの新しい拡張機能のコントリビューション ポイント

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

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

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

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

   

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

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

一度だけ実行するエージェント

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

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

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

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

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

エラー発生時に自動的に再デプロイする

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

Grafana の注釈サービス フック

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

Azure Monitor アラートのクエリ タスク

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

Kubernetes へのデプロイ タスクにおける仕様ファイルのインライン入力

以前は、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 ツールのインストーラー タスク

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

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

Kubernetes マニフェスト タスク

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

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

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

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

• ベイク マニフェスト - タスクのベイク アクションを使用すると、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 統合が強化されました。 さらに、組織内の 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 モジュールのサポートが追加されました。 Azure PowerShell タスク バージョン 3.* では、引き続き AzureRM モジュールがサポートされます。 ただし、最新の Azure サービスと機能に対応するために、できるだけ早く Azure PowerShell タスク バージョン 4.* に切り替えすることをお勧めします。

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

Note

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

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

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

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

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

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

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

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

• [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 パッケージはサポートされていませんでした。これは a +によって示されます。 ビルド メタデータを含む nuget.org からパッケージを保存し、ビルド メタデータを使用して独自のパッケージをプッシュできるようになりました。 SemVer 仕様と NuGet.org ポリシーでは、ビルド メタデータを使用してパッケージを注文することはできません。 そのため、Azure Artifacts (または nuget.org) の両方1.0.0+build11.0.0+build2を発行することはできません。これらのバージョンは同等と見なされるため、不変性の制約の対象となります。

パッケージに関する来歴情報

この更新プログラムにより、パッケージの実績 (誰または何が発行されたか、ソース コードのコミット元) を少し簡単に理解できるようになりました。 この情報は、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 アップストリームを既存のフィードに追加するには、フィード設定にアクセスし、[アップストリーム ソース] ピボットを選択してから、[アップストリーム ソースの追加] を選択します。

Artifacts に関連するタスクでのプロキシのサポート

これまで、アーティファクト関連のビルド タスクの多くは 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 (デザイナーの '[種類] インストーラー' )

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

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

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

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

保持ポリシーによる最近ダウンロードされたパッケージのスキップ

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

フィードの管理を委任する

Azure Artifacts では、Project Collection 管理istrators (PCA) は、常に Azure DevOps サーバー内のすべてのフィードを管理できました。 この更新プログラムにより、PCA は他のユーザーやグループにもこの機能を提供できるため、フィードを管理する機能を委任できます。

Wiki

数式およびビデオ用の Markdown テンプレート

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

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

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

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

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

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

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

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

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

Wiki ページ用のパーマリンク

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

この機能は、この提案チケットに基づいて優先されました。

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

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

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

@mention ユーザーとグループ

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

@メンション ユーザーとグループ。 />

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

@メンション。 />

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

Wiki ページに関する通知

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

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

HTML タグのサポート

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

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

   

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

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

   Note

   このタグは、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 の有効化に関するページを参照してください。
• Analytics の概要に 関するドキュメントを参照してください。
• 分析ウィジェット、上位失敗テスト レポート、Power BI 統合、OData エンドポイントの主な機能について説明します。
• Azure DevOps Analytics でこの Channel 9 ビデオをご覧 ください。

---

フィードバック

皆様のご意見をお待ちしております。 問題を報告したり、アイデアを提供したり、開発者コミュニティを通じて追跡したり、Stack Overflow に関するアドバイスを得たりすることができます。

---

ページの先頭へ