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

[アーティクル]
03/12/2024

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

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

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

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

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

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

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

プロキシキャッシュフォルダーで使用されているディスク領域が正しく計算されず、フォルダーが正しくクリーンアップされないバグを修正しました。
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

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

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

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

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

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

注意

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

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

重要

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

TFX の構成

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

TFX を使用してタスクを更新する

ファイル	Sha-256 ハッシュ
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

Tasks20231103.zipをダウンロードして抽出します。
抽出されたファイルにディレクトリを変更します。
次のコマンドを実行してタスクをアップロードします。

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 日

重要

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

パッチをリリースしました。 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 の特権昇格の脆弱性。

重要

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

注意

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

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

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

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

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

注意

エージェントがダウングレードされないようにするには、AZP_AGENT_DOWNGRADE_DISABLEDを "true" に設定する必要があります。 Windows では、管理コマンドプロンプトで次のコマンドを使用し、その後に再起動することができます。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX の構成

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

TFX を使用してタスクを更新する

Tasks_20230825.zipをダウンロードして抽出します。
抽出されたファイルにディレクトリを変更します。
次のコマンドを実行してタスクをアップロードします。

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 Serverスプーフィングの脆弱性。
SHA2-256 と SHA2-512 をサポートするように SSH サービスを更新します。 RSA を使用するようにハードコーディングされた SSH 構成ファイルがある場合は、SHA2 に更新するか、エントリを削除する必要があります。
マークダウンファイルで相対リンクが機能しない問題に対処しました。
コミットページでのコメントナビゲーションのバグを修正しました。
Analysis Owner 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 Serverスプーフィングの脆弱性。
CVE-2023-21569: Azure DevOps Serverスプーフィングの脆弱性。
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 での特殊文字の表示を修正しました。

IndetityPicker で特殊文字をデモする Gif。する

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

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

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

セキュリティダイアログ ID ピッカーに新しく追加された AD ID が表示されない問題を解決します。
Web フック設定の [グループのメンバーによる要求] フィルターに関する問題を修正します。
パイプラインの組織設定でジョブ承認スコープが [ジョブ承認スコープを非リリースパイプラインの現在のプロジェクトに制限する] として構成されている場合の Gated チェック-in ビルドエラーを修正しました。
認証されたプロキシの背後でサービス接続を確立するときに 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 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

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

注意

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

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

Azure DevOps Server 2020.1.2 では、パイプラインの実行 (ビルド) の損失を防ぐために、新しい保持モデル (Azure DevOps Server 2020 で導入) が無効になります。つまり、システムは次のことを行います。
- Server 2020 の実行中に生成された最新の 3 つのビルドのリースを作成する
- パイプラインごとの保持ポリシーのない YAML パイプラインとクラシックパイプラインの場合、ビルドはコレクションレベルの最大リテンション期間設定に従って保持されます
- カスタムパイプラインごとの保持ポリシーを使用するクラシックパイプラインの場合、ビルドはパイプライン固有の保持ポリシーに従って保持されます
- リースを含むビルドは、設定を維持するために [最小] にカウントされません
変更セットとシェルブセットコメントのリンクが正しくリダイレクトされませんでした。変更セットまたはシェルブセット内のファイルにコメントが追加された場合、それらのコメントを選択しても、ファイルビューの正しい場所にリダイレクトされませんでした。
[次へ実行] ボタンを使用してビルドキューをスキップできません。以前は、プロジェクトコレクション管理者に対してのみ [次に実行] ボタンが有効でした。
ユーザーの Active Directory アカウントが無効になった後は、すべての個人用アクセストークンを取り消してください。

Azure DevOps Server 2020.1.1 パッチ 4 リリース日: 2022 年 1 月 26 日

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

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

インストール手順

パッチ 4 を使用してサーバーをアップグレードします。
HKLM:\Software\Elasticsearch\Version でレジストリ値を確認します。そこにレジストリ値がない場合は、文字列値を追加し、Version を 5.4.1 (Name = Version、Value = 5.4.1) に設定します。
readme ファイルに指定されているように更新コマンド PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update を実行します。次のような警告が返される場合があります: "リモートサーバーに接続できません"。更新プログラムによって再試行が実行されている場合は、それが完了するまで、ウィンドウを閉じないでください。

注意

Azure DevOps Server と Elasticsearch が異なるマシンにインストールされている場合は、次の手順に従います。

パッチ 4 を使用してサーバーをアップグレードします。
HKLM:\Software\Elasticsearch\Version でレジストリ値を確認します。そこにレジストリ値がない場合は、文字列値を追加し、Version を 5.4.1 (Name = Version、Value = 5.4.1) に設定します。
C:\Program Files\{TFS Version Folder}\Search\zip にある zip という名前のフォルダーの内容を Elasticsearch リモートファイルフォルダーにコピーします。
Elasticsearch サーバーマシンで Configure-TFSSearch.ps1 -Operation update を実行します。

SHA-256 ハッシュ: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 パッチ 3 リリース日: 2021 年 12 月 15 日

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

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

Azure DevOps Server 2020.1.1 パッチ 2 リリース日: 2021 年 10 月 26 日

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

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

Azure DevOps Server 2020.1.1 パッチ 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 以降からアップグレードすることもできます。

注意

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

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

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 のパッチをリリースし、以下を修正しました。

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

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

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

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

注意

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

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 の状態遷移制限ルール
利害関係者が作業項目をボード列間で移動できるようになりました
アクセストークンのスコープを制限することでリリースセキュリティを強化する
強化された pull request エクスペリエンス
パイプラインのマルチリポジトリトリガー

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

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

Boards

状態遷移の制限規則

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

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

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

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

このページには、コピーした作業項目に子作業項目を含めるAzure Boardsの新しいオプションが表示されます。

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

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

これにより、ユーザーはカスタム状態値を作成し、カスタムルールを使用しなくても、 アクティブ化日、 アクティブ化日、 解決日、解決日の各フィールドを生成できます。

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

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

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

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

Process	作業アイテムの種類
アジャイル	問題
スクラム	障害
CMMI	変更要求
	問題
	確認
	リスク

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

Azure Boards GitHub アプリリポジトリの制限が引き上げ

GitHub マーケットプレースのAzure Boards アプリケーションのリポジトリ制限が 100 から 250 に増加しました。

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

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

pull request がマージされて完了したときに作業項目を目的の状態に設定できる新しい機能があります。これを行うには、pull request の説明をスキャンし、状態値の後に作業項目の #メンションを探します。この例では、2 つのユーザーストーリーを Resolved に設定し、2 つのタスクを閉じます。

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

作業項目を Build、Found in build、または Integrated in build にリンクするだけで、プロジェクト間でビルドの依存関係を簡単に追跡できるようになりました。

作業項目のリンク

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

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

説明の編集

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

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

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

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

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

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

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

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

[作業項目] ページで削除されたアイテム

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

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

Repos

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

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

default-branch-name

注: この機能を有効にしない場合、リポジトリはAzure Reposの既定の名前で初期化されます。現時点では、その既定値は master です。包括的な言語に対する Microsoft のコミットメントと顧客の要求を尊重するために、この既定値を メイン に変更するために、業界の同僚に参加します。この変更は今年の夏の後半に行われます。 マスターを引き続き使用する場合は、この機能を今すぐ有効にして、master に設定する必要があります。

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

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

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

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

Pull Request エクスペリエンスの機能強化

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

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

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

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

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

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

[+] 注釈の場所

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

注釈の場所を表示する

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

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

PR 更新のドロップダウンにタイミング情報がありません

**コメントフィルターレイアウトの改善 **

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

コメントフィルターレイアウトの改善

親コミットへのナビゲーション

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

親コミットへのナビゲーション

[PR ファイル] タブの長い名前を持つフォルダーとファイルの領域を増やす

ファイルツリーの水平方向の間隔がないため、長い名前のフォルダーとファイルが切断されました。ルートノードに一致するようにツリーのインデントを変更し、ポイント時を除いてページから省略記号ボタンを非表示にすることで、ツリー内の追加の領域を回復しました。

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

フォルダーとファイルの領域を増やす

ディレクトリにカーソルを合わせるときのファイルツリーの画像:

名前の表示

[PR ファイル] タブdiffウィンドウのサイズを変更するときにスクロール位置を保持する

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

モバイルデバイスでコミットを検索する

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

モバイルデバイスでコミットを検索する

モバイルビューで新しい PR ファイルの領域diff使用を改善しました

このページを更新して、ユーザーがヘッダーで画面の 40% を占めるのではなく、モバイルビューでより多くのファイルを表示できるように、このページを更新しました。

スペースの新しい PR ファイル名の使用の改善

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

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

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

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

ブランチエクスペリエンスの強化

Pipelines

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

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

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

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    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 つの実行のみが続行されます。その環境にデプロイする後続の実行は一時停止されます。排他ロックを使用した実行が完了すると、最新の実行が続行されます。中間実行はすべて取り消されます。

[チェックの追加] ページで、[排他ロック] を選択して、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 トリガーを構成する手順を次に示します。

外部サービスに Webhook を設定します。 Webhook を作成するときは、次の情報を入力する必要があります。
- 要求 URL - "https://dev.azure.com/<ADO コレクション>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
- シークレット - これは省略可能です。 JSON ペイロードをセキュリティで保護する必要がある場合は、 シークレット 値を指定します
新しい "着信 Webhook" サービス接続を作成します。これは、次の 3 つの重要な情報を定義できる、新しく導入されたサービス接続の種類です。
- Webhook 名: Webhook の名前は、外部サービスで作成した Webhook と一致する必要があります。
- HTTP ヘッダー - 要求検証のペイロードハッシュ値を含む要求内の HTTP ヘッダーの名前。たとえば、GitHub の場合、要求ヘッダーは "X-Hub-Signature" になります
- シークレット - シークレットは、受信要求の検証に使用されるペイロードハッシュを解析するために使用されます (これは省略可能です)。 Webhook の作成でシークレットを使用した場合は、同じシークレットキーを指定する必要があります
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}}

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

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

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

リソーストリガーは、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リポジトリ内toolsのブランチまたはreleaseブランチ

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

エージェントログのアップロードが改善されました

エージェントが 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 呼び出しを行います。ジョブごとに新しいアクセストークンが生成され、ジョブが完了すると有効期限が切れます。

この更新プログラムでは、アクセストークンのスコープを制限することでパイプラインのセキュリティを強化し、従来のリリースにも同じものを拡張します。

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

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コンパイル時の式 (${{ }}) を使用できませんでした。このリリースでは、コンテナーに対するこの制限が解除されました。これにより、リソース内でランタイムパラメーターの内容を使用できます。たとえば、キュー時にコンテナーを選択できます。このサポートは、時間の経過とともに他のリソースに拡張する予定です。

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% をノード 10 に移行しました。エージェントは、ノード 6 とノード 10 の両方のタスクを実行できるようになりました。今後の更新では、エージェントから Node 6 を完全に削除します。エージェントからの Node 6 の削除を準備するために、社内拡張機能とカスタムタスクを更新して、ノード 10 もすぐに使用するよう要求します。タスクにノード 10 を使用するには、の下executionでから Node にNode10更新しますtask.json。

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

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

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

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

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

新しい Web プラットフォーム変換。

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

[ポリシー] タブでクロスリポジトリポリシーを表示します。

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

[ブランチ] を選択してポリシーを表示します。

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

ポリシーが継承された場所を表示します。

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

セクションごとにフィルターを検索します。

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

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

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

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 パラメーター

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

要求本文

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

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

フィードバック

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

ページの先頭へ

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

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

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

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

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

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

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

TFX の構成

TFX を使用してタスクを更新する

パイプラインの要件

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

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

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

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

TFX の構成

TFX を使用してタスクを更新する

パイプラインの要件

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

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

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

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

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

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

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

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

Azure DevOps Server 2020.1.1 パッチ 4 リリース日: 2022 年 1 月 26 日

インストール手順

Azure DevOps Server 2020.1.1 パッチ 3 リリース日: 2021 年 12 月 15 日

Azure DevOps Server 2020.1.1 パッチ 2 リリース日: 2021 年 10 月 26 日

Azure DevOps Server 2020.1.1 パッチ 1 リリース日: 2021 年 9 月 14 日

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

Azure Boards

Azure Repos

Azure Pipelines

全般

Azure Test Plans

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

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

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

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

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

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

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

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

Boards

状態遷移の制限規則

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

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

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

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

Azure Boards GitHub アプリ リポジトリの制限が引き上げ

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

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

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

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

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

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

[作業項目] ページで削除されたアイテム

Repos

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

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

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

Pull Request エクスペリエンスの機能強化

Pipelines

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

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

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

排他展開ロック ポリシー

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

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

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

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

エージェント ログのアップロードが改善されました

必要に応じて、コンテナー ボリュームを読み取り専用でマウントする

コンテナーの開始/停止に対するきめ細かい制御

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

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

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

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

YAML resources ブロックで使用できるテンプレート式

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

Azure Boards GitHub アプリリポジトリの制限が引き上げ

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

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

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

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

排他展開ロックポリシー

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

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

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

エージェントログのアップロードが改善されました

必要に応じて、コンテナーボリュームを読み取り専用でマウントする

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

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

YAML `resources` ブロックで使用できるテンプレート式

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

パッケージバージョンの更新 REST API を Maven パッケージで使用できるようになりました