Azure DevOpsServer 2020 Update 1 リリース ノート

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 2020 Update 1.2 Patch 13 リリース日: 2024 年 3 月 12 日

ファイル	Sha-256 ハッシュ
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

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

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

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

ファイル	Sha-256 ハッシュ
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

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

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

Azure DevOps Server 2020 Update 1.2 Patch 11 リリース日: 2023 年 12 月 12 日

ファイル	Sha-256 ハッシュ
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

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

• パイプラインステージでデプロイ前承認セキュリティ継承が機能しないバグを修正しました。

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

次の修正プログラムを含む Azure DevOps Server 2020 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 2020 Update 1.2 Patch 9 リリース日: 2023 年 10 月 10 日

patch をリリースしました。 次の修正プログラムを含む Azure DevOps Server 2020 Update 1.2 の場合。

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

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

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

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

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

1. Azure DevOps Server 2020 Update 1.2 patch 8 をダウンロードしてインストールします。

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

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

• CVE-2023-36869: Azure DevOps サーバーのスプーフィングの脆弱性。
• SHA2-256 と SHA2-512 をサポートするように SSH サービスを更新します。 RSA を使用するようにハードコーディングされた SSH 構成ファイルがある場合は、SHA2 に更新するか、エントリを削除する必要があります。
• マークダウン ファイルで相対リンクが機能しない問題に対処しました。
• コミット ページでのコメント ナビゲーションのバグを修正しました。
• 分析所有者 ID が非アクティブ ID として表示されるバグを修正しました。
• CronScheduleJobExtension の無限ループバグを修正しました。

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

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

• CVE-2023-21565: Azure DevOps サーバーのスプーフィングの脆弱性。
• CVE-2023-21569: Azure DevOps サーバーのスプーフィングの脆弱性。
• 2018 以前からアップグレードするときにパッケージのプッシュを妨げるバグを修正しました。
• デタッチまたはアタッチ コレクションが失敗し、"TF246018: データベース操作がタイムアウト制限を超え、取り消されました" というエラーが報告されるバグを修正しました。

Azure DevOps Server 2020 Update 1.2 Patch 5 リリース日: 2023 年 2 月 14 日

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

• CVE-2023-21553: Azure DevOps Server のリモート コード実行の脆弱性
• Web UI を使用したシェルブセットのアクセシビリティの問題を修正しました
• お客様は、Azure DevOps Server 管理コンソールで SMTP 関連の設定を更新した後、tfsjobagent サービスと Azure DevOps Server アプリケーション プールを再起動する必要があります。

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

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

• IdentityPicker での特殊文字の表示を修正しました。

• テスト データが削除されず、データベースが拡張されました。 この修正により、新しい孤立したテスト データが作成されないようにビルドリテンション期間が更新されました。

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

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

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

Azure DevOps Server 2020 Update 1.2 Patch 2 リリース日: 2022 年 8 月 9 日

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

• 異なるドメインに表示される ID に作業項目を割り当て中の ID 値エラーを修正します。

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

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

• テスト実行 API では、返される継続トークンが、指定された "maxLastUpdatedDate" 値を超えました。

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

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

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

• Azure DevOps Server 2020.1.2 では、パイプラインの実行 (ビルド) が失われるのを防ぐために、新しい保持モデル (Azure DevOps Server 2020 で導入) が無効になります。 つまり、システムは次のことを行います。

  • Server 2020 の実行中に生成された最新の 3 つのビルドのリースを作成する
  • パイプラインごとのリテンション ポリシーのない YAML パイプラインとクラシック パイプラインの場合、ビルドは コレクション レベルの最大リテンション期間設定に従って保持されます
  • カスタムのパイプラインごとの保持ポリシーを使用するクラシック パイプラインの場合、ビルドはパイプライン固有の保持ポリシーに従って保持されます
  • リースを含むビルドは、設定を維持するために最小値にカウントされません

• 変更セットとシェルブセットのコメント リンクが正しくリダイレクトされませんでした。 変更セットまたはシェルブセット内のファイルにコメントが追加されたとき、それらのコメントを選択しても、ファイル ビューの正しい場所にリダイレクトされませんでした。

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

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

Azure DevOps Server 2020.1.1 Patch 4 リリース日: 2022 年 1 月 26 日

次の修正プログラムを含む Azure DevOps Server 2020.1.1 用の patch をリリースしました。

• 作業項目で @mention コントロールを使用しているときに、電子メール通知が送信されませんでした。
• ユーザー プロファイルの優先メール アドレスが更新されていませんでした。 これにより、メールが以前のメール アドレスに送信されていました。
• [プロジェクトの概要] ページにヘッダーが表示されませんでした。 ヘッダーは数ミリ秒間表示され、その後消えました。
• Active Directory ユーザー同期の機能強化。
• log4j バイナリから jndilookup クラスを削除することにより、Elasticsearch の脆弱性に対処しました。

インストール手順

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

Azure DevOps Server 2020.1.1 Patch 3 リリース日: 2021 年 12 月 15 日

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

• "Contains Words" を使用したクエリの作業項目マクロを修正しました。 以前は、クエリは改行を含む値に対して正しくない結果を返していました。
• Maven パッケージ バージョンの文字長の制限を増やします。
• カスタム作業項目のレイアウト状態のローカライズの問題。
• 電子メール通知テンプレートのローカライズの問題。
• 1 つのフィールドに対して複数の NOTSAMEAS ルールが定義されている場合の NOTSAMEAS ルールの評価に関する問題。

Azure DevOps Server 2020.1.1 Patch 2 リリース日: 2021 年 10 月 26 日

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

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

Azure DevOps Server 2020.1.1 Patch 1 リリース日: 2021 年 9 月 14 日

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

• アーティファクトのダウンロード/アップロードの失敗を修正しました。
• 一貫性のないテスト結果データに関する問題を解決します。

Azure DevOps Server 2020 Update 1.1 リリース日: 2021 年 8 月 17 日

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

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

Azure Boards

• 通知メールの [作業項目の表示] ハイパーリンクでは、パブリック URL が使用されていません。

Azure Repos

• 複数リポジトリ ポリシーを設定した後に制限のマージの種類を変更できるように、制限付きマージの種類の継承チェック ボックスが表示される問題を修正しました。

Azure Pipelines

• エージェントの更新の設定を変更しても、設定は環境内の他のアプリケーション層に反映されませんでした。

全般

• サーバー構成ウィザードのスペルを修正しました。
• 拡張機能パッケージのサイズを増やし、レジストリのサイズを変更できるようにします。

Azure Test Plans

• 履歴から概要ページに戻ると、テスト結果に戻ることができません。

---

Azure DevOps Server 2020.1 Patch 2 リリース日: 2021 年 8 月 10 日

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

• ビルド定義 UI エラーを修正しました。
• ルート リポジトリの代わりにファイルを表示するように閲覧履歴を変更しました。

Azure DevOps Server 2020.1 Patch 1 リリース日: 2021 年 6 月 15 日

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

• SameSite=Noneをアサートする承認フローで使用されるセキュリティで保護された Cookie。

• Notifications SDK に関する問題を解決します。 以前は、エリア パス フィルターを使用する通知サブスクリプションが正しく解析されませんでした。

Azure DevOps Server 2020.1 RTW リリース日: 2021 年 5 月 25 日

Azure DevOps Server 2020.1 RTW の新機能の概要

Azure DevOps Server 2020.1 RTW は、バグ修正のロールアップです。 これには、以前にリリースされた Azure DevOps Server 2020.1 RC2 のすべての機能が含まれています。 Azure DevOps Server 2020.1 RTW は、バグ修正のロールアップです。 Azure DevOps Server 2020.1 を直接インストールするか、Azure DevOps Server 2020、2019、または Team Foundation Server 2015 以降からアップグレードできます。

Azure DevOps Server 2020.1 RC2 リリース日: 2021 年 4 月 13 日

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

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

Azure DevOps Server 2020.1 RC1 リリース日: 2021 年 3 月 23 日

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

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

• Boards の状態遷移制限規則
• 利害関係者が作業項目をボード列間で移動できるようになりました
• アクセス トークンのスコープを制限してリリースのセキュリティを強化する
• プル要求エクスペリエンスの強化
• パイプラインのマルチリポジトリ トリガー

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

• Boards
• Repos
• パイプライン
• アイテム

---

Boards

状態遷移の制限規則

ホストされた XML と継承されたプロセス モデルの間の機能パリティギャップを引き続き閉じます。 この新しい作業項目の種類ルールを使用すると、作業項目をある状態から別の状態に移動することを制限できます。 たとえば、バグを [新規] から [解決済み] に制限できます。 代わりに、新しい -> アクティブ -> 解決済みから移動する必要があります

また、グループ メンバーシップ別に状態遷移を制限するルールを作成することもできます。 たとえば、[承認者] グループ内のユーザーのみが、New -> Approved からユーザー ストーリーを移動できます。

作業項目をコピーして子をコピーする

Azure Boards で要求される上位の機能の 1 つは、子作業項目もコピーする作業項目をコピーする機能です。 作業項目のコピー ダイアログに、"子作業項目を含める" という新しいオプションが追加されました。 このオプションを選択すると、作業項目がコピーされ、すべての子作業項目 (最大 100 個) がコピーされます。

アクティブ化されたフィールドと解決されたフィールドのルールが改善されました

これまで、 Activated By、 Activated Date、 Resolved By、 Resolved Date のルールは謎でした。 これらはシステム作業項目の種類にのみ設定され、"Active" と "Resolved" の状態値に固有です。 これらのルールが特定の状態でなくなったように、ロジックを変更しました。 代わりに、状態が存在するカテゴリ (状態カテゴリ) によってトリガーされます。 たとえば、解決済みカテゴリのカスタム状態が "テストが必要" であるとします。 作業項目が "アクティブ" から "テストが必要" に変わると、 Resolved By ルールと Resolved Date ルールがトリガーされます。

これにより、ユーザーはカスタム状態値を作成し、カスタム ルールを使用しなくても、 Activated By、 Activated Date、 Resolved By、 Resolved Date フィールドを生成できます。

利害関係者は、作業項目を複数のボード列に移動できます

利害関係者は、常に作業項目の状態を変更できます。 ただし、かんばんボードに移動すると、作業項目を 1 つの列から別の列に移動することはできません。 代わりに、利害関係者は各作業項目を一度に 1 つずつ開き、状態値を更新する必要があります。 これは長い間、お客様にとっての問題であり、作業項目をボード列間で移動できるようになったことをお知らせいたします。

バックログとボード上のシステム作業項目の種類

これで、選択したバックログ レベルにシステム作業項目の種類を追加できます。 これまで、これらの作業項目の種類はクエリからのみ使用できます。

プロセス	作業項目の種類
アジャイル	問題点
スクラム	障害
CMMI	変更要求
	問題点
	確認
	リスク

システム作業項目の種類をバックログ レベルに追加するのは簡単です。 カスタム プロセスに移動し、[バックログ レベル] タブ クリック。選択したバックログ レベル (例: 要件バックログ) を選択し、編集オプション 選択します。 次に、作業項目の種類を追加します。

Azure Boards の GitHub アプリ リポジトリの制限が引き上げされました

GitHub マーケットプレースの Azure Boards アプリケーション のリポジトリ制限が 100 から 250 に引き上げされました。

pull request がマージされたときに作業項目の状態をカスタマイズする

すべてのワークフローが同じであるわけではありません。 一部のお客様は、Pull Request が完了したときに関連する作業項目を閉じたいと考えています。 他のユーザーは、作業項目を閉じる前に検証する別の状態に設定する必要があります。 両方を許可する必要があります。

pull request のマージと完了時に作業項目を目的の状態に設定できる新機能が追加されました。 これを行うには、pull request の説明をスキャンし、状態値の後に作業項目の #mention を探します。 この例では、2 つのユーザー ストーリーを [解決済み] に設定し、2 つのタスクを閉じています。

作業項目を別のプロジェクトのビルドにリンクする

作業項目をビルド、ビルドで見つかった、またはビルドに統合にリンクするだけで、プロジェクト間でビルドの依存関係を簡単に追跡できるようになりました。

システム フィールドの説明 (ヘルプ テキスト) の編集

ユーザー設定フィールドの説明は、常に編集できました。 ただし、優先度、重大度、アクティビティなどのシステム フィールドでは、説明は編集できませんでした。 これは、一部の顧客が継承モデルに移行できなかった、ホストされた XML と継承の間の機能のギャップでした。 これで、システム フィールドの説明を編集できるようになりました。 編集された値は、プロセスのフィールドとその作業項目の種類にのみ影響します。 これにより、異なる作業項目タイプの同じフィールドに対して異なる説明を柔軟に設定できます。

pull request がマージされたときに作業項目の状態をカスタマイズする

プル要求は、多くの場合、複数の作業項目を参照します。 pull request を作成または更新する場合は、その一部を閉じて、その一部を解決し、残りを開いたままにしておく必要があります。 次の図に示すようなコメントを使用して、これを実現できるようになりました。 詳細については、 ドキュメントを参照してください。

タスク ボードの親フィールド

一般的な要求により、タスク ボードの子カードと親カードの両方に [親] フィールドを追加できるようになりました。

バグ作業項目の種類に対する "割り当て済み" ルールの削除

アジャイル、スクラム、CMMI では、さまざまな作業項目の種類に対して、いくつかの非表示のシステム ルールがあります。 これらの規則は 10 年以上存在し、一般的に問題なく正常に動作してきました。 しかし、いくつかのルールが歓迎を使い果たしました。 特に 1 つのルールは、新規および既存の顧客に多くの痛みを引き起こしており、それを削除する時期を決定しました。 このルールは、アジャイル プロセスのバグ作業項目の種類に存在します。

"状態が解決済みに変更されたときに、割り当てられた値を Created By に設定する"

このルールに関する多くのフィードバックを受け取りました。 これに対して、アジャイル プロセスのバグ作業項目の種類からこのルールを削除しました。 この変更は、継承されたアジャイルまたはカスタマイズされた継承されたアジャイル プロセスを使用するすべてのプロジェクトに影響します。 この現在のルールを気に入って依存しているお客様については、カスタム ルールを使用してルールを再追加するために実行できる手順に関する ブログの投稿 を参照してください。

[作業項目] ページの項目の削除

[ 作業項目] ページ は、作成したアイテムや割り当てられているアイテムをすばやく見つけるのに最適な場所です。 これは、いくつかのパーソナライズされたピボットとフィルタを提供します。 [自分に割り当て済み] ピボットの上位の苦情の 1 つは、削除された作業項目 (つまり、削除済み状態の作業項目) が表示されていることです。 そして、私たちは同意します! 削除された項目は、値がなくなったためバックログから削除された作業であるため、このビューに含めるのは役に立ちません。

[作業項目] ページの [割り当て済みアイテム] ピボットからすべての削除済みアイテムを非表示にできるようになりました。

Repos

既定のブランチ名の基本設定

Azure Repos では、Git のカスタマイズ可能な既定のブランチ名が提供されるようになりました。 リポジトリの設定では、リポジトリの初期化時に使用する任意の有効なブランチ名を選択できます。 Azure Repos では、既存のリポジトリの既定のブランチ名の変更が常にサポートされています。

詳細については、「管理ブランチ既定のブランチを変更する」を参照してください。

既定のブランチの組織レベルの設定

新しいリポジトリに優先する初期ブランチ名のコレクション レベルの設定が追加されました。 プロジェクトが最初のブランチ名を選択していない場合は、この組織レベルの設定が使用されます。 組織の設定またはプロジェクト設定で初期ブランチ名を指定しなかった場合、新しいリポジトリでは、Azure DevOps 定義の既定値が使用されます。

投稿する PR コメントの新しい認証スコープの追加

このリリースでは、pull request コメントを読み書きするための新しい OAuth スコープが追加されました。 コメントのみを操作する必要があるボットまたは自動化がある場合は、このスコープのみを含む PAT を付与できます。 このプロセスにより、自動化にバグがある場合、またはトークンが侵害された場合に、ブラスト半径が減少します。

Pull Request エクスペリエンスの改善

新しい pull request エクスペリエンスは、次のように改善されました。

• オプションのチェックを表示する

お客様は、オプションのチェックを使用して、潜在的な問題に開発者の注意を引きます。 以前のエクスペリエンスでは、これらのチェックが失敗したときには明らかだった。 ただし、プレビュー エクスペリエンスではそうではありません。 必要なチェックの大きな緑色のチェックマークは、オプションのチェックでエラーをマスクします。 ユーザーは、チェック パネルを開くだけで、オプションのチェックが失敗したことを検出できました。 開発者は、問題の兆候がない場合は、あまりこれを行いません。 このデプロイでは、省略可能なチェックの状態が概要に表示されるようにしました。

• Ctrl キーを押しながらメニュー項目をクリックする

PR のタブ メニューでは、Ctrl キーを押しながらクリックすることはできませんでした。 多くの場合、ユーザーは pull request を確認すると、新しいブラウザー タブを開きます。 これは修正されました。

• [+] 注釈の場所

PR 内のファイルのツリー リストには、作成者と校閲者が新しいファイルを識別するのに役立つ注釈 [+] が表示されます。 注釈は省略記号の後にあったため、多くの場合、長いファイル名では表示されませんでした。

• PR 更新プログラムのドロップダウンがタイミング情報を回復する

PR 内のファイルの更新と比較を選択するドロップダウンは、プレビュー エクスペリエンスで重要な要素を失いました。 その更新がいつ行われたかは表示されませんでした。 これは修正されました。

• **コメント フィルターのレイアウトが改善されました**

プル要求の概要ページでコメントをフィルター処理する場合、ドロップダウンは右側にありますが、テキストは左揃えでした。 これは修正されました。

• 親コミットへの移動

[コミット] ページでは、特定のコミットで行われた変更とその親コミットを比較できます。 ただし、親コミットに移動し、そのコミットが自身の親とどのように異なるかをさらに理解したい場合があります。 これは、多くの場合、リリースのすべての変更を理解する必要がある場合に必要です。 これを実現するために、コミットに親カードを追加しました。

• [PR ファイル] タブに長い名前のフォルダーとファイル用の領域の追加

ファイル ツリーの水平方向の間隔がないため、長い名前のフォルダーとファイルが切り取られました。 ツリーのインデントをルート ノードに合わせて変更し、ページの省略記号ボタンをホバー時以外に非表示にすることで、ツリー内の領域を追加しました。

新しいファイル ツリーの画像:

ディレクトリの上にマウス ポインターを置いたときのファイル ツリーの画像:

• [PR ファイル] タブの差分ペインのサイズ変更時にスクロール位置を保持する

PR ファイル タブで side-by-side diff ペインのサイズを変更すると、ユーザーのスクロール位置が失われます。 この問題は修正されました。ユーザーのスクロール位置が差分ペインのサイズ変更に保持されるようになりました。

• モバイル デバイスでのコミットの検索

モバイル デバイスで [コミット] ページを表示すると、新しいエクスペリエンスで検索ボックスが表示されません。 その結果、ハッシュによってコミットを見つけて開くのは困難です。 これは現在修正されています。

• 新しい PR ファイル差分ビューの領域の使用方法の改善

このページは、ヘッダーによって画面の 40% が取得されるのではなく、ユーザーがモバイル ビューでより多くのファイルを表示できるように、領域を使用するように更新されました。

• PR 概要ビューの拡張イメージ

PR で編集されたイメージが PR 概要ビューに表示されませんでしたが、PR ファイル ビューに正しく表示されていました。 この問題は解決されました。

• 新しい PR を作成するときのブランチ エクスペリエンスの強化

この更新の前は、このエクスペリエンスは、変更を比較ブランチではなくリポジトリの既定のブランチと比較するのと同じようには理想的ではありません。

Pipelines

追加のエージェント プラットフォーム: ARM64

Azure Pipelines エージェントでサポートされているプラットフォームの一覧に Linux/ARM64 を追加しました。 コードの変更は最小限でしたが、最初に多くのバックグラウンド作業を完了する必要があり、リリースをお知らせします。

パイプライン リソースでのタグ フィルターのサポート

これで、YAML パイプラインに "タグ" が追加されました。 タグを使用して、実行する CI パイプライン、または自動的にトリガーするタイミングを設定できます。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

上記のスニペットは、CD (継続的デプロイ) パイプラインの実行が他のソース/リソースまたはスケジュールされた実行トリガーによってトリガーされない場合に実行する CI (継続的インテグレーション) パイプラインの既定のバージョンを決定するためにタグを使用できることを示しています。

たとえば、CI に実稼働タグがある場合にのみ実行する CD パイプラインのスケジュールされたトリガー セットがある場合、triggers セクションのタグは、タグ付け条件が CI 完了イベントによって満たされた場合にのみ CD パイプラインがトリガーされるようにします。

パイプラインで許可されるタスクの制御

Marketplace タスクを無効にできるようになりました。 一部のユーザーは Marketplace 拡張機能を許可できますが、パイプラインのタスクは許可しません。 さらに詳細な制御を行うために、すべてのインザボックス タスクを個別に無効にすることもできます (チェックアウトを除き、これは特別なアクションです)。 これらの両方の設定を有効にすると、パイプラインで実行できるタスクは、 tfx を使用してアップロードされるタスクのみです。 https://dev.azure.com/<your_org>/_settings/pipelinessettingsにアクセスし、「タスクの制限」というセクションを探して作業を開始します。

排他展開ロック ポリシー

この更新プログラムを使用すると、一度に 1 回の実行のみが環境にデプロイされるようにすることができます。 環境で [排他ロック] チェックを選択すると、1 回の実行のみが続行されます。 その環境にデプロイする後続の実行は一時停止されます。 排他ロックを使用した実行が完了すると、最新の実行が続行されます。 中間実行はすべて取り消されます。

パイプライン リソース トリガーのステージ フィルター

YAML のパイプライン リソースのフィルターとして、"ステージ" のサポートを追加しました。 このフィルターを使用すると、CD パイプラインをトリガーするために CI パイプライン全体が完了するのを待つ必要はありません。 CI パイプラインの特定のステージが完了したときに CD パイプラインをトリガーすることを選択できるようになりました。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

トリガー フィルターで指定されたステージが CI パイプラインで正常に完了すると、CD パイプラインに対して新しい実行が自動的にトリガーされます。

YAML パイプライン用の汎用 Webhook ベースのトリガー

現在、成果物を使用して自動トリガーを有効にできるさまざまなリソース (パイプライン、コンテナー、ビルド、パッケージなど) があります。 ただし、これまでは、他の外部イベントやサービスに基づいてデプロイ プロセスを自動化できませんでした。 このリリースでは、任意の外部サービスとのパイプライン自動化の統合を可能にするために、YAML パイプラインで Webhook トリガーのサポートを導入します。 Webhook (Github、Github Enterprise、Nexus、Aritfactory など) を使用して外部イベントをサブスクライブし、パイプラインをトリガーできます。

Webhook トリガーを構成する手順を次に示します。

1. 外部サービスで Webhook をセットアップします。 Webhook を作成するときは、次の情報を指定する必要があります。

   • 要求 URL - "https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • シークレット - これは省略可能です。 JSON ペイロードをセキュリティで保護する必要がある場合は、 Secret 値を指定します

2. 新しい "着信 Webhook" サービス接続を作成します。 これは、次の 3 つの重要な情報を定義できる、新しく導入されたサービス接続の種類です。

   • Webhook 名: Webhook の名前は、外部サービスで作成した Webhook と一致する必要があります。
   • HTTP ヘッダー - 要求検証用のペイロード ハッシュ値を含む要求内の HTTP ヘッダーの名前。 たとえば、GitHub の場合、要求ヘッダーは "X-Hub-Signature" になります。
   • シークレット - シークレットは、受信要求の検証に使用されるペイロード ハッシュを解析するために使用されます (これは省略可能です)。 Webhook の作成にシークレットを使用した場合は、同じ秘密鍵を指定する必要があります

   

3. webhooks という新しいリソースの種類が YAML パイプラインに導入されています。 webhook イベントをサブスクライブするには、パイプラインで Webhook リソースを定義し、それを受信 Webhook サービス接続をポイントする必要があります。 また、JSON ペイロード データに基づいて Webhook リソースに追加のフィルターを定義して、各パイプラインのトリガーをさらにカスタマイズすることもできます。また、ジョブ内の変数の形式でペイロード データを使用することもできます。

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. 受信 Webhook サービス接続によって Webhook イベントが受信されるたびに、webhook イベントにサブスクライブされているすべてのパイプラインに対して新しい実行がトリガーされます。

YAML リソース トリガーの問題のサポートと追跡可能性

パイプライン トリガーが期待どおりに実行できない場合は、混乱を招く可能性があります。 これを理解しやすくするために、"トリガーの問題" という名前の新しいメニュー項目をパイプライン定義ページに追加しました。トリガーが実行されていない理由に関する情報が表示されます。

リソース トリガーは、2 つの理由で実行に失敗する可能性があります。

1. 指定されたサービス接続のソースが無効な場合、またはトリガーに構文エラーがある場合、トリガーはまったく構成されません。 これらはエラーとして表示されます。

2. トリガー条件が一致しない場合、トリガーは実行されません。 これが発生するたびに、条件が一致しなかった理由を理解できるように警告が表示されます。

   

マルチリポジトリ トリガー

1 つの YAML ファイルに複数のリポジトリを指定し、いずれかのリポジトリに対する更新によってパイプラインをトリガーできます。 この機能は、たとえば、次のシナリオで役立ちます。

• 異なるリポジトリにあるツールまたはライブラリを使っています。 ツールまたはライブラリが更新されるたびに、アプリケーションのテストを実行する必要があります。
• アプリケーション コードとは別のリポジトリに、YAML ファイルを保持しています。 更新がアプリケーションのリポジトリにプッシュされるたびに、パイプラインをトリガーする必要があります。

この更新プログラムでは、マルチリポジトリ トリガーは Azure Repos の Git リポジトリでのみ機能します。 GitHub または BitBucket リポジトリ リソースでは機能しません。

パイプラインで複数のリポジトリ リソースを定義する方法と、それらのすべてにトリガーを構成する方法を示す例を次に示します。

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

この例のパイプラインは、次の更新がある場合にトリガーされます。

• main YAML ファイルを含む self リポジトリ内のブランチ
• mainリポジトリ内のブランチtoolsreleaseする

詳細については、「 パイプライン内の複数のリポジトリを参照してください。

エージェント ログのアップロードの改善

エージェントが Azure Pipelines サーバーとの通信を停止すると、実行されていたジョブは破棄されます。 ストリーミング コンソールのログを見ていた場合は、エージェントが応答を停止する直前に、エージェントの状態に関するいくつかの手掛かりを得ている可能性があります。 しかし、そうでない場合、またはページを更新した場合、それらのコンソール ログは失われました。 このリリースでは、エージェントが完全なログを送信する前に応答を停止した場合は、コンソール ログを次に最適なものとして保持します。 コンソール ログは 1 行あたり 1,000 文字に制限されており、不完全な場合もありますが、何も表示しないよりもはるかに便利です。 これらのログを調べることは、独自のパイプラインのトラブルシューティングに役立つ場合があり、サポート エンジニアがトラブルシューティングを支援する際に役立ちます。

(オプション) コンテナー ボリュームの読み取り専用でのマウント

Azure Pipelines でコンテナー ジョブを実行すると、ワークスペース、タスク、およびその他のマテリアルを含む複数のボリュームがボリュームとしてマップされます。 これらのボリュームは、既定で読み取り/書き込みアクセスに使用されます。 セキュリティを強化するために、YAML でコンテナーの仕様を変更することで、ボリュームを読み取り専用でマウントできます。 mountReadOnlyの下の各キーは、読み取り専用でtrueに設定できます (既定値はfalse)。

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

コンテナーの開始/停止をきめ細かく制御

一般に、Azure Pipelines でジョブとサービス コンテナーのライフサイクルを管理できるようにすることをお勧めします。 ただし、いくつかの一般的でないシナリオでは、自分で開始して停止することができます。 このリリースでは、その機能を Docker タスクに組み込んできました。

新しい機能を使用したパイプラインの例を次に示します。

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

また、パイプライン変数 Agent.ContainerMappingにコンテナーの一覧を含めます。 たとえば、スクリプト内のコンテナーの一覧を調べる場合に使用できます。 これには、リソース名 (上の例の "ビルダー" ) をエージェントが管理するコンテナー ID にマッピングする文字列化された JSON オブジェクトが含まれています。

各ステップのタスク バンドルの解凍

エージェントは、ジョブを実行するときに、ジョブのステップで必要なすべてのタスク バンドルを最初にダウンロードします。 通常、パフォーマンスのために、タスクが複数のステップで使用されている場合でも、ジョブごとに 1 回タスクを解凍します。 解凍されたコンテンツを変更する信頼されていないコードに関する懸念がある場合は、エージェントが各使用法でタスクを解凍することで、少しのパフォーマンスを低下させることができます。 このモードを有効にするには、エージェントを構成するときに --alwaysextracttask 渡します。

アクセス トークンのスコープを制限してリリースのセキュリティを強化する

Azure Pipelines のセキュリティ設定を強化する取り組みに基づいて、リリースのアクセス トークンのスコープの制限がサポートされるようになりました。

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

この更新プログラムでは、アクセス トークンのスコープを制限し、従来のリリースに拡張することで、パイプラインのセキュリティを強化することに基づいて構築されています。

この機能は、新しいプロジェクトとコレクションに対して既定でオンになります。 既存のコレクションの場合は、コレクション Settings > Pipelines > 設定で有効にする必要があります。 > リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限します。 こちらをご覧ください。

YAML プレビュー API の機能強化

パイプラインを実行せずに、パイプラインの完全な YAML をプレビューできるようになりました。 さらに、プレビュー機能用の専用の新しい URL を作成しました。 これで、POST を https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview して、最終的な YAML 本文を取得できるようになりました。 この新しい API は、実行をキューに登録するのと同じパラメーターを受け取りますが、"キュー ビルド" アクセス許可は必要なくなりました。

このジョブを次に実行する

今 デプロイするために必要なバグ修正がありましたが CI ジョブと PR ジョブの背後で待機する必要がありましたか? このリリースでは、キューに登録されたジョブの優先順位を上げることができるようになりました。 プールに対する "管理" アクセス許可を持つユーザー (通常はプール管理者) には、ジョブの詳細ページに新しい [次へ実行] ボタンが表示されます。 ボタンをクリックすると、ジョブができるだけ早く実行されるように設定されます。 (もちろん、使用可能な並列処理と適切なエージェントが必要です)。

YAML resources ブロックで許可されるテンプレート式

以前は、 コンパイル時の式 (${{ }}) は、Azure Pipelines YAML ファイルの resources セクションでは許可されませんでした。 このリリースでは、コンテナーに対するこの制限が解除されました。 これにより、 runtime パラメーター リソース内の内容を使用できます。たとえば、キュー時にコンテナーを選択できます。 今後、このサポートを他のリソースに拡張する予定です。

Marketplace からの自動化されたタスクの更新を制御する

YAML パイプラインを記述するときは、通常、含まれるタスクのメジャー バージョン番号のみを指定します。 これにより、パイプラインで最新の機能の追加とバグ修正を自動的に実行できます。 場合によっては、タスクの以前のポイント リリースにロールバックする必要がある場合があり、この更新プログラムでは、これを行う機能が追加されました。 これで、YAML パイプラインで major.minor.patch タスクの完全なバージョンを指定できるようになりました。

これを定期的に行うことをお勧めしません。新しいタスクがパイプラインを中断する場合は、一時的な回避策としてのみ使用してください。 また、Marketplace から古いバージョンのタスクはインストールされません。 コレクションに既に存在している必要があります。または、パイプラインは失敗します。

例:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

エージェントとタスクでのノード 10 のサポート

ノード 6 はサポートされなくなったため、ノード 10 で動作するようにタスクを移行しています。 この更新プログラムでは、インボックス タスクのほぼ 50% を Node 10 に移行しました。 エージェントは、ノード 6 とノード 10 の両方のタスクを実行できるようになりました。 今後の更新では、エージェントから Node 6 を完全に削除します。 エージェントから Node 6 を削除する準備をするため、社内の拡張機能とカスタム タスクを更新して、間もなく Node 10 も使用するように要求します。 タスクに Node 10 を使用するには、 task.jsonの [ execution] で、 Node から Node10に更新します。

クラシック ビルド デザイナーでの YAML 変換の強化

このリリースでは、デザイナー ビルド パイプライン用の新しい "YAML へのエクスポート" 機能を導入しました。 パイプライン定義を保存し、 ... メニューの [YAML にエクスポート] を見つけます。

新しいエクスポート関数は、従来のビルド デザイナーで以前に見つかった "YAML として表示" 関数を置き換えます。 この関数は、Web UI がビルドについて知っていることを調べることしかできなかったため、不完全でした。これは、間違った YAML が生成されることがありました。 新しいエクスポート関数では、パイプラインの処理方法が正確に考慮され、デザイナー パイプラインに完全に忠実な YAML が生成されます。

新しい Web プラットフォーム変換 – リポジトリの設定

2 つのリポジトリ設定ページを、新しい Web プラットフォームにアップグレードされた 1 つのエクスペリエンスに変換しました。 このアップグレードにより、エクスペリエンスがより迅速かつ最新になるだけでなく、これらのページは、プロジェクト レベルからブランチ レベルまでのすべてのポリシーに対して 1 つのエントリ ポイントを提供します。

この新しいエクスペリエンスにより、読み込み時間が短縮され、検索フィルターが追加されたため、多数のリポジトリを持つプロジェクトのナビゲーションが簡単になりました。 プロジェクト レベルのポリシーと、クロスリポジトリ ポリシーの一覧を [ポリシー] タブで表示することもできます。

リポジトリをクリックすると、リポジトリ レベルで設定されたポリシーとアクセス許可を表示できます。 [ポリシー] タブでは、ポリシーが設定されているすべてのブランチの一覧を表示できます。 次に、ブランチをクリックしてポリシーをすべて表示しますが、[リポジトリの設定] ページを離れることはありません。

ここで、ポリシーが使用しているスコープよりも高いスコープから継承されると、ポリシーが継承された場所が各ポリシーの横に表示されます。 また、スコープ名をクリックして、上位レベルのポリシーが設定されたページに移動することもできます。

ポリシー ページ自体も、折りたたみ可能なセクションを含む新しい Web プラットフォームにアップグレードされました。 特定のビルド検証、状態チェック、または自動レビュー担当者ポリシーを検索するエクスペリエンスを向上させるために、セクションごとに検索フィルターを追加しました。

ServiceNow 変更管理の YAML パイプラインとの統合

ServiceNow 用の Azure Pipelines アプリ は、Azure Pipelines と ServiceNow Change Management を統合するのに役立ちます。 この更新プログラムでは、Azure Pipelines に ServiceNow で管理されている変更管理プロセスを YAML パイプラインに認識させる取り組みを進めています。

リソースに対して "ServiceNow Change Management" チェックを構成することで、そのリソースにビルドをデプロイする前に変更が承認されるように一時停止できます。 ステージの新しい変更を自動的に作成することも、既存の変更要求を待機することもできます。

サーバー ジョブに UpdateServiceNowChangeRequest タスクを追加して、展開の状態やメモなどで変更要求を更新することもできます。

Artifacts

UI から組織範囲のフィードを作成する機能

オンプレミスサービスとホステッド サービスの両方について、Web UI を通じてコレクション スコープのフィードを作成および管理する機能を顧客に提供しています。

[成果物] -> [フィードの作成] に移動し、[スコープ] 内でフィードの種類を選択することで、UI を介して組織スコープのフィードを作成できるようになりました。

他の Azure DevOps オファリングに合わせてプロジェクト スコープ のフィードを使用することをお勧めしますが、UI やさまざまな REST API を使用して、コレクション スコープ フィードを再度作成、管理、使用できます。 詳細については、フィードのドキュメントを参照してください。

更新プログラム パッケージのバージョン REST API を Maven パッケージで使用可能に

Azure Artifacts の "パッケージ バージョンの更新" REST API を使用して、Maven パッケージのバージョンを更新できるようになりました。 以前は、REST API を使用して、NuGet、Maven、npm、およびユニバーサル パッケージのパッケージ バージョンを更新できましたが、Maven パッケージは更新できませんでした。

Maven パッケージを更新するには、次のように HTTP PATCH コマンドを使用します。

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

次の設定を行うことができます。

URI パラメーター

名前	In	必須	Type	説明
artifactId	path	TRUE	string	パッケージの成果物 ID
feed	path	TRUE	string	フィードの名前または ID
groupId	path	TRUE	string	パッケージのグループ ID
収集	path	TRUE	string	Azure DevOps コレクションの名前
version	path	TRUE	string	パッケージのバージョン
project	path		string	プロジェクト ID またはプロジェクト名
api-version	query	TRUE	string	使う API のバージョン。 このバージョンの API を使用するには、これを '5.1-preview.1' に設定する必要があります

要求本文

名前	タイプ	説明
ビュー	JsonPatchOperation	パッケージ のバージョンが追加されるビュー

詳細については、 REST API のドキュメントを参照してください 更新されます。

フィードバック

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

---

ページのトップへ