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 10 リリース日: 2025 年 3 月 11 日

ファイル	SHA-256 ハッシュ
devops2019.1.2patch10.exe	0983A46E080DDDE09208612247670D2BAAF2A9AD3BF57FD111AF95F14F120E70

Azure DevOps Server 2019 Update 1.2 用の Patch 10 をリリースしました。これには次のものが含まれます。

• Edgio CDN の廃止に伴うタスクの更新。 詳細については、CDN プロバイダーの切り替えに関するブログ投稿 を参照してください。

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 用 Patch 9 をリリースしました。これには次のものが含まれています。

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

手記

パッチ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	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E7C7979244FAD20A

Azure DevOps Server 2019 Update 1.2 用の Patch 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 用 Patch 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 をインストールする前に、これらの更新プログラムをインストールすることをお勧めします。 Patch 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 ジョブ" のエラーを修正しました。

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

手記

データ移行ツールは、このリリースから約 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でレジストリ値を確認します。 レジストリ値が存在しない場合は、文字列値を追加し、バージョンを 5.4.1 (名前 = バージョン、値 = 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でレジストリ値を確認します。 レジストリ値が存在しない場合は、文字列値を追加し、バージョンを 5.4.1 (名前 = バージョン、値 = 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 には、次の修正プログラムが含まれています。

• この開発者コミュニティ フィードバック チケット で報告された問題を解決します。

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 CheckInstallを実行します。devops2019.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 と、Node.js ダウンロードに含まれている npm をダウンロードしてインストールします。

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

npm install -g tfx-cli

4. フル アクセス 特権を持つ個人用アクセス トークンを作成し、コピーします。 この個人用アクセス トークンは、tfx ログイン コマンドを実行するときに使用されます。

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 CheckInstallを実行します。devops2019.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. 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 ログイン コマンドを実行するときに使用されます。

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

• テスト 計画のフィールドの編集が遅い。
• テストケースでボードから開くと（テストプランからではなく）、共有ステップの詳細は表示されません。

全般

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

行政

• メモリ使用量が多い。
• ロード バランサー構成を持つサーバーは、パブリックオリジンを 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 日

手記

データ移行ツールは、このリリースから約 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 の問題を受け入れて実行する
• 自動補完プルリクエストのために期限切れのビルドを再実行する
• プルリクエストを完了するための新しいマージタイプ
• タグ を使用して YAML パイプラインをトリガーする
• YAML ファイルを編集するためのタスク アシスタント
• YAML パイプライン用の IntelliSense を備えた Web エディター
• パイプライン を使用して GitHub リリースを管理する
• テスト結果傾向 (詳細) のウィジェット
• パッケージ に関する の由来情報
• Pythonパッケージへのサポート
• Maven の アップストリームソース
• Wiki に Azure Boards クエリ結果を埋め込む
• Wiki ページ用の パーマリンク
• ウィキページでの通知
• Analytics 拡張機能で Analytics を使用する必要がなくなりました

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

• 全般
• ボード
• Repos
• パイプライン
• テスト計画
• アーティファクト
• Wiki
• 報告

---

全般

ダーク テーマ

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

ボード

新しい基本プロセス

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

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

基本プロセス

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

作業項目フォームにおける状態値の順序設定

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

機能の有効化は利用不可になりました

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

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

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

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

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

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

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

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

の README のバッジ

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

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

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

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

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

Azure Boards での作業項目のディスカッションで、高い投票を受けた Developer Community 機能の提供、コメントの編集と削除を発表いたします。 コメントを編集するには、所有しているコメントの上にマウス ポインターを置くと、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 でチームの作業全体を関連付けて整理したい場合は、次の手順を実行できます。

の関連する問題と Azure Boards の作業項目をリンクする

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

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

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

からリンクされた GitHub アクティビティを表示する

リポジトリ

下書きプルリクエスト

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

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

を作成する

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

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

自動補完のプルリクエストのために期限切れのビルドを再実行する

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

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

手記

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

プル要求で左または右のファイルのみを表示する

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

プルリクエストを完了するための新しいマージの種類

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

プルリクエスト を完了する ダイアログで、新しいオプションが利用できるようになりました。

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

を制限する

手記

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

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

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

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

プル要求 (PR) のターゲット ブランチをフィルターで絞り込む

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure Repos での Go get コマンドのサポート

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

パイプライン

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

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

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

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

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

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

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

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

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

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

最新の開発者を念頭に置いて Azure App Services をデプロイするための簡単かつ強力な方法を提供する 4 つの新しいタスクがサポートされるようになりました。 これらのタスクには最適化された 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 のデータの更新や、テスト結果のメタデータを使用したカスタム ツールの実行などのアクションを実行できます。 このコントリビューション ポイントを使用すると、選択したテスト結果の即時コンテキストを使用して、カスタム アクションを *[カスタム アクション- ] ボタンに追加する拡張機能を作成できます。

   

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

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

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

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

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

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

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

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

障害発生時に自動的に再デプロイする

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

Grafana 注釈サービスのフック

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

Azure Monitor アラート タスクを検索する

以前のバージョンの Query 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 オブジェクトに注釈が追加され、元の組織、プロジェクト、パイプライン、および実行に関する追跡情報が重ね合わされます。

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

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

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 モジュールへの移行の詳細については、こちら参照してください。

手記

プライベート エージェントを使用している場合は、エージェント マシンに 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***

テスト 計画

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

テスト結果傾向 (詳細) ウィジェット は、複数のビルドとリリースのテスト データをほぼリアルタイムで可視化します。 テスト結果の傾向 (詳細) ウィジェット、パイプラインまたはパイプライン全体のテスト結果の傾向が表示されます。 これを使用して、テスト、合格率、およびテスト期間の 1 日あたりのカウントを追跡できます。 時間の経過と共にテスト品質を追跡し、テスト資料を改善することは、正常な DevOps パイプラインを維持するための鍵となります。

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

これらの質問に答えるために、ウィジェットには次の機能があります。

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

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

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

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

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

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

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

成果 物

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

以前は、Azure Artifacts では、SemVer 2.0.0 バージョン番号 (通常、バージョンのビルド メタデータ部分を含むバージョン番号(+で示される) を含む NuGet パッケージはサポートされていませんでした。 ビルド メタデータを含む nuget.org からパッケージを保存し、ビルド メタデータを使用して独自のパッケージをプッシュできるようになりました。 SemVer 仕様の と NuGet.org ポリシーでは、ビルド メタデータを使用してパッケージを注文することはできません。 そのため、1.0.0+build1 と 1.0.0+build2 の両方を 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'): コマンド「restore」と「push」のみ実行可能
• DotNetCoreCLI@2 (デザイナー内の『.NET Core』): "restore" と "nuget push" コマンドのみ
• NpmAuthenticate@0、PipAuthenticate@0、およびTwineAuthenticate@0 (デザイナーでは '[種類] 認証'): これらのタスクは、認証トークンの取得中にプロキシをサポートしますが、プロキシを使用するように後続のタスク/スクリプト/ツールを構成する必要があります。 別の言い方をすると、これらのタスクでは、基になるツール (npm、pip、twine) のプロキシは構成されません。
• NuGetToolInstaller@0、NodeTool@0、DotNetCoreInstaller@0（デザイナー内の '[type] インストーラー'）

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

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

リリースでサポートされるアーティファクトビュー

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

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

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

フィードを管理できるユーザーを委任する

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

ウィキ

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

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 できるようになりました。 これにより、チームの連絡先ページ、ガイダンス ドキュメント、ナレッジ ドキュメントなどのドキュメントが豊富になります。 次の図は、タスクと責任者を含むスプリント振り返りを示す例です。

@mention ユーザーとグループをするときの表示を示しています。 />

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

@mentionの <入力を開始したときに表示される自動提案を示すスクリーンショット。 />

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

Wiki ページの通知

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

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

HTML タグのサポート

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

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

   

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

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

   手記

   このタグは、Edge および Internet Explorer ブラウザーではサポートされていません。

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

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

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

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

   

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

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

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

   エディターでチャートを読みやすくするために、ワードラップを 切り替え可能になりました。 折り返しを無効にすると、大きなテーブルの内容を簡単に表示できるスクロール バーが追加されます。

   

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

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

   

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

報告

Analytics 拡張機能で Analytics を使用する必要がなくなりました

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

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

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

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

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

これで終わりです！ 分析機能を利用したエクスペリエンスは、コレクションに対して有効になります。

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

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

• Analytics を有効にするについて詳しくは、こちらをご覧ください。
• Analytics の概要に関するドキュメントを参照してください。
• Analytics ウィジェットの、トップ失敗テスト レポート、Power BI 統合、OData エンドポイントの主な機能について説明します。
• Channel 9 のビデオ を Azure DevOps Analyticsでご覧ください。

---

フィードバック

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

---

ページの上部