Azure DevOps Server 2022 リリースノート

[アーティクル]
11/14/2023

| | Developer Communityシステム要件と互換性 | ライセンス条項 | DevOps ブログ | SHA-256 ハッシュ |

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

Azure DevOps Server展開のインストールまたはアップグレードの詳細については、「Azure DevOps ServerAzure 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累積的です。Patch 3 をインストールしなかった場合、このパッチには Azure Pipelines エージェントの更新プログラムが含まれます。 Patch 5 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

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

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

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

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

Note

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

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

パイプライン実行モデルをアップグレードしてパイプラインがスタックする原因となったバグを修正しました。
パッチアップグレードマシンで "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 のパッチをリリースしました。これには、次の修正プログラムが含まれています。

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 のパッチをリリースしました。これには、次の修正プログラムが含まれています。

CVE-2023-36869: Azure DevOps Serverスプーフィングの脆弱性。
大きなメタデータ 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 のパッチをリリースしました。これには、次の修正プログラムが含まれています。

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

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

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

Azure DevOps Server管理コンソールで SMTP 関連の設定を更新した後に tfsjobagent サービスとAzure DevOps Serverアプリケーションプールを再起動する必要がある問題に対処しました。
エンドポイントの状態を参照渡しではなく、サービスエンドポイント編集パネルにコピーします。
以前は、サービス接続を編集するときに、[キャンセル] ボタンを選択した後、UI で編集が保持されていました。このパッチでは、チームが通知配信を [配信しない] に設定した場合の Notification SDK で修正されています。このシナリオでは、通知サブスクリプションが [チーム優先 配信] オプションで構成されている場合、チームメンバーは通知を受け取りません。メンバーの好みをチェックするために、チームの下の 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/config1 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 つのメインビューがあります。プランの右側にある虫眼鏡をクリックして、プランを拡大または縮小することもできます。

コンデンスビュー

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

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

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

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

依存関係の追跡

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

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

依存関係の表示

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

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

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

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

問題がある場合、線の色は赤で、依存関係アイコンも同じになります。

次に例を示します。

カードのスタイル

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

スタイル設定

変更前

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

クリック後

後のカードのスタイル

配信プランの詳細については、こちらのドキュメントをチェックしてください。

作業項目ハブの削除済みアイテム

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

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

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

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

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

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

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

Pipelines

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

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

これが意味する内容: パイプラインごとの保持ルールを持つ従来のビルドパイプラインは、プロジェクトレベルの保持ルールによって管理されます。

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

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

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

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

パイプラインの logging コマンドを使用して変数を設定することに依存する多くのユーザーがいます。このリリースでは、コマンドの不要な使用のリスクを軽減するために、次の変更を 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 リポジトリのフォークからコントリビューションビルドすると、ジョブアクセストークンに付与されるアクセス許可が制限され、そのようなジョブによるパイプラインシークレットへのアクセスは許可されません。フォークの構築のセキュリティの詳細については、こちらのドキュメントを参照してください。

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

この設定は、パイプラインエディター の [トリガー] から変更できます。この設定を変更する前に、この構成を有効にすることのセキュリティへの影響を十分に理解しておく必要があります。

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

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

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

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

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

チェックの追加

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

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

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

Note

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

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

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

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

シークレット変数

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

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

環境の自動作成の変更

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 のアプリと Azure DevOps の拡張機能に依存しています。これで、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完全な一覧については、GitHub の問題を参照してください。windows-2019 イメージにインストールされているソフトウェアの完全な一覧については、こちらをチェック。

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

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

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

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

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

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

.NET 6 のリリースでは、新しいクロスプラットフォーム機能を利用できます。具体的には、Apple シリコンと 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 の種類の 1 つをコピーすると、ファイルのコンテンツタイプが正しく設定されます。
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 Runs REST API はリポジトリのみを self 返しました。この更新プログラムでは、Pipelines Runs REST API はビルドのすべてのリポジトリリソースを返します。

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

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

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

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

例を見てみましょう。たとえば、pull request 検証のためにエンドツーエンドのテストを実行するパイプラインを作成しているとします。目標は、システムの 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 HTTP コード 200 を dimensionsapi 返しますが、 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` プロパティは廃止されました

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

Repos

新しい TFVC ページ

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

リポジトリを無効にする

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

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

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

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

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

リポジトリを無効にする

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

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

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

すべてのリポジトリ設定

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

フォークユーザーがアップストリーム PR に投票できないようにする

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

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

リポジトリ設定

レポート

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

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

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

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

フィードバック

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

ページの先頭へ