Azure DevOps Server 2022 リリースノート

[アーティクル]
07/17/2024

| Developer Community | System Requirements and Compatibility | License Terms | DevOps Blog | SHA-256 Hashes |

この記事では、Azure DevOps Server の最新リリースに関する情報を確認できます。

Azure DevOps Server のデプロイのインストールまたはアップグレードの詳細については、「 Azure DevOps Server の要件を参照してください。

Azure DevOps Server 製品をダウンロードするには、 Azure DevOps Server のダウンロードページを参照してください。

Azure DevOps Server 2022 への直接アップグレードは、Azure DevOps Server 2019 または Team Foundation Server 2015 以降からサポートされています。 TFS デプロイが TFS 2013 以前の場合は、Azure DevOps Server 2022 にアップグレードする前にいくつかの中間手順を実行する必要があります。詳細については、「インストール」ページを参照してください。

Azure DevOps Server 2022 Update 0.1 Patch 5 リリース日: 2023 年 11 月 14 日

Note

Azure DevOps Server のパッチは累積的です。パッチ 3 をインストールしなかった場合、このパッチには Azure Pipelines エージェントの更新プログラムが含まれます。 Patch 5 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

ファイル	Sha-256 ハッシュ
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

Enable シェルタスク引数パラメーターの検証の文字の許可リストを PowerShell タスクで拡張しました。
[キャンセル] ボタンをクリックした後にサービス接続の編集が永続的になる原因となった問題を修正します。

Azure DevOps Server 2022 Update 0.1 Patch 4 リリース日: 2023 年 10 月 10 日

Note

Azure DevOps Server のパッチは累積的です。パッチ 3 をインストールしなかった場合、このパッチには Azure Pipelines エージェントの更新プログラムが含まれます。 Patch 5 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

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

パイプライン実行モデルをアップグレードしてパイプラインがスタックする原因となったバグを修正しました。
パッチアップグレードマシンで "Analysis Owner" ID が非アクティブ ID と表示されるバグを修正しました。
ビルドクリーンアップジョブには多くのタスクが含まれており、それぞれがビルドの成果物を削除します。これらのタスクのいずれかが失敗した場合、後続のタスクは実行されません。タスクの失敗を無視し、できるだけ多くの成果物をクリーンアップするように、この動作を変更しました。

Azure DevOps Server 2022 Update 0.1 Patch 3 リリース日: 2023 年 9 月 12 日

Note

このパッチには、Azure Pipelines エージェントの更新プログラムが含まれています。 Patch 3 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

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

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

Azure DevOps Server 2022 Update 0.1 Patch 2 リリース日: 2023 年 8 月 8 日

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

CVE-2023-36869: Azure DevOps サーバーのスプーフィングの脆弱性。
大きなメタデータ XML 応答に対して ArithmeticException を発生できる SOAP 呼び出しのバグを修正しました。
コンポーネントの無視時にエンドポイントの状態がフラッシュされるように、サービス接続エディターに対する変更を実装しました。
マークダウンファイルで相対リンクが機能しない問題に対処しました。
多数のタグが定義されている場合に、通常よりも起動に時間がかかるアプリケーション層に関連するパフォーマンスの問題を修正しました。
[エージェントプール] ページTF400367エラーに対処しました。
分析所有者 ID が非アクティブ ID として表示されるバグを修正しました。
CronScheduleJobExtension の無限ループバグを修正しました。

Azure DevOps Server 2022 Update 0.1 Patch 1 リリース日: 2023 年 6 月 13 日

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

CVE-2023-21565: Azure DevOps サーバーのスプーフィングの脆弱性。
CVE-2023-21569: Azure DevOps サーバーのスプーフィングの脆弱性。
サービス接続エディターのバグを修正しました。コンポーネントの破棄時に下書きエンドポイントの状態がフラッシュされるようになりました。
デタッチまたはアタッチコレクションが失敗し、"TF246018: データベース操作がタイムアウト制限を超え、取り消されました" というエラーが報告されるバグを修正しました。

Azure DevOps Server 2022 Update 0.1 リリース日: 2023 年 5 月 9 日

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

Azure DevOps Server 2022 Update 0.1 RC リリース日: 2023 年 4 月 11 日

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

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

セキュリティの脆弱性に対処するために、Git 仮想ファイルシステム (GVFS) を v2.39.1.1-micorosoft.2 にアップグレードしました。
テストデータが削除されず、データベースが拡張されました。この修正により、新しい孤立したテストデータが作成されないようにビルドリテンション期間が更新されました。
AnalyticCleanupJob が更新され、ジョブの状態が停止し、成功と報告されました。
"指定されたキーがディクショナリに存在しなかった" というエラーで "tfx extension publish" コマンドが失敗する問題を修正しました。
チームカレンダー拡張機能へのアクセス中に対処してエラーを発生させる回避策を実装しました。
CVE-2023-21564: Azure DevOps Server のクロスサイトスクリプティングの脆弱性
CVE-2023-21553: Azure DevOps Server のリモートコード実行の脆弱性
Visual Studio 2022 をサポートするように MSBuild タスクと VSBuild タスクを更新しました。
XSS 攻撃ベクトルを防ぐために再認証を読み込む方法を更新します。
Azure DevOps Server 2022 プロキシは、次のエラーを報告します。VS800069: このサービスは、オンプレミスの Azure DevOps でのみ使用できます。
Web UI を使用したシェルブセットのアクセシビリティの問題を修正しました。
Azure DevOps Server 管理コンソールで SMTP 関連の設定を更新した後に tfsjobagent サービスと Azure DevOps Server アプリケーションプールを再起動する必要がある問題に対処しました。
有効期限の 7 日前に PAT の通知が送信されませんでした。

Azure DevOps Server 2022 Patch 4 リリース日: 2023 年 6 月 13 日

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

CVE-2023-21565: Azure DevOps サーバーのスプーフィングの脆弱性。
CVE-2023-21569: Azure DevOps サーバーのスプーフィングの脆弱性。
サービス接続エディターのバグを修正しました。コンポーネントの破棄時に下書きエンドポイントの状態がフラッシュされるようになりました。
デタッチまたはアタッチコレクションが失敗し、"TF246018: データベース操作がタイムアウト制限を超え、取り消されました" というエラーが報告されるバグを修正しました。

Azure DevOps Server 2022 Patch 3 リリース日: 2023 年 3 月 21 日

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

Azure DevOps Server 管理コンソールで SMTP 関連の設定を更新した後に tfsjobagent サービスと Azure DevOps Server アプリケーションプールを再起動する必要がある問題に対処しました。
エンドポイントの状態を参照渡しではなく、サービスエンドポイント編集パネルにコピーします。
以前は、サービス接続を編集するときに、[キャンセル] ボタンを選択した後、編集が UI に保持されていました。このパッチでは、チームが通知配信を Do not deliver に設定した場合の Notification SDK で修正されました。このシナリオでは、通知サブスクリプションが Team 基本設定 配信オプションで構成されている場合、チームメンバーは通知を受け取りません。メンバーの設定を確認するために、チームの下の ID をさらに拡張する必要はありません。

Azure DevOps Server 2022 Patch 2 リリース日: 2023 年 2 月 14 日

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

CVE-2023-21564: Azure DevOps Server のクロスサイトスクリプティングの脆弱性
Visual Studio 2022 をサポートするように MSBuild タスクと VSBuild タスクを更新しました。
XSS 攻撃ベクトルの可能性を防ぐために、再認証を読み込む方法を更新します。
Azure DevOps Server 2022 プロキシは、次のエラーを報告します。VS800069: このサービスは、オンプレミスの Azure DevOps でのみ使用できます。

Azure DevOps Server 2022 Patch 1 リリース日: 2023 年 1 月 24 日

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

テストデータが削除されず、データベースが拡張されました。この修正により、新しい孤立したテストデータが作成されないようにビルドリテンション期間が更新されました。
AnalyticCleanupJob が更新され、ジョブの状態が停止し、成功と報告されました。
"指定されたキーがディクショナリに存在しなかった" というエラーで "tfx extension publish" コマンドが失敗する問題を修正しました。
チームカレンダー拡張機能へのアクセス中に対処してエラーを発生させる回避策を実装しました。

Azure DevOps Server 2022 リリース日: 2022 年 12 月 6 日

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

Azure DevOps Server 2022 RC2 リリース日: 2022 年 10 月 25 日

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

Note

有効になっている新しい SSH RSA アルゴリズム

RSA 公開キーのサポートは、以前にサポートしていた SHA1 SSH-RSA に加えて、SHA2 公開キーの種類をサポートするように改善されました。

現在サポートされている公開キーの種類は次のとおりです。

SSH-RSA
RSA-SHA2-256
RSA-SHA2-512

必要な対応

ファイルで SSH-RSA を明示的に指定して SSH-RSA を有効にする回避策を実装した場合は、PubkeyAcceptedTypesを削除するか、RSA-SHA2-256 または RSA-SHA2-512、またはその両方を使用するように変更する必要があります。パスワードの入力を求められた場合に GIT_SSH_COMMAND="ssh -v" git fetch 相互署名アルゴリズムが表示されない場合の詳細については、こちらのドキュメントを参照してください。

楕円キーのサポートはまだ追加されておらず、バックログで引き続き高く要求されている機能です。

Azure DevOps Server 2022 RC1 リリース日: 2022 年 8 月 9 日

Azure DevOps Server 2022 の新機能の概要

重要

Warehouse and Analysis Service は、以前のバージョンの Azure DevOps Server (2020) で非推奨になりました。 Azure DevOps Server 2022 では、Warehouse and Analysis Service が製品から削除されました。分析によって、製品内レポートエクスペリエンスが提供されるようになりました。

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

配信計画
コミットリンクに正しいペルソナを表示する
パイプライン内の環境変数の新しいコントロール
フォークビルドの無制限トークンを生成する
新しい TFVC ページ
グラフウィジェットで使用可能なタグ別のグループ化

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

Boards
Repos
パイプライン
レポート

Boards

配信計画

配信プランが Azure DevOps Server に含まれるようになったことをお知らせします。配信計画には、次の 3 つの主要なシナリオが用意されています。

プランのタイムラインビュー
作業の進行状況
依存関係の追跡

主な機能を次に示します。フィルター処理、マーカー、フィールド条件も配信計画の一部です。

2 つの主なビューがあります。

配信計画 2.0 では、開始日とターゲットの日付またはイテレーションの日付を使用して、タイムラインでプラン内のすべての作業項目を表示できます。優先順位は開始日とターゲットの日付で、その後にイテレーションが続きます。これにより、イテレーションに定義されていないポートフォリオレベルの作業項目 (例:Epic) を追加できます。

分割ビューと展開ビューの 2 つの主なビューがあります。プランの右側にある虫眼鏡をクリックして、プランを拡大または縮小することもできます。

分割ビューと展開ビューの 2 つの主なビューがあります。プランの右側にある虫眼鏡をクリックして、プランを拡大または縮小することもできます。

コンデンスビュー

要約ビューには、すべての作業項目カード collapsed が表示されます すべてのカード情報が表示されるわけではありません。このビューは、プラン内の作業の全体的なビューに役立ちます。カードフィールドを折りたたむには、プランの右側にある虫眼鏡アイコンの横にあるカードアイコンをクリックします。

縮小ビューと展開ビューを切り替えるプランの例を次に示します。
展開ビュー

展開されたビューには、子とリンクされたアイテムの数をカウントし、完了率を表示することで、作業項目の進行状況が表示されます。現在の進行状況は、作業項目数によって決まります。

展開ビューを使用したプランの例を次に示します。進行状況バーと完了率に注意してください。

依存関係の追跡

依存関係の追跡は、作業項目で定義されている先行リンクと後続リンクに基づいています。これらのリンクが定義されていない場合、依存関係行は表示されません。作業項目に依存関係の問題がある場合、依存関係リンクアイコンは赤で表示されます。

依存関係を示す赤い依存関係アイコンを使用した依存関係の追跡

依存関係の表示

特定の依存関係は、方向を含め、その作業項目のすべての依存関係を表示する依存関係パネルを通じて表示されます。赤い感嘆符は、依存関係の問題を示します。パネルを表示するには、カードの右上隅にある依存関係リンクアイコンをクリックするだけです。依存関係の例を次に示します。
依存関係行

作業項目間の依存関係は、それぞれの作業項目間の方向矢印線で視覚化されます。複数の依存関係が複数の行として表示されます。赤い色の線は問題を示します。

いくつか例を挙げます。

複数の依存関係を持つ作業項目の例を次に示します。また、コンデンスビューを使用して動作します。

問題が発生すると、線の色が赤になり、依存関係アイコンも表示されます。

次に例を示します。

カードのスタイル設定

かんばんボードなどのルールを使用してカードのスタイルを設定できるようになりました。プランの設定を開き、 Styles をクリックします。 [スタイル] ウィンドウで、 + スタイルルールの追加 をクリックしてルールを追加し、[ 保存] をクリックします。ルールは最大 10 個まであり、各ルールには最大 5 つの句を含めることができます。

スタイル設定

以前

前のカードスタイル

クリック後

後のカードのスタイル設定

配送計画の詳細については、こちらのドキュメントを参照してください。

作業項目ハブのアイテムを削除しました

作業項目ハブは、作成したアイテムまたは自分に割り当てられているアイテムの一覧を表示する場所です。作業項目の一覧表示を効率化するために、カスタマイズされたピボットとフィルターの機能がいくつか用意されています。 自分に割り当てられたピボットの上位の苦情の 1 つは、削除された作業項目が表示されていることです。削除された作業項目は価値がなくなり、バックログに含まれてはならないことに同意します。このスプリントでは、作業項目ハブの Assigned to me ビューからすべての Removed 項目を非表示にします。

コミットリンクに正しいペルソナを表示する

作業項目の 開発セクション には、関連するコミットとプル要求の一覧が表示されます。コミット要求またはプル要求の作成者を、関連付けられた時刻と共に表示できます。この更新プログラムでは、作成者のアバターがビューに正しく表示されない問題を修正しました。

作業項目の履歴から削除された添付ファイルをダウンロードする機能を削除する

フォームから添付ファイルが削除された後でも、ユーザーが作業項目の履歴から添付ファイルをダウンロードできる小さな問題を修正しました。これで、添付ファイルが削除されると、履歴からダウンロードすることも、REST API 応答からダウンロード URL を使用することもできなくなります。

バグ理由フィールドに "修正しない" 値を追加しました

他のすべての作業項目の種類と同様に、バグ作業項目の種類には明確に定義されたワークフローがあります。各ワークフローは、3 つ以上の状態と理由で構成されます。理由は、ある状態から別の状態に項目が遷移する理由を指定します。この更新プログラムでは、アジャイルプロセスのバグ作業項目の種類の 修正しない 理由の値を追加しました。この値は、[バグ] を [新規] または [アクティブ] から [解決済み] に移動する場合に使用できます。ソフトウェアバグの、キャプチャ、トリアージ、管理の方法の詳細については、Azure Boards のドキュメントを参照してください。

Pipelines

クラシックビルドでのパイプラインごとの保持ポリシーの削除

Azure DevOps プロジェクト設定で、クラシックビルドと YAML パイプラインの両方のアイテム保持ポリシーを構成できるようになりました。クラシックビルドパイプラインのパイプラインごとのリテンション期間ルールはサポートされなくなりました。これは YAML パイプラインのリテンション期間を構成する唯一の方法ですが、パイプラインごとにクラシックビルドパイプラインのリテンション期間を構成することもできます。今後のリリースで、クラシックビルドパイプラインのパイプラインごとのリテンション期間ルールをすべて削除しました。

つまり、パイプラインごとのリテンション期間ルールを持つ従来のビルドパイプラインは、プロジェクトレベルのリテンション期間ルールによって管理されます。

アップグレード時にビルドが失われるのを確実にしないように、アップグレード時にリースがないすべてのビルドのリースを作成します。

アップグレード後にプロジェクトレベルの保持設定を確認することをお勧めします。パイプラインにカスタムルールが特に必要な場合は、パイプラインでカスタムタスクを使用できます。タスクを通じて保持リースを追加する方法については、ビルド、リリース、テストのセットの保持ポリシーに関するドキュメントを参照してください。

パイプライン内の環境変数の新しいコントロール

Azure Pipelines エージェントは、標準出力で特殊なログコマンドをスキャンしそれらを実行します。 setVariable commandを使用して、変数を設定したり、以前に定義した変数を変更することができます。これは、システムの外部にあるアクターによって悪用される可能性があります。たとえば、パイプラインに ftp サーバー内のファイルの一覧を出力する手順がある場合、ftp サーバーにアクセスできるユーザーは、 setVariable コマンドを含む名前の新しいファイルを追加し、パイプラインの動作を変更できます。

パイプラインでログコマンドを使用して変数を設定することに依存する多くのユーザーがいます。このリリースでは、 setVariable コマンドの不要な使用のリスクを軽減するために、次の変更を行っています。

タスク作成者向けの新しいコンストラクトが追加されました。 task.jsonに次のようなスニペットを含めることで、タスク作成者はタスクによって変数が設定されるかどうかを制御できます。

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}

さらに、ssh などの多くの組み込みタスクを更新して、悪用できないようにしています。
最後に、YAML コンストラクトを使用して、ステップで変数を設定できるかどうかを制御できるようになりました。

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

フォークビルドの無制限トークンを生成する

GitHub Enterprise ユーザーは、通常、フォークを使用してアップストリームリポジトリに投稿します。 Azure Pipelines は、GitHub Enterprise リポジトリのフォークから投稿を作成するときに、ジョブアクセストークンに付与されるアクセス許可を制限し、そのようなジョブによるパイプラインシークレットへのアクセスを許可しません。フォークの構築のセキュリティの詳細については、ドキュメントを参照してください。

これは、ユーザーが内部ソースのコラボレーションモデルの恩恵を受ける可能性がある、このような閉じた環境では、望ましいよりも制限が厳しい場合があります。パイプラインで設定を構成してシークレットをフォークで使用できるようにすることはできますが、ジョブアクセストークンスコープを制御する設定はありません。このリリースでは、フォークのビルドでも通常のジョブアクセストークンを生成する制御を提供しています。

この設定は、パイプラインエディターの Triggers から変更できます。この設定を変更する前に、この構成を有効にした場合のセキュリティへの影響を十分に理解しておいてください。

フォークビルドの無制限トークンを生成する

YAML パイプラインの保護されたリソースとしてのリポジトリ

Azure DevOps プロジェクトを整理して、多数のサブプロジェクトをホストできます。それぞれに独自の Azure DevOps Git リポジトリと 1 つ以上のパイプラインがあります。この構造では、どのパイプラインがどのリポジトリにアクセスできるかを制御できます。たとえば、同じプロジェクトに 2 つのリポジトリ A と B があり、これらのリポジトリを通常ビルドする 2 つのパイプライン X と Y があるとします。パイプライン Y がリポジトリ A にアクセスできないようにすることができます。一般に、A の共同作成者は、アクセスを提供するパイプラインを制御する必要があります。

これは Azure Git リポジトリとパイプラインで部分的に可能でしたが、管理の経験はありませんでした。この機能は、そのギャップに対処します。 Azure Git リポジトリは、サービス接続やエージェントプールと同様に、YAML パイプラインで保護されたリソースとして扱えるようになりました。

リポジトリ A の共同作成者として、リポジトリにチェックとパイプラインのアクセス許可を追加できます。これを行うには、プロジェクト設定に移動し、[リポジトリ]、[リポジトリ] の順に選択します。 "チェック" という新しいメニューが表示されます。このメニューでは、Azure 関数の形式で任意のインザボックスチェックまたはカスタムチェックを構成できます。

チェックを追加する

[セキュリティ] タブでは、リポジトリにアクセスできるパイプラインの一覧を管理できます。

[セキュリティ] タブでパイプラインの一覧を管理する

YAML パイプラインがリポジトリを使用するたびに、Azure Pipelines インフラストラクチャは、すべてのチェックとアクセス許可が満たされていることを確認し、確認します。

Note

これらのアクセス許可とチェックは、YAML パイプラインにのみ適用されます。クラシックパイプラインでは、これらの新機能は認識されません。

変数グループとセキュリティで保護されたファイルに対するアクセス許可とチェック

YAML パイプラインでは、さまざまな種類の共有リソースを使用できます。たとえば、サービス接続、変数グループ、セキュリティで保護されたファイル、エージェントプール、環境、またはリポジトリなどがあります。リソースへのアクセスからパイプラインを保護するために、リソースの所有者はアクセス許可を構成し、そのリソースを確認できます。パイプラインがリソースにアクセスしようとするたびに、構成されているすべてのアクセス許可とチェックが評価されます。これらの保護は、しばらくの間、サービス接続、環境、およびエージェントプールで使用できます。これらは最近、 repositoriesに追加されました。このリリースでは、変数グループとセキュリティで保護されたファイルに同じ保護を追加します。

変数グループまたはセキュリティで保護されたファイルへのアクセスを少数のパイプラインに制限するには、 Pipelines のアクセス許可 機能を使用します。

自分のシークレット変数

パイプラインを実行するたびに評価する必要があるチェックまたは承認を構成するには、 Approvals と Library チェック機能を使用します。

チェックの承認を追加する

環境の自動作成の変更

YAML パイプラインを作成し、存在しない環境を参照すると、Azure Pipelines によって環境が自動的に作成されます。この自動作成は、ユーザーコンテキストまたはシステムコンテキストで行うことができます。次のフローでは、Azure Pipelines は操作を実行しているユーザーを認識します。

Azure Pipelines の Web エクスペリエンスで YAML パイプライン作成ウィザードを使用し、まだ作成されていない環境を参照します。
Azure Pipelines の Web エディターを使用して YAML ファイルを更新し、存在しない環境への参照を追加した後にパイプラインを保存します。上記の各ケースでは、Azure Pipelines は操作を実行しているユーザーを明確に理解しています。そのため、環境が作成され、その環境の管理者ロールにユーザーが追加されます。このユーザーには、環境を管理したり、環境を管理するためのさまざまなロールに他のユーザーを含めたりするためのすべてのアクセス許可があります。

次のフローでは、Azure Pipelines には、環境を作成するユーザーに関する情報がありません。別の外部コードエディターを使用して YAML ファイルを更新し、存在しない環境への参照を追加してから、継続的インテグレーションパイプラインをトリガーします。この場合、Azure Pipelines はユーザーを識別できません。以前は、すべてのプロジェクトの共同作成者を環境のAdministratorロールに追加することで、このケースを処理していました。その後、プロジェクトのメンバーは、これらのアクセス許可を変更し、他のユーザーが環境にアクセスできないようにすることができます。

プロジェクトのすべてのメンバーに対する環境に対する管理者権限の付与に関するフィードバックを受け取りました。お客様のフィードバックに耳を傾けて、操作を実行しているユーザーが誰であるかが明確でない場合は、環境を自動作成するべきではないと聞きました。このリリースでは、環境を自動的に作成する方法を変更しました。

今後、パイプラインの実行では、環境が存在せず、ユーザーコンテキストが不明な場合は、自動的には作成されません。このような場合、パイプラインは Environment not found エラーで失敗します。適切なセキュリティを備えた環境を事前に作成し、パイプラインで使用する前に構成を確認する必要があります。
既知のユーザーコンテキストを持つパイプラインでは、過去と同様に環境が自動的に作成されます。
最後に、環境を自動的に作成する機能が追加されたのは、Azure Pipelines の使用を開始するプロセスを簡略化するためだけであることに注意してください。これは、実稼働シナリオではなく、テストシナリオ向けでした。常に適切なアクセス許可とチェックを使用して運用環境を事前に作成し、パイプラインで使用する必要があります。

ビルドパイプラインから Insights ダイアログを削除する

フィードバックに基づいて、ワークフローを改善するために、ビルドパイプライン内を移動するときに表示されるタスク/パイプライン分析情報ダイアログボックスが削除されました。必要な分析情報を得ることができるように、パイプライン分析は引き続き使用できます。

排他ロックチェックを使用する場合にのみ、最新ではなくシーケンシャルデプロイのサポート

YAML パイプラインでは、チェックを使用して、保護されたリソースに対するステージの実行を制御します。使用できる一般的なチェックの 1 つは、排他的ロックチェックです。このチェックにより、パイプラインからの 1 回の実行のみが続行されます。複数の実行が同時に環境にデプロイしようとすると、チェックによってすべての古い実行が取り消され、最新の実行のデプロイが許可されます。

古い実行を取り消す方法は、リリースが累積的であり、以前の実行からのすべてのコード変更が含まれている場合に適しています。ただし、コードの変更が累積されないパイプラインがいくつかあります。この新機能を使用すると、すべての実行を続行して環境に順番にデプロイしたり、以前の実行を取り消して最新の実行のみを許可したりする以前の動作を維持することができます。この動作は、パイプライン YAML ファイルの lockBehavior という新しいプロパティを使用して指定できます。 sequentialの値は、すべての実行が保護されたリソースに対して順番にロックを取得することを意味します。 runLatestの値は、最新の実行のみがリソースへのロックを取得することを意味します。

sequential デプロイまたは runLatest で排他ロックのチェックを使用するには、次の手順に従います。

環境 (または別の保護されたリソース) で排他ロックのチェックを有効にします。
パイプラインの YAML ファイルで、 lockBehaviorという新しいプロパティを指定します。これは、パイプライン全体または特定のステージに対して指定できます。

ステージに設定する場合:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

パイプラインに設定する場合:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

lockBehaviorを指定しない場合は、runLatestと見なされます。

ServiceNow のケベックバージョンのサポート

Azure Pipelines には、ServiceNow との既存の統合があります。統合は、ServiceNow の app と Azure DevOps の extension に依存します。これで、ServiceNow のケベックバージョンで動作するようにアプリが更新されました。クラシックパイプラインと YAML パイプラインの両方がケベック州で動作するようになりました。この統合が確実に機能するように、Service Now ストアから新しいバージョンのアプリ (4.188.0) にアップグレードします。詳細については、「 ServiceNow Change Management を使用した統合」を参照してください。

新しい YAML 条件式

${{ else }}式と${{ elseif }}式を使用することで、YAML ファイルでの条件式の記述が簡単になりました。 YAML パイプラインファイルでこれらの式を使用する方法の例を次に示します。

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

パスフィルターでのワイルドカードのサポート

ワイルドカードは、パイプライン YAML ファイル内の CI トリガーまたは PR トリガーの包含ブランチと除外ブランチを指定するときに使用できます。ただし、パスフィルターを指定するときに使用することはできません。たとえば、 src/app/**/myapp*に一致するすべてのパスを含めることはできません。これは、の顧客によって不便として指摘されています。この更新プログラムは、このギャップを埋めます。パスフィルターを指定するときに、ワイルドカード文字 (**、 *、または ?) を使用できるようになりました。

パイプラインの既定のエージェント仕様は Windows-2022 になります

windows-2022 イメージは、Azure Pipelines Microsoft でホストされるエージェントのwindows-latest ラベルの既定のバージョンになる準備ができています。これまで、このラベルは windows-2019 エージェントを指しています。この変更は、1 月 17 日から数週間にわたってロールアウトされます。移行は 3 月までに完了する予定です。

Azure Pipelines では、2021 年 9 月以降、 windows-2022 がサポートされています。 windows-2022画像の安定性を向上させるためにフィードバックを監視しました。これで、最新のイメージとして設定する準備ができました。

windows-2022イメージには、Visual Studio 2022 が含まれています。 windows-2022とwindows-2019の違いの完全な一覧については、GitHub の問題を参照してください。イメージにインストールされているソフトウェアの完全な一覧については、こちらを参照してください。

パイプラインフォルダーの名前変更によってアクセス許可が検証される

パイプラインを含むフォルダーの名前を変更できます。フォルダーの名前変更は、ユーザーがフォルダーに含まれる少なくとも 1 つのパイプラインに対する編集アクセス許可を持っている場合にのみ成功するようになりました。

Pipelines エージェントのランタイムアップグレード計画

パイプラインエージェントとは

Azure DevOps Pipeline Agent は、パイプラインジョブを実行するためにパイプラインホスト上で実行されるソフトウェア製品です。 Microsoft でホストされているエージェント、スケールセットエージェント、セルフホステッドエージェントで実行されます。後者の場合は、自分でインストールします。パイプラインエージェントはリスナーとワーカー (.NET で実装) で構成され、Worker は Node または PowerShell で実装されたタスクを実行するため、それらのランタイムをホストします。

.NET 6 および Red Hat 6 の非推奨への今後のアップグレード

.NET 6 のリリースにより新しいクロスプラットフォーム機能を利用できます。具体的には、Apple Silicon と Windows Arm64 のネイティブ互換性を提供できます。そのため、今後数か月以内に .NET 6 for Pipeline Agent (リスナーと Worker) に移行する予定です。

多くの制約が課されるため、2022 年 4 月 30 日にエージェントから Red Hat Enterprise Linux 6 のサポートが削除されます。

Azure ファイルコピータスクの更新

Azure ファイルコピータスクの新しいバージョンをロールアウトしています。このタスクは、Microsoft Azure ストレージ BLOB または仮想マシン (VM) にファイルをコピーするために使用されます。新しいバージョンには、コミュニティから頻繁に要求されたいくつかの更新プログラムがあります。

AzCopy ツールのバージョンが 10.12.2 に更新され、ファイルコンテンツタイプがサポートされています。その結果、PDF、Excel、PPT、またはサポートされている MIME タイプのいずれかをコピーすると、ファイルのコンテンツタイプが正しく設定されます。
新しいバージョンの AzCopy では、ターゲットの種類が Azure BLOB の場合にターゲットをクリーンアップするように設定を構成することもできます。このオプションを設定すると、そのコンテナー内のすべてのフォルダー/ファイルが削除されます。または、BLOB プレフィックスが指定されている場合、そのプレフィックス内のすべてのフォルダー/ファイルが削除されます。
新しいバージョンのタスクは、AzureRM モジュールではなくエージェントにインストールされている Az モジュールに依存します。これにより、タスクを使用する場合に不要な警告が削除されることがあります。

変更は、このタスクのメジャーバージョンの更新プログラムの一部です。新しいバージョンを使用するには、パイプラインを明示的に更新する必要があります。 AzureRM モジュールにまだ依存しているパイプラインを中断しないように、メジャーバージョンの更新を選択しました。

パイプラインの詳細ビューの新しい拡張ポイント

拡張機能でターゲットにできる 2 つの新しい拡張ポイントが追加されました。これらの機能拡張ポイントを使用すると、パイプラインヘッダーにカスタムボタンを追加し、パイプラインフォルダーのカスタムメニューを追加できます。

パイプラインヘッダーのカスタムボタン: ms.vss-build-web.pipelines-header-menu
パイプラインフォルダーのカスタムメニュー: ms.vss-build-web.pipelines-folder-menu

これらの新しい拡張ポイントを使用するには、 Azure DevOps 拡張機能の vss-extension.json マニフェストファイルに、それらを対象とする新しいコントリビューションを追加するだけです。

次に例を示します。

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

結果は次のようになります。

パイプラインヘッダーのカスタムボタン
パイプラインフォルダーのカスタムメニュー

Azure DevOps Services への移行の改善

Azure DevOps Server から Azure DevOps Services へのインポートを実行する場合は、Azure DevOps がパイプラインごとのリテンション期間ルールをサポートしなくなったことを考慮する必要があります。この更新プログラムでは、オンプレミスの Azure DevOps Server から Azure DevOps Services に移行するときに、これらのポリシーが削除されました。アイテム保持ポリシーの構成の詳細については、ビルド、リリース、テストのアイテム保持ポリシーの設定に関するドキュメントを参照してください。

パイプライン実行 REST API の改善

以前は、Pipelines は REST API を実行self リポジトリのみを返しました。この更新により、Pipelines Runs REST API はビルドのすべてのリポジトリリソースを返します。

拡張 YAML パイプラインテンプレートに、ステージ、ジョブ、およびデプロイのコンテキスト情報を渡すことができるようになりました

この更新プログラムでは、テンプレートと組み合わせて使用することを意図した job、deployment、stage YAML パイプラインコンポーネントの新しいtemplateContext プロパティを追加します。

templateContextを使用するシナリオを次に示します。

テンプレートを使用して、コードの重複を減らすか、パイプラインのセキュリティをする
テンプレートはパラメーターとして、 stages、 jobs、または deployments
テンプレートは入力リストを処理し、各ステージ、ジョブ、またはデプロイに対していくつかの変換を実行します。たとえば、各ジョブを実行する環境を設定したり、コンプライアンスを適用するための追加の手順を追加したりします。
この処理では、パイプライン作成者がリスト内の各ステージ、ジョブ、またはデプロイのテンプレートに追加情報を渡す必要があります

例を見てみましょう。たとえば、プル要求の検証のためにエンドツーエンドのテストを実行するパイプラインを作成しているとします。目標は、システムの 1 つのコンポーネントのみをテストすることですが、エンドツーエンドのテストを実行する予定であるため、システムのコンポーネントの多くを使用できる環境が必要であり、それらの動作を指定する必要があります。

他のチームにも同様のニーズがあることに気付いているので、環境をテンプレートに設定するための手順を抽出することにします。そのコードは次のようになります。

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

テンプレートは、 testSet パラメーター内の各ジョブについて、${{ testJob.templateContext.requiredComponents }} で指定されたシステムのコンポーネントの応答を設定して、${{ testJob.templateContext.expectedHTTPResponseCode }} を返します。

次の例のように、 testing-template.yml を拡張する独自のパイプラインを作成できます。

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

このパイプラインは、正と負の 2 つのテストを実行します。どちらのテストでも、 dimensionsapi コンポーネントを使用できる必要があります。 positive_test ジョブでは、dimensionsapiは HTTP コード 200 を返しますが、negative_testは HTTP コード 500 を返します。

グループ管理サービスアカウントをエージェントサービスアカウントとしてサポートする

Azure Pipelines エージェントは、Windows セルフホステッドエージェントのグループ管理サービスアカウントをサポートするようになりました。

グループ管理サービスアカウントは、サービスアカウントとして機能するドメインアカウントの一元的なパスワード管理を提供します。 Azure Pipelines エージェントはこの種類のアカウントを認識できるため、構成時にパスワードは必要ありません。

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

情報提供の実行

情報提供の実行では、Azure DevOps が YAML パイプラインのソースコードの取得に失敗したことが通知されます。このような実行は次のようになります。

最近実行されたパイプライン

Azure DevOps は、外部イベント (プッシュされたコミットなど) に応答して YAML パイプラインのソースコードを取得します。たとえば、コードの変更があるかどうかを確認し、スケジュールされた実行を開始するかどうかなど、内部トリガーに応答します。この手順が失敗すると、システムによって情報提供の実行が作成されます。これらの実行は、パイプラインのコードが GitHub または BitBucket リポジトリにある場合にのみ作成されます。

パイプラインの YAML コードの取得は、次の理由で失敗する場合があります。

リポジトリプロバイダーで障害が発生している場合
要求の調整
認証の問題
パイプラインの.yml ファイルの内容を取得できません

詳細については、情報の実行を参照してください。

ビルド定義 REST API `retentionRules` プロパティは廃止されました

Build Definition REST APIのBuildDefinition応答の種類では、このプロパティは常に空のセットを返すので、retentionRules プロパティは古いものとしてマークされるようになりました。

Repos

新しい TFVC ページ

さまざまなサービスでエクスペリエンスの一貫性とアクセシビリティを高めるという目的で、新しい Web プラットフォームを使用するように、Azure DevOps のさまざまなページを更新しています。新しい Web プラットフォームを使用するように TFVC ページが更新されました。このバージョンでは、新しい TFVC ページを一般公開しています。

リポジトリを無効にする

お客様は、多くの場合、リポジトリを無効にし、ユーザーがそのコンテンツにアクセスできないようにする方法を要求してきました。たとえば、次の場合にこれを行うことができます。

リポジトリにシークレットが見つかりました。
サードパーティ製のスキャンツールで、リポジトリがコンプライアンス違反であることが検出された。

このような場合は、問題の解決に取り組んでいる間に、リポジトリを一時的に無効にすることができます。この更新プログラムでは、 削除リポジトリ アクセス許可がある場合は、リポジトリを無効にすることができます。リポジトリを無効にすると、次の操作が行われます。

リポジトリの一覧にリポジトリを一覧表示できます
リポジトリの内容を読み取ることができません
リポジトリの内容を更新できません
Azure Repos UI でリポジトリにアクセスしようとしたときに、リポジトリが無効にされたことを示すメッセージを表示する

必要な軽減手順を実行した後、 Delete リポジトリ アクセス許可を持つユーザーは、リポジトリを再度有効にすることができます。リポジトリを無効または有効にするには、[プロジェクトの設定] に移動し、[リポジトリ] を選択してから、特定のリポジトリを選択します。

リポジトリを無効にする

ブランチ作成者が自分のブランチの「管理アクセス許可」を取得しないように構成する

新しいブランチを作成すると、そのブランチに対する "アクセス許可の管理" が取得されます。このアクセス許可を使用すると、他のユーザーのアクセス許可を変更したり、そのブランチに投稿する追加のユーザーを許可したりできます。たとえば、ブランチ作成者は、このアクセス許可を使用して、別の外部ユーザーがコードに変更を加えることを許可できます。または、パイプライン (ビルドサービス ID) がそのブランチのコードを変更できるようにする場合もあります。コンプライアンス要件が高い特定のプロジェクトでは、ユーザーはそのような変更を行うことができません。

この更新プログラムでは、チームプロジェクト内のすべてのリポジトリを構成し、ブランチ作成者が "アクセス許可の管理" アクセス許可を取得できないように制限できます。これを行うには、プロジェクト設定に移動し、[リポジトリ] を選択し、すべてのリポジトリまたは特定のリポジトリの [設定] を選択します。

すべてのリポジトリの設定

この設定は、既存の動作を模倣するために既定でオンになっています。ただし、この新しいセキュリティ機能を利用する場合は、オフにすることができます。

フォークユーザーが上流 PR に投票できないようにする

Azure Repos では、リポジトリに対する "読み取り" アクセス許可を持つユーザーは、リポジトリをフォークし、フォークを変更できます。アップストリームに変更を加えた pull request を送信するには、アップストリームに対する "pull requests に貢献する" アクセス許可が必要です。ただし、このアクセス許可は、アップストリームリポジトリ内のプル要求に投票できるユーザーも管理します。その結果、リポジトリの共同作成者ではないユーザーがプル要求を送信し、ブランチポリシーの設定方法に応じてマージされる場合があります。

内部ソースモデルを昇格させるプロジェクトでは、fork-and-contribute が一般的なパターンです。このパターンをさらにセキュリティで保護して昇格させるために、pull request に投票するアクセス許可を "pull request に投稿する" から "投稿" に変更しています。ただし、この変更はすべてのプロジェクトで既定で行われるわけではありません。このアクセス許可を切り替えるには、リポジトリでオプトインし、"Strict Vote Mode" という名前の新しいポリシーを選択する必要があります。 Azure Repos のフォークに依存する場合は、これを行うことをお勧めします。

リポジトリ設定

レポート

グラフウィジェットで使用可能なタグ別のグループ化

[タグ別グループ化] グラフウィジェットが、すべての顧客に対して既定で使用できるようになりました。グラフウィジェットを使用する場合、タグに使用できるオプションが追加されました。ユーザーは、ウィジェット内のすべてのタグまたはタグのセットを選択して、情報を視覚化できます。

グラフウィジェットで使用可能なタグ別のグループ化

以前は、バーンダウンウィジェットで構成され、ユーザー設定フィールドによって合計またはカウントされたカスタム作業項目の種類を表示できませんでした。この更新プログラムでは、この問題を修正しました。これで、バーンダウンウィジェットでカスタム作業項目の種類を確認できるようになりました。

フィードバック

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

ページのトップへ