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

[アーティクル]
02/15/2023

| 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 のインストールと構成」を参照してください。

2019 Azure DevOps Server から 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 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 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

新しく追加された AD ID がセキュリティダイアログ 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 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

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

Note

データ移行ツールは、このリリースから約 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 Patch 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 Patch 3 リリース日: 2021 年 12 月 15 日

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

"単語を含む" クエリの作業項目マクロを修正しました。以前は、クエリは改行を含む値に対して正しくない結果を返していました。
Maven パッケージバージョンの文字長の制限を増やします。
カスタム作業項目のレイアウト状態に関するローカライズの問題。
電子メール通知テンプレートのローカライズの問題。
フィールドに対して複数の 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 接続 ページの [プロジェクトの設定] にあります。
テスト計画ウィジェットに関する問題を解決します。テスト実行レポートに、結果に正しくないユーザーが表示されていました。
[プロジェクトの概要] 概要ページの読み込みに失敗する問題を修正しました。
製品のアップグレードを確認するために電子メールが送信されない問題を修正します。

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

Note

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

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

Azure Boards

通知メールの "作業項目の表示" ハイパーリンクがパブリック URL を使用していません。

Azure Repos

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

Azure Pipelines

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

全般

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

Azure Test Plans

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

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

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

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

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

Note

データ移行ツールは、このリリースから約 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 つの列から別の列に移動することはできません。代わりに、利害関係者は各作業項目を一度に 1 つずつ開き、状態値を更新する必要があります。これは長い間、お客様にとって問題点であり、作業項目を複数のボード列に移動できるようになったことをお知らせします。

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

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

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

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

バックログ

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

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

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

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

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

work-item-state

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

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

作業項目のリンク

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

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

説明の編集

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

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

状態をカスタマイズする

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

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

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

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

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

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

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

[作業項目] ページのアイテムを削除しました

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

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

Repos

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

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

default-branch-name

注: この機能を有効にしない場合、リポジトリはAzure Reposの既定の名前で初期化されます。現時点では、その既定値は master です。包括的な言語に対する Microsoft のコミットメントと顧客の要求を尊重するために、業界の同僚に参加して、この既定値を main に変更します。この変更は、今年の夏の後半に行われます。引き続き master を使用する場合は、この機能を今すぐ有効にして 、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 ファイル] タブで差分ウィンドウのサイズを変更するときにスクロール位置を保持する

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

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

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

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

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

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

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

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

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

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

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

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

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 を作成しました。これで、に https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview POST して、完成した 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% を Node 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 を統合するのに役立ちます。この更新プログラムでは、ServiceNow で管理されている変更管理プロセスを Azure Pipelines に認識させ、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 に関するアドバイスを得ることができます。

ページの先頭へ