Azure DevOps Server 2019 のリリース ノート

Developer Community | System Requirements | License Terms | DevOps Blog | SHA-1 Hashes

この記事では、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.0.1 Patch 16 リリース日: 2023 年 11 月 14 日

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

• Enable シェル タスク引数パラメーターの検証の文字の許可リストを PowerShell タスクで拡張しました。

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

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.0.1 Patch 15 リリース日: 2023 年 9 月 12 日

以下を修正する Azure DevOps Server 2019.0.1 のパッチをリリースしました。

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

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

1. Azure DevOps Server 2019.0.1 Patch 15 をダウンロードしてインストールします。

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

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

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.0.1 Patch 14 リリース日: 2022 年 8 月 8 日

以下を修正する Azure DevOps Server 2019.0.1 用の patch をリリースしました。

• CVE-2023-36869: Azure DevOps サーバーのスプーフィングの脆弱性。

Azure DevOps Server 2019.0.1 Patch 13 リリース日: 2022 年 5 月 17 日

以下を修正する Azure DevOps Server 2019.0.1 用の patch をリリースしました。

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

Azure DevOps Server 2019.0.1 Patch 12 リリース日: 2022 年 1 月 26 日

以下を修正する Azure DevOps Server 2019.0.1 用の patch をリリースしました。

• log4j バイナリから jndilookup クラスを削除することにより、Elasticsearch の脆弱性に対処しました。

インストール手順

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

1. Patch 12 を使用してサーバーをアップグレードします。
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 Hash: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 Patch 11 リリース日: 2021 年 8 月 10 日

以下を修正する Azure DevOps Server 2019.0.1 用の patch をリリースしました。

• ビルド定義 UI エラーを修正しました。

Azure DevOps Server 2019.0.1 Patch 10 リリース日: 2021 年 4 月 13 日

以下を修正する Azure DevOps Server 2019.0.1 のパッチをリリースしました。

• CVE-2021-27067: 情報の漏えい

Patch 10 を適用するには、 AzureResourceGroupDeploymentV2 タスクをインストールする必要があります。

AzureResourceGroupDeploymentV2 タスクのインストール

インストール

1. AzureResourceGroupDeploymentV2.zip パッケージをコンピューター上の新しいフォルダーに展開します。 例: 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.0.1 Patch 9 リリース日: 2020 年 12 月 8 日

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

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

一般的な修正プログラムのインストール

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

インストールの確認

• オプション 1: devops2019.0.1patch9.exe CheckInstallを実行します。devops2019.0.1patch9.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.0.1 Patch 9 をインストールすると、バージョンは 17.143.30723.4 になります。

AzurePowerShellV4 タスクのインストール

前提条件

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

2. AzurePowerShellV4 タスクを使用してパイプラインを作成します。 タスクに表示される Fail on Standard Error は 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 (1)\AzurePowerShellv4 になります。

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

Azure DevOps Server 2019.0.1 Patch 8 リリース日: 2020 年 9 月 8 日

Azure DevOps Server 2019.0.1 用の セキュリティパッチ をリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

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

Azure DevOps Server 2019.0.1 Patch 7 リリース日: 2020 年 7 月 14 日

Azure DevOps Server 2019.0.1 用の セキュリティパッチ をリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

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

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

Azure DevOps Server 2019.0.1 用の セキュリティパッチ をリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

• CVE-2020-1327: Azure DevOps Server でユーザー入力がサニタイズされていることを確認する
• Azure DevOps での SSH での SHA2 のサポートの追加

Azure DevOps Server 2019.0.1 Patch 5 リリース日: 2020 年 3 月 10 日

Azure DevOps Server 2019.0.1 用の セキュリティパッチ をリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

• CVE-2020-0700: クロスサイト スクリプティングの脆弱性
• CVE-2020-0758: 特権の昇格の脆弱性
• CVE 2020-0815: 特権の昇格の脆弱性

Azure DevOps Server 2019.0.1 Patch 3 リリース日: 2019 年 9 月 10 日

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

• CVE-2019-1305: Repos でのクロス サイト スクリプティング (XSS) の脆弱性
• CVE-2019-1306: Wiki でのリモート コード実行の脆弱性

---

Azure DevOps Server 2019.0.1 Patch 2 リリース日: 2019 年 8 月 13 日

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

• 既定ですべてのパイプラインに対して承認されていることを明確にするために、サービス接続に情報を追加しました。

---

Azure DevOps Server 2019.0.1 Patch 1 リリース日: 2019 年 7 月 9 日

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

• CVE-2019-1072: 作業項目のトラッキング中のリモート コード実行の脆弱性
• CVE-2019-1076: プル要求にクロス サイト スクリプティング (XSS) の脆弱性

---

Azure DevOps Server 2019.0.1 リリース日: 2019 年 5 月 21 日

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

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

Azure Boards

• プランを構成するときに、"このプランのフィールド条件にエラーがあります"。 Developer Community を通じて報告されます。
• apiwitcontroller.executequery は、クエリに同じ列が複数回ある場合に例外をスローします。
• vso.work_full oauth スコープを使用するクライアント オブジェクト モデルでは、WorkItemServer.DownloadFile() は失敗します。
• 作業項目フィールドから別のプロジェクト内の別の作業項目フィールドに埋め込まれたイメージをコピーすると、破損した画像が作成されることがあります。

Azure Repos

• "TF401019: GitRepositoryNotFoundException"。

Azure Pipelines

• Test Analytics タブには、この機能がプレビュー段階ではない場合でも、プレビューを示す星 (*) があります。
• Releases タブで、アクセス許可を変更できるかどうかに関係なく、セキュリティを管理するアクションがすべてのユーザーに表示されるようになりました。
• [リリース] ランディング ページでは、ドラフトリリースの開始アクションで新しいリリースが作成されていましたが、現在はドラフト リリースが開始されます。

Azure Test Plans

• TestRuns と TestResults CompletedDate の 1 時間フィルターが細かすぎます。
• テスト ケース作業項目の種類では、種類 "テスト ケース" をローカライズしないでください。
• テスト ケースは MTM またはブラウザーに表示されません。
• テスト 計画から自動テストを実行すると、"検証ステージ: 関連付けられているリリース パイプラインでリリースをトリガーするアクセス許可がありません" というエラーが表示されます。 Developer Community を通じて報告されます。
• delete テスト ケース APIを使用すると、テスト ケースを他のプロジェクトから削除できます。 Developer Community を通じて報告されます。
• テスト ランナーの作業項目リンクをクリックすると、既定のブラウザーではなく、テスト ランナー内の作業項目 URL が開きます。
• テスト ランナーからサインアウトしたユーザーのテスト ケースの状態が更新されません。
• ユーザー名と電子メール アドレスは、テスト ランナーのユーザー ドロップダウンに表示されません。

Azure Artifacts

• 上へ移動 と 下へ移動 はアップストリームにローカライズされません。

分析

• 分析レポートでは、モデルが実際に完了する前に "準備完了" としてマークされているため、不完全なデータが表示される場合があります。
• 速度、バーンダウン、バーンアップウィジェットには、異なるタイムゾーンのユーザーに対して異なる計画された作業が表示されます。
• メンテナンス中に Analytics のデータ インジェストに保留が発生し、古いレポートが発生する可能性があります。

全般

• 十分な領域がない場合、IE では左側のナビゲーション項目が絞り込まれます。

管理

• 問題のデバッグに役立つ、コレクションのアップグレードに追加されたログ記録。
• TfsConfig offlineDetach が失敗した場合、エラー メッセージは操作できません。
• TfsJobAgent サービスがクラッシュします。
• 構成が完了した後、Search 拡張機能はインストールされません。
• 構成 DB が破損すると、管理コンソールが応答しなくなります。
• サービス フックで通知が正しく処理されない場合があります。
• コード検索のインデックス作成は、Search の構成後に開始されません。
• 検索ページの結果には、未割り当て文字列があります。

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

Visual Studio テスト タスクでの Visual Studio 2019 (VS2019) のサポート

パイプラインの Visual Studio テスト タスクに Visual Studio 2019 のサポートが追加されました。 Visual Studio 2019 のテスト プラットフォームを使用してテストを実行するには、[テスト プラットフォームのバージョン] ドロップダウンから Latest または Visual Studio 2019 オプションを選択します。

---

Azure DevOps Server 2019 Patch 2 リリース日: 2019 年 5 月 14 日

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

• CVE-2019-0872: Test Plans でのクロス サイト スクリプティング (XSS) の脆弱性
• CVE-2019-0971: Repos API での情報漏えいの脆弱性
• CVE-2019-0979: ユーザー ハブでのクロス サイト スクリプティング (XSS) の脆弱性

---

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

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

• CVE-2019-0857: Wiki のスプーフィングの脆弱性
• CVE-2019-0866: Pipelines でのリモート コード実行の脆弱性
• CVE-2019-0867: Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
• CVE-2019-0868: Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
• CVE-2019-0869: パイプラインの HTML インジェクションの脆弱性
• CVE-2019-0870: Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
• CVE-2019-0871: Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
• CVE-2019-0874: Pipelines のクロスサイト スクリプティング (XSS) の脆弱性
• CVE-2019-0875: Boards の特権の昇格の脆弱性

---

Azure DevOps Server 2019 リリース日: 2019 年 3 月 5 日

---

RC2 リリース日: 2019 年 1 月 22 日

Azure DevOps Server 2019 RC2 の新機能の概要

RC2 に次の機能が追加されました。

• GitHub Enterprise のコミットと pull request を Azure Boards の作業項目にリンクする
• YAML を使用してビルドを構成する
• カード注釈には、バグとカスタム作業項目の種類が含まれます
• 改善されたブランチ ピッカー
• 成果物とリリース管理のデプロイ パイプライン ライセンスの変更

---

RC1 リリース日: 2018 年 11 月 19 日

Azure DevOps Server 2019 RC1 の新機能の概要

Azure DevOps Server 2019 では、新しいナビゲーション エクスペリエンスと多くの新機能が導入されています。 主な特徴:

• 新しいナビゲーション エクスペリエンス
• レポート用の Analytics マーケットプレース拡張機能が利用可能になりました
• Azure SQL Database のサポート
• 新しいコレクションの継承を処理する
• 新しい作業項目ハブ
• 新しいボード、バックログ、スプリント ハブ
• 新しいクエリ ハブ
• テンプレートを使用して pull request の説明を標準化する
• pull request のターゲット ブランチを変更
• 新しい [ビルド] ページを使用してビルド パイプラインを管理する
• 新しい [リリース] ページを使用してリリース パイプラインを管理する
• リリースの進行状況を視覚化する
• エージェントをローカルで更新する
• リリース ゲートを使用して段階的に公開し、デプロイをフェーズ化する
• アップストリーム ソース
• Wiki ページの目次を作成する

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

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

---

全般

Azure DevOps Server の発表

9 月 10 日に、Visual Studio Team Services と Team Foundation Server の進化として Azure DevOps を発表しました。 Azure DevOps Server 2019 は、この新しいブランドで初めてのオンプレミス リリースです。 詳細については、 ブログの投稿を参照してください。

新しいナビゲーション エクスペリエンス

ユーザー エクスペリエンスを最新化するための新しいナビゲーションが導入されています。 この新しいナビゲーションは Azure DevOps サービスにロールアウトされ、Azure DevOps Server 2019 で使用できるようになりました。 詳細については、ブログを参照してください。

成果物とリリース管理のデプロイ パイプライン ライセンスの変更

ユーザーからのフィードバックに基づいて、Azure DevOps Server 2019 でライセンスに 2 つの重要な変更を加えます。 まず、アーティファクトを使用するためにアーティファクト拡張機能を購入する必要がなくなりました。 これで、成果物ライセンスの使用が基本ライセンスに含まれるようになります。 基本ライセンスが割り当てられているすべてのユーザーは、アーティファクトを使用できるようになります。 第 2 に、お客様はリリース管理デプロイ パイプラインを購入する必要がなくなりました。 ビルド パイプラインと同様に、リリース管理デプロイ パイプラインは Azure DevOps Server 2019 に含まれるようになりました。

Azure SQL Database のサポート

Azure で Azure DevOps 2019 を実行するエクスペリエンスを簡略化するために、Azure SQL Database (General Purpose S3 以降) のサポートを有効にしました。 これにより、広範なバックアップ機能スケール オプションを利用してサービスを実行する管理オーバーヘッドを削減しながら、ニーズに合わせて使用できます。 待機時間を短く保つために、ホスト VM はデータベースと同じ Azure リージョンに配置する必要があることに注意してください。 詳細については、ドキュメントを参照してください。

作業項目とテスト クライアント オブジェクト モデルの SOAP API (将来のバージョン)

Azure DevOps Server 2019 では、作業項目追跡 SOAP API とクライアント オブジェクト モデルが引き続きサポートされます。 ただし、今後のバージョンの Azure DevOps Server では非推奨としてマークされます。 詳細については、 ドキュメントを参照してください。

新しいコレクションの継承を処理する

プロセスの継承が新しいコレクションで使用できるようになりました。 ユーザーは、新しいコレクションを作成するときに、プロセス モデルに関して良心的な決定を行う必要があります。 継承モデル XML との違いについては、ドキュメントを参照してください。

拡張された検索ボックス

検索の重要性を理解し、製品ヘッダーの展開された検索ボックスを取り戻しています。 さらに、Azure DevOps の任意のサービス ページで [/] をクリックするだけで、検索ボックスを呼び出すようになりました。

既定の検索ボックスを次に示します。

"/" を入力すると、展開された検索ボックスが表示されます。

作業ポップアップ

私たちが紹介する新しい機能は、 私の仕事 ポップアップです。 製品の一部に参加していて、別の部分からの情報が必要な場合は、コンテキストを失いたくないというフィードバックが寄せられます。 この新機能を使用すると、製品のどこからでもこのポップアップにアクセスでき、作業項目、プル要求、すべてのお気に入りなどの重要な情報をすばやく確認できます。 この新しいポップアップを使用すると、 Repos コード内で頭を下げて、次に作業する作業項目をすばやく確認したい場合は、ポップアップをクリックして割り当てられた作業項目を表示し、次の項目を選択するだけです。

以下に、自分に割り当てられている作業項目を示す 作業 ポップアップが表示されます。

ここでは、自分に割り当てられている PR を示す 2 番目のピボットを確認できます。 ポップアップでは、1 回のクリックでアクセスして、さらにプル要求を表示することもできます。

ここでは、最後のピボットを確認できます。これは、お気に入りのすべてです。 これには、お気に入りのチーム、ダッシュボード、ボード、バックログ、クエリ、リポジトリが含まれます。

Boards

GitHub Enterprise のコミットと pull request を Azure Boards の作業項目にリンクする

コードに GitHub Enterprise を使用し、豊富なプロジェクト管理機能が必要な Teams は、リポジトリを Azure Boards と統合できるようになりました。 GitHub と Azure Boards を 接続することでバックログ、ボード、スプリント計画ツール、複数の作業項目の種類などのすべての機能を取得し、GitHub の開発者ワークフローと統合するワークフローを持つことができます。

コミットとプル要求を作業項目にリンクするのは簡単です。 次の構文を使用して作業項目をメンションします。

AB#{work item ID}

コミット メッセージ、pull request タイトル、またはプル要求の説明で作業項目をメンションすると、Azure Boards によってその成果物へのリンクが作成されます。 たとえば、次のようなコミット メッセージを考えてみましょう。

Adds support for deleting connections. Fixes AB#20.

これにより、作業項目 #20 から GitHub のコミットへのリンクが作成され、作業項目の開発セクションに表示されます。 ​

"fix"、"fixs"、または "fixed" という単語が (上に示すように) 作業項目メンションの前にある場合、コミットが既定のブランチにマージされるときに、作業項目は完了状態に移動されます。

Azure Pipelines を使用して GitHub でコードをビルドしているチームには、ビルドの概要に GitHub コミットにリンクされている作業項目も表示されます。

新しい作業項目ハブ

作業項目ハブは、作業項目のホームとして機能する新しいハブです。 ここでは、作業項目のさまざまなリスト ビューを対象範囲として表示します。 割り当て済みを表示すると自分に割り当てられているすべての作業をすばやく確認したり、更新最近更新されたすべての作業項目を表示したりできます。 すべてのリスト オプションを次に示します。

リストをさらに絞り込む場合は、種類、割り当て先、状態、領域、タグ、キーワードをフィルター処理できます。 目的のリスト ビューを作成したら、列のヘッダーをクリックするだけで作業項目を並べ替えることができます。 1 つの列が狭すぎて列の完全な内容を表示できない場合は、ヘッダー領域の列のサイズを簡単に変更できます。 これらのエクスペリエンスを次に示します。

新しいボード、バックログ、スプリント ハブ

Backlogs ハブは、ユーザー エクスペリエンスを向上させるために 3 つの異なるハブに分割されました。 強力ですが、古い Backlogs ハブには多すぎる機能が含まれています。 多くの場合、ユーザーが探していた機能を見つけるのが困難になりました。 この問題に対処するために、Backlogs ハブを次の内容に分割しました。

• Backlogs ハブには、プロジェクトのバックログだけが含まれるようになりました。 バックログは、チームの作業の優先順位付けされた一覧です。 バックログには、作業項目階層、予測、新しいスプリント計画エクスペリエンスなどの計画ツールが用意されています。
• 新しい Boards ハブには、プロジェクトのすべてのかんばんボードがあります。 ボードは、状態とフローを伝えるために使用されます。 カード (作業項目) は、チームによって定義された列を通じて、ボード全体で左から右に移動します。
• 新しい Sprints ハブには、作業の増分を計画および実行するために使用される機能があります。 各スプリントには、スプリント バックログ、タスクボード、およびチームの容量を管理および設定するためのビューが含まれています。

新しいクエリ ハブ

新しいクエリ ハブは、古いハブの既存のクエリ機能の多くをよりモダンな外観で効率化するだけでなく、重要なクエリに簡単にアクセスできるようにする新機能を提供します。 新しいエクスペリエンスのハイライトには、次のようなものがあります。

• 情報によって最後に変更されたディレクトリ ページとクエリを検索する機能
• クエリの重要なグループをブックマークするフォルダーの一意の URL を持つ階層リンク
• 結果ページからお気に入りのクエリにすばやくアクセスする

これらのエキサイティングな更新プログラムの詳細については、 DevOps ブログを参照してください。

作業項目を別のプロジェクトに移動し、作業項目の種類を変更する

作業項目の種類 変更したり 作業項目を 移動したり プロジェクト コレクション内の別のプロジェクトに移動したりできるようになりました。 これらの機能を使用するには、データ ウェアハウスが無効になっている必要があります。 データ ウェアハウスが無効になっているときは、Analytics サービスを使ってレポートのニーズをサポートできます。 データ ウェアハウスを無効にする方法の詳細については、「データ ウェアハウスとキューブを無効にする」を参照してください。

スプリント計画の機能

新しいスプリント計画機能は、スプリント計画エクスペリエンスの迅速化と向上に役立ちます。

• 次のスプリントを作成するか、 Sprints ハブから直接既存のスプリント スケジュールにサブスクライブします。
• バックログの新しい Planning ペインを使用して、作業項目を将来のスプリントにドラッグ アンド ドロップします。 [ 計画 ] ウィンドウには、スプリント日付、作業項目数、計画作業が含まれます。
• Taskboard の上部に要件を追加するかクイック作成を使用して、スプリント バックログの上、下、または任意の行に追加します。
• 担当者、作業項目の種類、状態、タグのフィルターを使用して、ニーズに合わせてビューを調整します。

新しいディレクトリ ページ

Backlogs、Boards、Sprints などすべての新しいハブに、次のセクションで整理された新しいディレクトリ ページが追加されました。

• 中断したところから続行します この新しいセクションでは、最後のセクション (ボード |バックログ |スプリント) をオンにしていました。
• お気に入り すべてのチームでお気に入りのボード、スプリント、バックログ。
• My 所属するチームのすべてのボード、バックログ、スプリント。
• [すべて すべてのボード、バックログ、スプリントの完全なリスト。

[新しい表示オプション] メニュー

Backlogs、Boards、Sprints など、新しいハブには、新しい View オプション メニューがあります。 これは、レイアウトとページコンテンツをカスタマイズするためのすべてのアクションのための新しいホームです。 ビュー オプションを使用して、バックログでの階層の表示やタスクボードの Group By オプションの変更などの追加のビューを有効にして、スプリントのマッピングと計画のサイド パネルをオンにしたり、作業の詳細グラフを調査したりできます。

これらのエキサイティングな更新プログラム、新しいチーム プロファイル ウィンドウ、お気に入りの詳細については、 DevOps ブログを参照してください。

カード注釈には、バグとカスタム作業項目の種類が含まれます

カード注釈は、直感的なチェック リスト ビューと操作で愛されています。 以前は、カード注釈は既定のバックログ レベルの種類に制限されていましたが、バグやカスタムの種類はサポートされていませんでした。 新しいリリースでは、作業項目の種類に関する制限が削除され、バグとカスタム作業項目の種類をカード注釈として表示する機能が追加されました。

カード注釈のボード設定が拡張され、そのバックログ レベルで使用可能なすべての作業項目の種類が含まれます。

作業項目の注釈が有効になっている場合、その作業項目の種類のカウントは別のチェック リストとしてカードに含まれます。

有効な作業項目の種類のクイック作成は、カードのコンテキスト メニューでも使用できます。

Area と Iteration の候補を使用して作業項目を移動

同じエリアやイテレーションで作業していると、作業項目を移動する際に階層を何度も参照する必要があります。 Area と Iteration パス コントロールには、最近使用した値の一覧が Suggestions として含まれるようになり、設定して次に進むための簡単なアクセスが可能になりました。

また、日付が名前の右側に含まれるため、作業項目を配送するタイミングをすばやく判断できます。

+/- を使用してイテレーション スケジュール全体のクエリ作業を実行する @CurrentIteration

イテレーション スケジュールに基づいてチームが作業を追跡するのに役立つ @CurrentIteration マクロで、整数オフセットがサポートされるようになりました。 @CurrentIteration - 1 で閉じられなかった作業に関するタブを簡単に保持するか、@CurrentIteration + 1 で将来のイテレーションに予定されている作業を先読みします。 詳細については、Microsoft DevOps ブログの @CurrentIteration投稿 を参照してください。

@CurrentIteration Team パラメーターを使用してクエリイテレーション スケジュールを明確にする

過去にクエリで @CurrentIteration マクロを使用していた場合、イテレーション スケジュールが異なる Teams 間でチーム コンテキストが変更された場合、結果が異なる場合があることに気付いた可能性があります。 ここで、 @CurrentIteration マクロを使用してクエリを作成または変更するときに、クエリに関連するイテレーション スケジュールを持つチームも選択する必要があります。 Team パラメーターを使用すると、 @CurrentIteration マクロを同じクエリで使用できますが、チーム間で使用できます。 1 つの例として、異なるイテレーション名とスケジュールを使用する 2 つの異なるチーム プロジェクトの作業項目のクエリがあります。 つまり、スプリントの変化に合わせ、クエリを更新する必要がなくなります。 詳細については、Microsoft DevOps ブログの @CurrentIteration投稿 を参照してください。

新しい @TeamAreas マクロを使用してチームのエリア パスでクエリを実行する

チームの設定では、1 つ以上のエリア パスを関連付けることができます。これにより、 Backlogs、 Boards、 Plans、 Dashboards をそのチームの作業だけに集中させることができます。 ただし、チームのクエリを記述する場合は、クエリ句でそのチームの特定のエリア パスを一覧表示する必要がありました。 これで、新しい @TeamAreas マクロを使用して、指定したチームに所有されているエリア パスを簡単に参照できるようになりました。

空のリッチ テキスト フィールドのクエリ

新しい IsEmpty クエリ演算子を使用して、Description などの空のリッチ テキスト フィールドを持つ作業項目を検索します。

リンクとメンションエクスペリエンスで既存の作業項目を簡単に見つける

既存の 2 つの作業項目をリンクする場合、新しい作業項目検索コントロールを使用して、重要な項目を簡単に見つけることができます。 クエリ セレクターは、最近アクセスした作業項目に基づくインライン候補と、ID またはタイトルで特定の作業項目を検索するためのエントリ ポイントに置き換えられました。

検索から作業項目を開く

以前は、作業項目のプレビュー ウィンドウがオフになっている場合、検索結果ページから作業項目を開くことができませんでした。 これにより、検索結果を調べるのが難しくなります。 作業項目のタイトルをクリックして、モーダル ウィンドウで作業項目を開くことができます。

Repos

改善されたブランチ ピッカー

Azure Repos のエクスペリエンスのほとんどはリポジトリとそのリポジトリ内のブランチを選択する必要があります。 多数のブランチを持つ組織でこのエクスペリエンスを向上させるために、新しいブランチ ピッカーをロールアウトしています。 ピッカーを使用して、お気に入りのブランチを選択したり、ブランチをすばやく検索したりできるようになりました。

プル要求ポリシーがバイパスされたときに通知を受信する

プル要求 (PR) ポリシーと ブランチ ポリシーを使用するチームの場合、ユーザーがこれらのポリシーをオーバーライドしてバイパスする必要がある場合があります(たとえば、夜間に運用環境の問題に修正プログラムを展開する場合など)。 開発者が適切な操作を行い、オーバーライド機能を慎重に使用することを信頼することは理にかなっています。 同時に、チームは、これらのポリシーオーバーライドが適切な状況で使用されていることを確認する方法が必要です。 これをサポートするために、ポリシーがバイパスされるたびにユーザーとチームが電子メール アラートを受信できるように、新しい通知フィルターが追加されました。 最初に、 A プル要求が作成または更新 テンプレートで、フィルターの一覧から Policy Bypass を選択します。 値として ポリシーがバイパスされた を選択すると、PR が完了するたびに通知され、ポリシーがバイパスされます。

プッシュ保護を終了せずにブランチ ポリシーのバイパスを許可する

ブランチ ポリシーをバイパスする必要があるシナリオは多数あります。ビルドの中断の原因となった変更の元に戻す、深夜に修正プログラムを適用するなどです。以前は、プル要求の完了時にブランチ ポリシーをバイパスする機能を付与されたユーザーをチームが管理できるように、アクセス許可 ("ポリシーの適用から除外") を提供しました。 ただし、そのアクセス許可には、PR プロセスを完全にバイパスして、ブランチに直接プッシュする機能も付与されました。

このエクスペリエンスを向上させるために、古いアクセス許可を分割して、バイパスアクセス許可を付与しているチームにより多くの制御を提供しました。 古いアクセス許可を置き換える新しいアクセス許可が 2 つあります。

1. [Bypass policies when completing pull requests](pull request 完了時にポリシーをバイパス)。 このアクセス許可を持つユーザーは、pull request に対して "オーバーライド" 操作を使用できます。
2. [Bypass policies when pushing](プッシュ時にポリシーをバイパス)。 このアクセス許可を持つユーザーは、必要なポリシーが構成されているブランチに直接プッシュできます。

最初のアクセス許可を付与し、2 つ目のアクセス許可を拒否することで、ユーザーは必要に応じてバイパス オプションを使用できますが、ポリシーを使用して誤ってブランチにプッシュすることを防ぎます。

詳細については、 Set ブランチのアクセス許可 ドキュメントを参照してください。

コミット メッセージを使用してプル要求をすばやく記述する

記述コミット メッセージを記述すると、Git リポジトリの履歴に価値が追加されます。 品質コミット メッセージを促進するために、複数のコミットを持つ新しいプル要求 (PR) では、共同作成者がタイトルを手動で入力する必要があります。

プル要求の説明は既定では引き続き空ですが、新しい機能により、PR コミットのコミット メッセージを PR の説明に簡単に組み込むことができます。 コミット メッセージを追加するには、 [コミット メッセージの追加] をクリックして PR の説明テキストの末尾にコミット メッセージを追加します。

レビュー担当者として既定のチームを使用せずに pull request を作成する

プル要求 (PR) エクスペリエンスを初めて開始したとき、PR の作成時に選択したチーム コンテキストにすべての PR を割り当てることが理にかなっていると考えました。 多くの人がチーム コンテキストと PR 割り当ての間の接続に気付かなかったため、この動作は不満の点でした。

新しいナビゲーションの変更の一環として、この既定のチームとの関連付けを変更する機会を得ました。 次の 2 つの変更が表示されます。

1. PR を作成する場合、レビュー担当者は既定で追加されません。 レビュー担当者の一覧には、最近 PR に追加された個人やグループを簡単に追加できる機能があります。 レビュー担当者ポリシーは、特定の校閲者を確実に追加してコードをレビューするチームにも役立ちます。
2. Pull Requests ハブには、新しいカスタマイズ可能なセクションがあります。 既定では、このセクションには "自分のチームに割り当てられている" PR が表示され、以前のセクションと同等の機能が提供されます。 ただし、複数のチームに属している場合、このセクションにはいずれかのチームに割り当てられている PR が表示されます。 セクションもカスタマイズ可能です。セクション ヘッダーの近くにある [このビューのカスタマイズ] アクションをクリックするだけです。

テンプレートを使用して pull request の説明を標準化する

適切な pull request の説明を記述することは、レビュー担当者がコードをレビューするときに期待する内容を把握するのに役立つ優れた方法です。 また、テスト、単体テストの追加、ドキュメントの更新など、すべての変更に対して行う必要のある作業を追跡するのに役立つ優れた方法でもあります。 多くのユーザーは、チームが優れた説明を簡単に記述できるように pull request テンプレートを追加することを要求しており、その機能が追加されました。

既定の PR 説明テンプレートをサポートするだけでなく、チームは複数のテンプレートを追加できます。このテンプレートは、[PR の作成] ページのメニューに表示されます。 テンプレートの追加ボタンをクリックして、リポジトリ内の任意のテンプレートから選択し、PR の説明に追加します。

ブランチ固有のテンプレートは、PR 用の別のテンプレートを特定のブランチまたはブランチ フォルダーに適用する場合にもサポートされます。 たとえば、"修正プログラム/" で始まるすべてのブランチに固有のテンプレートを作成する場合は、すべての PR に使用されるテンプレートをそれらのブランチに追加できます。

テンプレートを作成して使用する方法の詳細については、 pull 要求テンプレート ドキュメントを参照してください。

pull request のターゲット ブランチを変更

ほとんどのチームでは、ほぼすべてのプル要求が同じブランチ ( main や developなど) を対象とします。 ただし、別のブランチをターゲットにする必要がある場合は、ターゲット ブランチを既定から変更することを忘れるのは簡単です。 アクティブなプル要求のターゲット ブランチを変更する新機能により、これは単純なアクションになりました。 プル要求ヘッダーのターゲット ブランチ名の近くにある鉛筆アイコンをクリックするだけです。

間違いを修正するだけでなく、ターゲット ブランチを変更する機能により、ターゲット ブランチがマージまたは削除されたときに pull request を "再ターゲット" することも簡単になります。 変更が依存している機能を含む機能ブランチを対象とする PR があるシナリオを考えてみましょう。 依存する変更を、機能ブランチの他の変更とは切り離して確認する必要があるため、最初はfeatures/new-featureを対象とします。 その後、レビュー担当者は自分の変更のみを確認し、適切なコメントを残すことができます。

ここで、機能ブランチも PR がアクティブで、変更前にmainにマージされた場合はどうなりますか。 以前は、変更を破棄して新しい PR を main に作成するか、PR を features/new-feature にマージしてから、 features/new-feature から main に別の PR を作成する必要があります。 ターゲット ブランチを更新するこの新しいアクションを使用すると、PR のターゲット ブランチを features/new-feature から main に変更するだけで、すべてのコンテキストとコメントを保持できます。 ターゲット ブランチを変更すると、PR に対する新しい更新も作成されるため、ターゲット ブランチが変更される前の差分を簡単に確認できます。

拡張作成者は現在のリポジトリに関するコンテキストをクエリできる

バージョン管理拡張機能の作成者にとっての課題の 1 つは、名前、ID、URL など、ユーザーに表示されるリポジトリのコンテキストを取得することです。 これを支援するために、拡張機能でアクセス可能なサービスとして VersionControlRepositoryService を追加しました。 これを使用して、拡張機能の作成者は、Web UI 内の現在の Git リポジトリ コンテキストに関する情報を照会できます。 現在、このメソッドには getCurrentGitRepository() という 1 つのメソッドがあります。

• Git リポジトリが選択されている場合、リポジトリに関する基本的なデータ (名前、ID、URL) を含む GitRepository オブジェクトが返されます。
• TFVC リポジトリが選択されているか、サービスが Azure Repos ページの外部でアクセスされている場合、null が返されます。

このサービスを使用する サンプル拡張機能 を次に示します。

Pipelines

新しい [ビルド] ページを使用してビルド パイプラインを管理する

いくつかの機能強化を行い、 Builds ページの新しいバージョンをロールアウトしています。 この新しいバージョンでは、すべてのビルド パイプラインのディレクトリと現在のビルドの一覧が結合されるため、プロジェクトのビルド間をすばやく移動して状態を確認できます。 また、選択したパイプラインのテスト分析のプレビューも含まれています。

改善された書式設定を使用してビルドとデプロイの完了メールをより適切に管理する

ビルドとデプロイの完了メールが、電子メール ルールでフィルター処理できるように更新されました。 これで、件名に一目で関連性の高い情報が含まれるようになり、本文に詳細が含まれるようになり、そのスタイルが最新のブランドで更新されました。

新しい形式の要素は次のとおりです。

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

次に例をいくつか示します。

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

新しい統合 Azure Pipelines の用語に従う

ビルドとリリースを通じて、似た概念のためにさまざまな用語が歴史的に使用されてきました。 他のケースでは、用語の意味はあいまいでした。 たとえば、 agent プール と agent キューの違いを示。

用語は、その概念を明確にするために Azure Pipelines で統一されています。 次の統一された用語が表示されます。

従来の用語	統一された用語	意味
ホストされたエージェント	Microsoft によってホストされるエージェント	Microsoft によって管理されるクラウドでホストされるインフラストラクチャ上で実行されるビルド/リリース エージェント。
プライベート エージェント	自己ホスト エージェント	ユーザーが提供および管理するコンピューター上で実行されるビルド/リリース エージェント。
エージェント プール	エージェント プール	ビルドまたはリリースを実行できるエージェント マシンの組織レベルのセット。
エージェント キュー	エージェント プール	ビルドまたはリリースを実行できるエージェント マシンのプロジェクト レベルのセット。 これは、組織レベルのエージェント プールにリンクされています。
ビルド定義	ビルド パイプライン	アプリケーションのビルド ステップのエンド ツー エンドセット。
ビルド	ビルド	実行中または実行済みのビルド パイプラインのインスタンス。
フェーズ	ジョブ	エージェントで順次または並列に実行される一連のタスク。 ビルドまたはリリース パイプラインには、1 つのジョブまたは複数のジョブのグラフを含めることができます。
リリース定義	リリース パイプライン	さまざまなステージにまたがってアプリケーションをデプロイするための、エンド ツー エンドのリリース手順のセット。
リリース	リリース	実行中または実行済みのリリース パイプラインのインスタンス。
環境	段階	リリース パイプラインから生成されたリリースをデプロイする場所を表す論理エンティティと独立エンティティ。
同時実行ジョブ/パイプライン	並列ジョブ	並列ジョブを使用すると、組織内で一度に 1 つのビルドジョブまたはリリース ジョブを実行できます。 使用可能な並列ジョブが増えるので、より多くのビルド ジョブとリリース ジョブを同時に実行できます。
サービス エンドポイント	サービス接続	ビルドまたはリリースでタスクを実行するために外部サービスに接続するために使用される設定のグループ (資格情報など)。

詳細については、 Concepts ドキュメントを参照してください。

新しい [リリース] ページを使用してリリース パイプラインを管理する

リリースランディングページでは、新しく完全に再設計されたユーザー エクスペリエンスを利用できます。 左側で頻繁にリリースするリリース パイプラインの一覧を参照してください。 パイプラインを検索してお気に入りに追加することもできます。

フォルダー ビューに変更して、組織とセキュリティ用のフォルダーを作成します。 セキュリティはフォルダー レベルで設定できます。

リリースの進行状況を視覚化する

新しいリリースの進行状況ビューには、デプロイの進行状況のライブ更新と、詳細へのワンクリック アクセスが表示されます。 新しいビューではリリース パイプラインが視覚化されるため、何が起こっているかを理解しやすくなり、リリースのさまざまな段階で適切な詳細とアクションが表示されます。

パイプライン、リリースの詳細、環境

Pipeline ビューには、リリースの成果物と、それらがデプロイされる環境が表示されます。 Release 領域には、リリース トリガー、成果物のバージョン、タグなどのリリースの詳細が表示されます。

環境は、その状態と詳細な進行状況を理解するのに役立つ方法でモデル化されます。 環境内の状態リンクをクリックすると、いつでもログにアクセスできます。

デプロイ前とデプロイ後

環境に対してデプロイ前またはデプロイ後の条件が設定されている場合は、承認とゲートが存在する環境に示されます。 承認とゲートの進行状況は、環境の状態にも表示されます。 環境の右側または左側にある環境の条件アイコンをクリックして、アクションを実行したり、詳細を表示したりできます。

コミットと作業項目

環境をクリックすると、新しいリリースごとに、関連付けられているコミットと作業項目の一覧を環境ごとに個別に確認できます。 一覧が長い場合は、フィルターを使用して、関心のあるコミットまたは作業項目を見つけます。

デプロイの進行状況とログ

環境には、完了したフェーズとタスクの数や実行時間など、進行中のデプロイのライブ更新が表示されます。 環境の状態をクリックすると、ログを含むビューが開き、現在アクティブになっている内容がフォーカスされます。

ログをクリックして、フォーカスされたビューを入力できます。

タスクに対する Azure DevOps Server 2019 へのアップグレードの影響: ターゲット コンピューター上の Windows マシン ファイル コピーと PoweShell

テスト ハブの下のマシン グループは、TFS 2017 RTM で定義済みでした。 Azure DevOps Server 2019 では、マシン グループ サービスは使用できなくなります。 これは、'Windows マシン ファイル コピー' タスク バージョン 1.* および 'ターゲット マシン上の PowerShell' タスク バージョン 1.* のユーザーに影響します。 パイプラインが動作し続けるには、

• "Windows マシン ファイル コピー" タスク バージョン 2.* に切り替え、マシン名だけでなく、ターゲット コンピューターの完全な fqdn を指定する必要があります。
• また、'ターゲット マシン上の Powershell' タスク バージョン 2.* 以降に切り替え、コンピューターまたはコンピューター名の完全な fqdn の後に Windows リモート管理ポート (http/https) を指定します。 たとえば、targetMachine:5985 や targetMachine:5986 などです。

テスト結果と拡張性

テスト実行の結果も環境ごとに表示されます。 テスト結果をクリックすると、プロセスに貢献する他の拡張機能からの結果を含むテストの詳細を含むビューが開きます。

既存の拡張機能は、この新しいビューで機能します。また、拡張機能を開発して環境に関するさらに多くの情報を表示できるようにするための新しい拡張ポイントもあります。 詳細については、 説明と拡張機能 ドキュメントを参照してください。

YAML を使用してビルドを構成する

YAML ベースのビルド パイプラインは、Azure DevOps Server で使用できます。 リポジトリにチェックインされた YAML ファイルを使用して、継続的インテグレーション パイプラインを自動化します。 YAML スキーマの完全なリファレンスについては、 こちらを参照してください。

YAML ベースのビルド パイプラインをよりシームレスにサポートするために、作成するすべての新しいリソース (サービス接続、変数グループ、エージェント プール、セキュリティで保護されたファイルなど) の既定の動作を、そのプロジェクトのすべてのパイプラインで使用できるように変更しました。 リソースをより厳密に制御する場合は、既定の承認モデルを無効にすることができます (下の図を参照)。 その場合、リソースを使用するアクセス許可を持つユーザーは、リソース参照が YAML ファイルに追加された後、Web エディターにパイプラインを明示的に保存する必要があります。

ビルド完了トリガーを使用して関連ビルドを連結

大規模な製品には、相互に依存する複数のコンポーネントがあります。 多くの場合、これらのコンポーネントは個別に構築されます。 アップストリーム コンポーネント (ライブラリなど) が変更された場合、ダウンストリームの依存関係を再構築して再検証する必要があります。 通常、このような依存関係は手動で管理されています。

このたび、ビルドの正常な完了時に別のビルドをトリガーできるようになりました。 アップストリーム ビルドによって生成された成果物は、後のビルドでダウンロードして使用できます。また、Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName の変数からデータを取得することもできます。 詳細については、 ビルド トリガー ドキュメントを参照してください。

場合によっては、1 つの マルチフェーズ ビルド がニーズを満たす可能性があることに注意してください。 複数の構成設定やオプションを設定している場合や、依存するプロセスを別のチームが所有している場合などには、ビルド完了トリガーを使用するのが便利です。

エージェントをローカルで更新する

ギャラリーからインストールするタスクには、新しいバージョンのパイプライン エージェントが必要な場合があります。 Azure DevOps Server がインターネットに接続できる場合は、新しいバージョンが自動的にダウンロードされます。 そうでない場合は、各エージェントを手動でアップグレードする必要があります。 このリリース以降、インターネットではなくローカル ディスク上のエージェント パッケージ ファイルを検索するように Azure DevOps Server を構成できます。 これにより、Azure DevOps Server をインターネットに公開することなく、使用できるエージェントのバージョンを柔軟に制御できます。

新しいビルドステータスバッジの URL

リポジトリのホームページに埋め込まれたビルド バッジは、リポジトリの正常性を示す一般的な方法です。 これまではビルド バッジがありましたが、いくつかの問題がありました。

• URL が直感的ではなかった
• バッジはブランチに固有のものではありません
• ユーザーがバッジをクリックして、その定義の最新のビルドにユーザーを連れて行く方法はありませんでした

現在、これらの問題を解決するビルド バッジ用の新しい API をロールアウトしています。 新しい API を使用すると、ユーザーはブランチごとの状態を発行でき、選択したブランチの最新のビルドにユーザーを連れて行くことができます。 新しいステータス バッジ URL の Markdown を取得するには、新しい Builds ページ で Status バッジメニュー アクション選択。

下位互換性のために、以前のビルド バッジ URL も引き続き受け入れます。

ビルドにカスタム ビルド カウンターを追加

ビルド カウンターは、ビルドに一意に番号を付け、ラベルを付ける方法を提供します。 以前は、$(rev:r) 特殊変数を使用してこれを実現できました。 ビルドを実行するたびに自動インクリメントされる独自のカウンター変数をビルド定義で定義できるようになりました。 これは、定義の [変数] タブで行います。 この新機能により、次の方法でより多くの機能が提供されます。

• カスタム カウンターを定義し、そのシード値を設定できます。 たとえば、カウンターは 100 から開始できます。 $(rev:r) は常に 0 から始まります。
• 独自のカスタム ロジックを使用して、カウンターをリセットできます。 $(rev:r) はビルド番号の生成に関連付けられており、ビルド番号に新しいプレフィックスがある場合は常に自動リセットされます。
• 定義ごとに複数のカウンターを定義できます。
• ビルドの外部にあるカウンターの値を照会できます。 たとえば、カウンターを使用して最後のリセット以降に実行されたビルドの数をカウントできます。

ビルド カウンターの詳細については、 ユーザー定義変数 に関するドキュメントを参照してください。

Pipelines における Azure Policy コンプライアンスとセキュリティの検証

開発、セキュリティ、運用を一緒にしながら、開発プロセスの早い段階でソフトウェアの安定性とセキュリティを確保したいと考えています。 これを行うために、 Azure Policy のサポートが追加されました。

Azure Policy では、リソースに対してルールと効果を適用するポリシー定義によって IT の問題を管理および防止できます。 Azure Policy を使用する場合、リソースは会社の標準とサービス レベルアグリーメントに準拠し続けます。

リリース プロセスの一環として、コンプライアンスとセキュリティのガイドラインに準拠するために、Azure リソース グループのデプロイ エクスペリエンスが強化されました。 これで、ARM テンプレートのデプロイ中に違反が発生した場合に、関連するポリシー関連のエラーで Azure リソース グループのデプロイ タスクが失敗します。

さらに、Azure Policy リリース定義テンプレートが追加されました。 これにより、ユーザーは Azure ポリシーを作成し、リリース定義自体からリソース、サブスクリプション、または管理グループにこれらのポリシーを割り当てることができます。

Linux/ARM および Windows 32 ビット プラットフォーム上にビルド

Azure Pipelines オープンソース、クロスプラットフォーム エージェントは、常に 64 ビット (x64) Windows、macOS、Linux でサポートされています。 このリリースでは、 Linux/ARM と Windows/32 ビットの 2 つの新しいサポートされるプラットフォームが導入されています。 これらの新しいプラットフォームを使用すると、Linux/ARM マシンである Raspberry Pi などのあまり一般的ではありませんが、重要ではないプラットフォームを基に構築できます。

パイプラインでのテストのエクスペリエンスの向上

[テスト] タブ には、 Pipelines のコンテキスト内の豊富なテスト情報を提供する最新のエクスペリエンスが追加されました。 新しいエクスペリエンスでは、進行中のテスト ビュー、完全なページ デバッグ エクスペリエンス、コンテキスト テスト履歴、中止されたテスト実行のレポート、実行レベルの概要が提供されます。

進行中のテストの実行を表示する

統合テストや機能テストなどのテストは長時間実行される可能性があるため、特定の時点でテストの実行を確認することが重要です。 進行中のテスト ビューでは、テストの実行が完了するまで待機してテスト結果を把握する必要がなくなりました。 結果は、実行時にほぼリアルタイムで利用でき、迅速なアクションの実行に役立ちます。 エラーのデバッグや中止、バグの報告、パイプラインの中止を行うことができます。 この機能は、現在、マルチ エージェント フェーズで VS テスト タスク を使用するビルドパイプラインとリリース パイプラインの両方で使用できます。また、 Publish テスト結果タスクを使用するか API を使用してテスト結果を発行します。 今後は、単一エージェントを使用してテストを実行するために、このエクスペリエンスを拡張する予定です。

次のビューは、新しいリリースの進行状況ビューの進行中のテストの概要を示し、特定の時点でのテストの合計数とテスト失敗の数を報告します。

上記の進行中のテストの概要をクリックすると、テストの詳細な概要と、 Test Plansで失敗または中止されたテスト情報を表示できます。 テストの概要は定期的に更新され、新しい結果の可用性に基づいて、必要に応じて詳細ビューを更新できます。

テスト実行のデバッグの詳細を完全なページで表示する

エラー メッセージとスタック トレースは本質的に長く、デバッグ中に詳細を表示するのに十分な不動産が必要です。 イマーシブ デバッグ エクスペリエンスを実現するために、テストまたはテストの実行ビューをフル ページ ビューに拡張しながら、バグの作成や現在のテスト結果の要件の関連付けなどのコンテキスト操作で必要な操作を実行できるようになりました。

コンテキスト内でのテスト履歴の表示

これまで、チームはテスト結果の履歴を表示するために Runs ハブに移動する必要があります。 新しいエクスペリエンスにより、ビルドとリリース用の Test Plans タブ内のコンテキストでテスト履歴が正しく表示されます。 テスト履歴情報は、選択したテストの現在のビルド定義または環境から順に段階的に提供され、その後、ビルドとリリースの他のブランチと環境がそれぞれ提供されます。

中止されたテストを表示する

テストの実行は、不適切なテスト コード、テスト対象のソース、環境の問題など、複数の理由により中止される可能性があります。 中止の理由に関係なく、動作を診断し、根本原因を特定することが重要です。 中止されたテストとテストの実行を、 Test Plans の完了した実行と共に表示できるようになりました。 この機能は現在、マルチ エージェント フェーズで VS テスト タスク を使用するか、API を使用してテスト結果を発行して、ビルドとリリースの両方のパイプラインで使用できます。 今後は、単一エージェントを使用してテストを実行するために、このエクスペリエンスを拡張する予定です。

テスト履歴でのテストの追跡可能性とリリース環境のサポート

テストが実行されるさまざまなリリース環境によってグループ化された自動テストの履歴を表示するためのサポートが追加されています。 リリース環境をリリース パイプラインまたはテスト環境としてモデル化し、このような環境間でテストを実行している場合は、テストが開発環境で成功しているが、統合環境では失敗しているかどうかを確認できます。 それが英語のロケールで渡されているが、トルコ語のロケールを持つ環境では失敗しているかどうかを調べることができます。 環境ごとに、最新のテスト結果の状態が表示され、その環境でテストが失敗した場合は、テストが失敗したリリースも見つかります。

要約されたテスト結果を確認する

テストの実行中に、テストによって、全体的な結果に寄与するテストの複数のインスタンスが生成される場合があります。 たとえば、エラーが原因で再実行されるテスト、他のテストの順序付けされた組み合わせで構成されるテスト (順序付けされたテストなど)、指定された入力パラメーター (データドリブン テスト) に基づいて異なるインスタンスを持つテストなどがあります。 これらのテストは関連しているため、個々のテスト結果に基づいて派生した全体的な結果と共に報告する必要があります。 この更新プログラムでは、リリースの Tests タブに階層として表示されるテスト結果の改善されたバージョンが導入されました。 例を見てみましょう。

前に、 VS テスト タスクで失敗したテストを再実行する機能を導入しました。 ただし、テストの最後の試行についてのみ報告しました。この機能の有用性はやや制限されています。 テスト実行の各インスタンスを試行として報告するように、この機能を拡張しました。 さらに、Test Management API では、階層的なテスト結果を発行してクエリを実行する機能がサポートされるようになりました。 詳細については、 Test results API ドキュメントを参照してください。

Pipelines でテスト分析を表示

時間の経過と共にテスト品質を追跡し、テスト資料を改善することは、正常なパイプラインを維持するための鍵となります。 テスト分析機能を使用すると、ビルドとリリース パイプラインのテスト データをほぼリアルタイムで可視化できます。 繰り返し発生する影響の大きい品質上の問題を特定することで、パイプラインの効率を向上させることができます。

さまざまな要素でテスト結果をグループ化したり、ブランチまたはテスト ファイルの主要なテストを識別したり、特定のテストにドリルダウンして傾向を表示したり、フラキネスなどの品質の問題を理解したりできます。

builds および release のテスト分析を以下のプレビューで表示します。

詳細については、こちら を参照してください。

複数のエージェントレス タスクを使用して定義を簡略化する

エージェントレス フェーズのタスクは、サーバーによって調整され、実行されます。 エージェントレス フェーズでは、エージェントやターゲット コンピューターは必要ありません。 エージェント フェーズとは異なり、定義内の各エージェントレス フェーズに追加できるタスクは 1 つだけです。 これは、プロセスに複数のエージェントレス タスクがある場合に複数のフェーズを追加する必要があり、定義が大きかったことを意味します。 この制限を緩和しました。これにより、エージェントレス フェーズで複数のタスクを維持できます。 同じフェーズのタスクは、エージェント フェーズの場合と同様に、順番に実行されます。 詳細については、 server フェーズ ドキュメントを参照してください。

リリース ゲートを使用して段階的に公開し、デプロイをフェーズ化する

リリース ゲートを使用すると、リリースを次の環境に昇格させる前に満たす必要があるアプリケーションの正常性基準を指定できます。 指定されたすべてのゲートは、デプロイの前またはデプロイ後に、すべてが成功するまで定期的に評価されます。 4 種類のゲートをすぐに使用でき、 Marketplace からさらにゲートを追加できます。 デプロイに必要なすべての条件が満たされたことを監査できます。 詳細については、リリース ゲートに関する文書を参照してください。

ゲートが一貫して成功するまでデプロイを保持する

リリース ゲートを使用すると、リリースが次の環境に昇格される前に、正常性基準の自動評価が可能になります。 既定では、すべてのゲートに対して 1 つのサンプルが成功した後にリリースが進行します。 ゲートが不安定で、正常に受信したサンプルがノイズである場合でも、リリースは進行します。 このような種類の問題を回避するために、リリースを構成して、進行する前の最小期間の正常性の整合性を確認できるようになりました。 実行時に、リリースにより、昇格を許可する前にゲートの連続した評価が成功することが保証されます。 評価の合計時間は"再評価の間の時間" に依存し、通常は構成された最小期間を超えます。 詳細については、ゲートを使用した Release デプロイ制御 ドキュメントを参照してください。

配置グループ内の新しいターゲットに自動的にデプロイする

以前は、新しいターゲットがデプロイ グループに追加されたとき、すべてのターゲットが同じリリースになるように手動デプロイが必要でした。 これで、新しいターゲットに最後に成功したリリースを自動的にデプロイするように環境を構成できるようになりました。 詳細については、 デプロイ グループ ドキュメントを参照してください。

ビルド後処理によってタグ付けされたビルドを継続的にデプロイする

継続的配置トリガーは、ビルドの完了時にリリースを作成します。 ただし、ビルドが後処理されることがあり、その処理が完了した後にのみビルドを解放する必要があります。 リリースのトリガー フィルターで、後処理中に割り当てられるビルド タグを利用できるようになりました。

リリース時に変数を設定する

リリース定義で、リリースの作成時に設定する変数を選択できるようになりました。

リリースの作成時に変数に指定された値は、そのリリースにのみ使用されます。 この機能は、下書き作成の複数の手順を回避し、下書きの変数を更新し、変数を使用してリリースをトリガーするのに役立ちます。

環境変数をタスクに渡す

CI/CD タスクの作成者は、task.jsonで新しいプロパティ showEnvironmentVariables を設定して、環境変数をタスクに渡すことができます。 これを行うと、ビルド エディターのタスクに追加のコントロールがレンダリングされます。 これは、 Powershell、 Cmd、および Bash タスクで使用できます。

これにより、次の 2 つのシナリオが可能になります。

• タスクには、変数名に大文字と小文字が保持された環境変数が必要です。 たとえば、上記の例では、タスクに渡される環境変数は "FOO" ではなく "foo" になります。
• これにより、シークレット値をスクリプトに安全な方法で渡すことができます。 エージェント上のオペレーティング システムは、引数を含むプロセスの呼び出しをログに記録できるため、シークレットを引数としてスクリプトに渡すことをお勧めします。

変数グループの複製

変数グループの複製のサポートが追加されました。 変数グループをレプリケートし、いくつかの変数を更新するだけの場合は、変数を 1 つずつ追加する面倒なプロセスを実行する必要はありません。 これで、変数グループのコピーをすばやく作成し、値を適切に更新して、新しい変数グループとして保存できるようになりました。

デプロイのリリース ゲートを無視する

リリース ゲートを使用すると、リリースが次の環境に昇格される前に、正常性基準の自動評価が可能になります。 既定では、リリース パイプラインは、すべてのゲートが同時に正常な場合にのみ進行します。 リリースを迅速化するときや手動で正常性を確認した後など、特定の状況では、承認者はゲートを無視し、そのゲートがまだ正常と評価されていない場合でも、リリースの進行を許可することができます。 詳細については、 リリース ゲート ドキュメントを参照してください。

pull request リリース トリガーを使用して追加のテストを実行する

pull request (PR) に基づいてビルドをトリガーし、しばらくの間、マージの前にそのクイック フィードバックを取得できました。 リリースの PR トリガーも構成できるようになりました。 リリースの状態はコード リポジトリにポストバックされ、PR ページに直接表示されます。 これは、PR ワークフローの一部として追加の機能テストまたは手動テストを実行する場合に役立ちます。

証明書を使用して認証するサービス プリンシパルによって Azure サービス接続を作成

認証用のサービス プリンシパルと証明書を使用して Azure サービス接続を定義できるようになりました。 証明書で認証するサービス プリンシパルが Azure サービス接続でサポートされるようになりました。これで、AD FS で構成された Azure Stackにデプロイできるようになりました。 証明書認証を使用してサービス プリンシパルを作成するには、 証明書で認証するサービス プリンシパルを作成する方法に関する記事を参照してください。

Azure App Service の配置でサポートされているパッケージから実行

Azure アプリ Service Deploy タスク (4.*) バージョンでは、RunFromPackage (以前は RunFromZip がサポートされるようになりました。

App Service では、msdeploy (別名 WebDeploy)、git、ARM など、ファイルをデプロイするためのさまざまな手法がサポートされています。 ただし、これらすべての手法には制限があります。 ファイルは wwwroot フォルダー (具体的には d:\home\site\wwwroot) の下に展開され、ランタイムはそこからファイルを実行します。

パッケージから実行を使用すると、個々のファイルを wwwroot にコピーする展開手順はなくなりました。 代わりに、zip ファイルをポイントするだけで、zip は読み取り専用のファイル システムとして wwwroot にマウントされます。 これにはいくつかの利点があります。

• ファイル コピー ロック問題のリスクを軽減します。
• 運用環境のアプリにデプロイできます (再起動が必要です)。
• アプリで実行されるファイルを確定できます。
• Azure アプリ サービスデプロイのパフォーマンスが向上します。
• 特に大規模な npm パッケージのツリーの JavaScript 関数の場合、コールド スタート時間を減らすことができます。

App Server 配置タスクを使用して Linux コンテナーを配置

Azure アプリ Service Deploy タスクの 4.* バージョンでは、Linux 上の Azure Functions への独自のカスタム コンテナーのデプロイがサポートされるようになりました。

Azure Functions の Linux ホスティング モデルは、Docker コンテナーに基づいており、パッケージ化とアプリ固有の依存関係の活用の点で柔軟性が高まります。 Linux 上の関数は、2 つの異なるモードでホストできます。

1. 組み込みのコンテナー イメージ: Function App コードを取り込み、Azure がコンテナー (組み込みイメージ モード) を提供および管理するため、Docker に関連する特定の知識は必要ありません。 これは、App Service Deploy タスクの既存のバージョンでサポートされています。
2. カスタム コンテナー イメージ: Linux 上の Azure Functions へのカスタム コンテナー イメージのデプロイをサポートするように App Service デプロイ タスクが強化されました。 関数に特定の言語バージョンが必要な場合や、組み込みイメージ内に用意されていない特定の依存関係や構成が必要な場合は、Azure Pipelines を使用して、カスタム イメージをビルドして Linux 上の Azure 関数にデプロイできます。

Xcode タスクで新たにリリースされた Xcode 10 をサポート

Apple の Xcode 10 リリースに合わせて、プロジェクトをビルドするように設定したり、Xcode 10 で具体的にテストしたりできます。 パイプラインでは、Xcode バージョンの matrix と並列でジョブを実行することもできます。 Microsoft がホストする macOS エージェント プールを使用して、これらのビルドを実行できます。 Azure Pipelines で Xcode を使用するための ガイド を参照してください。

Helm を使用して Kubernetes へのデプロイを効率化

Helm は、Kubernetes アプリケーションのインストールと管理を効率化するツールです。 この 1 年間で利用者やコミュニティの支持が急増しています。 Release の Helm タスクを使用して、Azure Container Service (AKS)またはその他の Kubernetes クラスターに Helm チャートをパッケージ化してデプロイできるようになりました。

Helm タスクの追加により、Helm ベースの CI/CD パイプラインをセットアップし、コンテナーを Kubernetes クラスターに配布できるようになりました。 詳細については、Kubernetes を使用した Azure Container Service への デプロイ ドキュメントを参照してください。

リリースで使用される Helm のバージョンを制御する

Helm ツール インストーラー タスクは、インターネットまたはツール キャッシュから特定のバージョンの Helm を取得し、エージェントの PATH (ホステッドまたはプライベート) に追加します。 このタスクを使用して、 .NET Core cli タスクなどの後続のタスクで使用される Helm のバージョンを変更します。 ビルド定義またはリリース定義の Helm Deploy タスクの前にこのタスクを追加すると、適切な Helm バージョンでアプリをパッケージ化してデプロイできます。 このタスクは、必要に応じて、Helm が機能するための前提条件である kubectl ツールのインストールにも役立ちます。

Azure Database for MySQL への継続的デプロイ

Azure の MySQL データベースをサービスとして Azure Database for MySQL に継続的にデプロイできるようになりました。 バージョン管理で MySQL スクリプト ファイルを管理し、PowerShell スクリプトではなくネイティブ タスクを使用して、リリース パイプラインの中で継続的デプロイを行うことができます。

強化された Windows リモート PowerShell ベースのタスクを使用する

新しく改良された Windows リモート PowerShell ベースのタスクを利用できます。 これらの機能強化には、いくつかのパフォーマンス修正が含まれており、ライブ ログとコンソール出力コマンド (書き込みホスト、書き込み出力など) がサポートされています。

ターゲット タスクの PowerShell (バージョン: 3.*): インライン スクリプトを追加したり、PSSession オプションを変更したり、"ErrorActionPreference" を制御したり、標準エラーで失敗したりできます。

Azure ファイル コピー タスク (バージョン: 2.*): GitHub の問題に対処する最新の AzCopy (v7.1.0) に付属。

GitHub Enterprise または外部 Git アーティファクトのブランチをフィルター処理する

GitHub Enterprise または外部 Git リポジトリからリリースするときに、リリースされる特定のブランチを構成できるようになりました。 たとえば、特定のブランチから運用環境に来るビルドのみをデプロイできます。

Go で構築されたアプリケーションをビルド

Go ツール インストーラー タスクを使用して、1 つ以上のバージョンの Go Tool をその場でインストールします。 このタスクは、プロジェクトで必要とされる Go Tool のバージョンを取得し、ビルド エージェントのパスに追加します。 プロジェクトに必要な Go Tool のバージョンを取得し、ビルド エージェントのパスに追加します。ターゲットに指定したバージョンの Go Tool が既にエージェントにインストールされている場合は、ダウンロードとインストールのプロセスをスキップします。

Go タスクは、依存関係のダウンロード、ビルド、またはアプリケーションのテストに役立ちます。 また、任意のカスタム Go コマンドを実行することもできます。

パイプラインでインラインまたはファイル ベースの Python スクリプトを実行する

新しい Python Script タスクにより、パイプラインでの Python スクリプトの実行が簡略化されます。 タスクはリポジトリ内の Python ファイル (.py) からスクリプトを実行するか、タスクの設定にスクリプトを手動で入力してパイプラインの一部として保存できます。 このタスクでは、パスで Python のバージョンが使用されます。または、使用する Python インタープリターへの絶対パスを指定できます。

改善された Xcode ビルドと xcpretty からのテスト出力を活用する

xcpretty は xcodebuild 出力の読みやすさを向上させ、JUnit 形式でテスト結果を生成します。 Xcode ビルド タスクは、ホストされている macOS エージェント上にあるように、エージェント コンピューターで使用できる場合に自動的に xcpretty を使用するようになりました。 xcpretty の出力は xcodebuild 出力とは異なり、詳細が少なくてもかまいませんが、ビルドごとに完全な xcodebuild ログを使用できるようにします。

Test Plans

デスクトップ アプリケーションの手動テストを実行するテスト ランナー (Azure Test Plans) クライアント

テスト ランナー (Azure Test Plans) クライアントを使用して、デスクトップ アプリケーションの手動テストを実行できるようになりました。 これは、Microsoft Test Manager から Azure Test Plans に移行するのに役立ちます。 こちら ガイダンスをご覧ください。 テスト ランナー クライアントを使用すると、手動テストを実行し、各テスト ステップのテスト結果を記録できます。 また、スクリーンショット、画像アクション ログ、オーディオ ビデオ録画などのデータ収集機能もあります。 テスト時に問題が見つかる場合は、テスト ランナーを使用して、テスト 手順、スクリーンショット、およびコメントがバグに自動的に含まれるバグを作成します。

テスト ランナー (Azure Test Plans) には、ランナーの 1 回限りのダウンロードとインストールが必要です。 次に示すように、 デスクトップ アプリケーションの実行 を選択します。

Artifacts

アップストリーム ソース

Azure DevOps Server 2019 では、Azure Artifacts フィードで利用できるアップストリーム ソースが大幅に更新されます。

• nuget.orgアップストリーム ソースは、以前の TFS リリースで作成された既存のフィードに追加できます。 アップグレードする前に注意する必要がある動作の変更など、フィードのパッケージの上にあるバナーを探して詳細を確認します。
• 他の Azure DevOps Server フィードをアップストリーム ソースとしてフィードに追加できます。つまり、フィードを介してそれらのフィードから NuGet パッケージと npm パッケージを使用できます。

また、Azure Artifacts に新しいロール "コラボレーター" も導入しました。 コラボレーターはアップストリーム ソースからパッケージを保存できますが、パッケージ パッケージをフィードに直接発行することはできません (たとえば、nuget publish を使用)。 これにより、信頼できるユーザーまたはビルド システムにパッケージの発行を制限しながら、エンジニアがアップストリーム ソースの新しいパッケージを使用できるようになります。

パッケージのフォロー

新しい Follow ボタンを使用して、すべてのパッケージに直接通知を設定する作業がさらに簡単になりました。 [フォロー] ボタンもリリース ビューと互換性があります。 ビューを使用してパッケージを確認しているときにパッケージをフォローすると、そのビューに昇格された新しいバージョンの更新プログラムのみが取得されます。

手動で保存しなくてもフィード設定を変更する

フィード設定ページの操作の一部が改善されました。 これで、アップストリームやアクセス許可の追加など、行った変更がすぐに保存されます。 つまり、設定ピボットを切り替えるときに、変更を失うことを心配する必要はありません。

新しいクロスプラットフォームの Credential Provider for NuGet を使用して認証を簡単にする

認証された NuGet フィードとの対話が大幅に向上しました。 新しい .NET Core ベースの Azure Artifacts Credential Provider は、Windows、macOS、Linux 上の msbuild、dotnet、nuget(.exe) で動作します。 Azure Artifacts フィードのパッケージを使用する場合、資格情報プロバイダーは、使用している NuGet クライアントに代わってトークンを自動的に取得して格納します。 構成ファイルにトークンを手動で格納して管理する必要がなくなりました。

新しいプロバイダーを入手するには、 GitHub にアクセスし、クライアントとプラットフォームの指示に従います。

ファイル共有に公開するときにシンボルを圧縮する

インデックスとシンボルの発行タスクを更新しシンボルがファイル共有に発行されたときの圧縮をサポートしました。

Wiki

Git リポジトリからマークダウン ファイルを Wiki として公開

開発者は、「API」、「SDK」、「コードを説明するヘルプ ドキュメント」などのドキュメントをコード リポジトリに作成します。 しかしユーザーは、コードを精査して必要なドキュメントを探す必要があります。 今回、コード リポジトリからマークダウン ファイルを公開し、Wiki でホストできるようになりました。

Wiki 内から、まず Wiki としてコードを発行しますをクリックします。 次に、公開する Git リポジトリのフォルダーを指定します。

Publishをクリックすると、選択したフォルダの下にあるすべてのマークダウンファイルが Wiki として公開されます。 また、ブランチの最上位のフォルダーが Wiki に関連付けられるため、Git リポジトリの変更が即座に反映されます。

詳細については、 製品ドキュメントのブログ記事 を参照してください。

ページ内の見出しへのリンク

Wiki ページのセクション見出しの横にあるリンク アイコンをクリックして、そのセクションに直接 URL を生成できるようになりました。 その URL をコピーし、チーム メンバーと共有して、そのセクションに直接リンクすることができます。

フォルダー内のファイルと画像を添付する

Wiki ページをオフラインで編集すると、Wiki ページと同じディレクトリに添付ファイルや画像を簡単に追加できます。 これで、Wiki 内の任意のフォルダーに添付ファイルまたは画像を追加し、ページにリンクできます。

Wiki にビデオを埋め込む

これで、Microsoft Stream や YouTube などのオンライン サービスから Wiki ページにビデオを埋め込むことができます。 埋め込みビデオ URL は、次の構文を使用して追加できます。

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Wiki の名前を変更する

Wiki ユーザー インターフェイスで、および REST API を使用して Wiki の名前を変更できるようになりました。 [詳細メニューからrename wikiをクリックして、Wiki に覚えやすい名前を付けます。

新しいタブでページを開く

Wiki ページを右クリックして新しいタブで開くか、Ctrl キーを押しながら Wiki ページを左クリックして新しいタブで開くことができます。

Wiki ページ タイトルで特殊文字を保持する

: < > * ? | -などの特殊文字を含む Wiki ページを作成できるようになりました。 "FAQ" のようなタイトルを含むページが表示されるようになりました。 または「セットアップガイド」を Wiki で作成できます。 次の文字は、UTF-8 でエンコードされた文字列に変換されます。

文字	エンコードされた文字列
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

壊れたリンクを表示する

正しくリンクされていない Wiki 内のすべてのリンクは、明確な赤い色と壊れたリンク アイコンで表示され、Wiki ページ内のすべての壊れたリンクの視覚的な手掛かりが得られます。

ページを移動するときの壊れたリンクを修正する

破損したページ リンクは、ドキュメント ソリューションにおけるページ品質の低下の主な原因の 1 つです。 以前 Wikiでは、ツリー構造内のページを移動したり、ページの名前を変更したりすると、他のページや作業項目からのページへのリンクが壊れる可能性があります。 これで、リンクが壊れる前に、リンクを確認して修正できます。

ページの名前を変更または移動すると、影響を受ける絶対リンクまたは相対リンクを確認するように求められます。

その後、アクションを実行する前に、影響を受ける Page のリンク と Work アイテム の一覧が表示されます。

Wiki ページの目次を作成する

Wiki ページが長くなる場合があり、コンテンツは複数の見出しにまとめられます。 これで、 [[_TOC_]] 構文を使用して、少なくとも 1 つの見出しを持つ任意のページに目次を追加できるようになりました。

また、ページの編集時に書式設定ウィンドウの適切なボタンをクリックして目次を挿入することもできます。

Azure DevOps での markdown の使用の詳細については、 markdown ガイダンス ドキュメントを参照してください。

YAML タグを使用した Wiki ページとコード プレビューのサーフェス メタデータ

ドキュメントにメタデータを追加すると、読者や検索インデックスが意味のあるコンテンツを取得して表示するのに役立ちます。 この更新では、ファイルの先頭に YAML ブロックを含むファイルは、1 つのヘッドと 1 行のメタデータ テーブルに変換されます。 YAML ブロックは、3 つの破線の間に有効な YAML セットの形式を取る必要があります。 すべての基本的なデータ型、リスト、オブジェクトを値としてサポートします。 構文は、 Wiki およびコード ファイル プレビューでサポートされています。

YAML タグの例:

---
tag: post
title: Hello world
---

リストを含む YAML タグの例:

---
tags:
- post
- code
- web
title: Hello world
---

コントリビュート許可で Wiki としてコードを発行

以前は、git リポジトリに対する Create Repository アクセス許可を持つユーザーのみが Wiki としてコードを発行できました。 これにより、リポジトリ管理者または作成者は、git リポジトリでホストされているマークダウン ファイルを wiki として発行する要求のボトルネックになりました。 これで、コード リポジトリに Contribute アクセス許可がある場合はコードを wiki としてできます。

レポート

レポート用の Analytics マーケットプレース拡張機能が利用可能になりました

Analytics Marketplace 拡張機能は、Azure DevOps Server で使用できるようになりました。 分析は、Azure DevOps と Azure DevOps Server のレポートの未来です。 Analytics 拡張機能をインストールすると、 advanced widgets、 Power BI 統合、および OData アクセスが提供されます。

詳細については、「 Analytics とはレポート ロードマップを参照してください。 分析はパブリック プレビュー段階です。 現在、Pipelines を介した Boards と自動テスト結果のデータが含まれています。 Analytics Service で使用できる Data を参照してください。

新しいビルド ダッシュボード ウィジェットを使用してビルド履歴を調査する

ダッシュボードに追加できる、新しく改良されたビルド履歴ウィジェットがあります。 このウィジェットを使用すると、ダッシュボード上の特定のブランチからのビルドの履歴を表示し、匿名の訪問者のためにパブリック プロジェクトで構成できるようになりました。

---

フィードバック

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

---

ページのトップへ