Azure DevOps Server 2022 Update 2 リリースノート

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

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

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

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

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

Azure DevOps Server 2022.2 RTW リリース日: 2024 年 7 月 9 日

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

Azure DevOps Server 2022.2 RTW は、バグ修正のロールアップです。これには、以前にリリースされた Azure DevOps Server 2022.2 RC のすべての機能が含まれています。 Azure DevOps Server 2022.2 を直接インストールするか、Azure DevOps Server 2020、2019、または Team Foundation Server 2015 以降からアップグレードできます。このリリースでは、次の問題と脆弱性に対処しました。

CVE-2024-35266: Azure DevOps サーバーのスプーフィングの脆弱性
CVE-2024-35267: Azure DevOps サーバーのスプーフィングの脆弱性
開発者コミュニティフィードバックチケット: エージェントのバージョンは、Azure DevOps Server 2022.1 にアップグレードし、エージェントプールの構成で更新エージェントを使用した後に更新されません
開発者コミュニティフィードバックチケット: チーム構成ページの読み込みに関する問題
開発者コミュニティフィードバックチケット: 特定の地域形式の PR 電子メール通知で正しくない日付処理を修正しました

Azure DevOps Server 2022 Update 2 RC リリース日: 2024 年 5 月 7 日

Azure DevOps Server 2022.2 RC には、多くの新機能が含まれています。主な特徴:

領域パスと反復パスの制限
パイプラインの承認とチェックをバイパスする
YAML 検証の改善
Cargo Crates に対する Azure Artifacts のサポート
新しいダッシュボードディレクトリエクスペリエンス
テスト計画またはスイート ID を使用したクイックコピーとインポート

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

全般
Boards
Repos
パイプライン
アイテム
レポート

全般

テスト結果の発行タスク

テスト結果の発行タスクで、JUnit レポート形式のテスト実行添付ファイルがサポートされるようになりました。

Azure DevOps Web 拡張機能 SDK の新しいバージョン

この更新プログラムでは、Azure DevOps Web Extension SDK の新しいバージョンがリリースされます。クライアント SDK を使用すると、Web 拡張機能がホストフレームと通信できるようになります。次の用途に使用できます。

拡張機能が読み込まれているか、エラーが発生したことをホストに通知する
現在のページに関する基本的なコンテキスト情報 (現在のユーザー、ホスト、拡張機能の情報) を取得する
テーマ情報を取得する
AZURE DevOps への REST 呼び出しで使用する承認トークンを取得する
ホストフレームによって提供されるリモートサービスを取得する

完全な API リファレンスについては、 azure-devops-extension-sdk パッケージドキュメントを参照してください。この新しいバージョンでは、次のモジュールがサポートされます。

ES モジュールのサポート: SDK では、既存の AMD (非同期モジュール定義) モジュールに加えて、ES (ECMAScript) モジュールもサポートされるようになりました。 ES モジュール構文を使用して SDK をインポートできるようになりました。これにより、パフォーマンスが向上し、アプリケーションのサイズが小さくなります。
AMD モジュールの下位互換性: AMD モジュールの既存のサポートはそのまま残ります。プロジェクトで AMD モジュールを使用している場合は、変更を加えずに、以前と同様に引き続き使用できます。

使用方法:

ES モジュールの場合は、import ステートメントを使用してモジュールをインポートできます。

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

AMD モジュールを使用している場合は、 require 関数を使用して引き続き SDK をインポートできます。

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Boards

領域パスと反復パスの制限

制限は、大規模なグローバルサービスの正常性と効率を維持する上で重要な役割を果たしています。このリリースでは、領域パスと反復パスの両方に対して、プロジェクトあたり 10,000 のハード制限が導入されています。サービスのさまざまな制限の詳細については、「 Work の追跡、プロセス、およびプロジェクトの制限ページを参照してください。

領域パスと反復パスのスクリーンショット。

開発と展開の制御

プロジェクトの構成方法に応じて、作業項目から開発コントロールまたは配置コントロールを削除します。たとえば、リポジトリやパイプラインをオフにするようにプロジェクト設定を構成できます。

DevOps サービスのスクリーンショット。

作業項目に移動すると、対応する開発コントロールと配置コントロールがフォームに表示されなくなります。

関連する作業のスクリーンショット。

GitHub リポジトリを Azure Boards に接続する場合 GitHub リポジトリの開発コントロールが表示されます。

開発コントロールのスクリーンショット。

Repos

ユーザーが自分の変更を承認できないようにする新しい "ブランチポリシー"

ユーザーが承認する変更に関する制御を改善し、より厳しい規制/コンプライアンス要件に一致させるために、明示的に許可されない限り、ユーザーが自分の変更を承認できないようにするオプションを提供します。

ブランチポリシーを管理する機能を持つユーザーは、[新しい変更がプッシュされたとき] の下で、新しく追加されたオプション "イテレーションごとに少なくとも 1 つの承認を要求する" を切り替えることができるようになりました。このオプションを選択すると、最後のソースブランチの変更に対して少なくとも 1 つの承認投票が必要になります。ユーザーの承認は、そのユーザーによってプッシュされた過去の未承認のイテレーションに対してカウントされません。そのため、最後のイテレーションに対する追加の承認は、別のユーザーが行う必要があります。

次の図は、ユーザー A によって作成されたプル要求と、ユーザー B、C、A、C によってそのプル要求に対して行われた追加の 4 つのコミット (イテレーション) を示しています。2 回目のイテレーション (ユーザー B によるコミット) が完了した後、ユーザー C はそのことを承認しました。その時点で、ユーザー A の最初のコミット (pull request が作成されたとき) が暗黙的に承認され、新しく導入されたポリシーが成功します。 5 回目のイテレーション (ユーザー C の最後のコミット) の後、承認はユーザー A によって行われました。これは、ユーザー C によって行われた以前のコミットに対する暗黙的な承認ですが、4 番目のイテレーションでユーザー A によって行われた 2 番目のコミットの承認を意味するものではありませんでした。新しく導入されたポリシーを成功させるには、承認されていないイテレーション 4 が、ユーザー B、C、または pull request に変更を加えなかった他のユーザーからの承認によって承認される必要があります。

アクセス許可管理イメージ。

Note

ブランチポリシーが、レビュー担当者として構成されたグループを承認エンティティとして受け取るという既知の問題があります。グループ G のユーザー A がそのグループ G のメンバーである場合に必要な承認があるとします。上の図のようにユーザー A が承認を行った後 (5 回目のイテレーションの後)、グループ G の承認によってユーザー A によって行われた変更が承認されます。これは想定されておらず、RTW リリースで解決される予定です。

Blobless フィルターとツリーレスフィルターのサポート

Azure DevOps では、複製/フェッチ中に 2 つの追加のフィルター処理がサポートされるようになりました。これらは：--filter=blob:none そして --filter=tree:0 最初のオプション (blobless clone) は通常の開発に最適ですが、2 番目のオプション (ツリーレスクローン) は、ビルドの実行後に複製を破棄する場合に適しています。

SSH-RSA の非推奨

Azure Repos には、ユーザーが Azure Repos の Git リポジトリにアクセスするための 2 つの方法 (HTTPS と SSH) が用意されています。 SSH を使用するには、サポートされている暗号化方法のいずれかを使用してキーペアを作成する必要があります。以前は、SSH-RSA のみをサポートしており、SSH-RSA ここを有効にするようユーザーに依頼してきました。

この更新プログラムでは、SSH を使用して Azure Repos に接続するためにサポートされている暗号化方法として、SSH-RSA の廃止を発表します。詳細については、Azure Repos に対する SSH-RSA サポートのエンドブログ記事を参照してください。

Pipelines

意図しないパイプラインの実行を防ぐ

現在、YAML パイプラインで trigger セクションが指定されていない場合は、リポジトリにプッシュされた変更に対して実行されます。これにより、パイプラインが実行された理由が混乱し、意図しない実行が多数発生する可能性があります。

この動作を変更できる、 Disable 暗黙的な YAML CI トリガー という名前のプロジェクトコレクションおよびプロジェクトレベルのパイプライン設定を追加しました。トリガーセクションがない場合は、パイプラインをトリガーしないことを選択できます。

YAML CI トリガーのスクリーンショット。

承認とチェックがタイムアウトになったときにステージを再試行する

承認とチェックがタイムアウトになると、所属するステージはスキップされます。スキップされたステージに依存するステージもスキップされます。

承認時にステージを再試行し、タイムアウトを確認できるようになりました。以前は、これは承認がタイムアウトしたときにのみ可能でした。

ステージの再試行のスクリーンショット。

承認とチェックをバイパスする

承認とチェックサービス接続、リポジトリ、エージェントプールなどの重要なリソースへのアクセスを保護するのに役立ちます。一般的なユースケースは、運用環境にデプロイするときに承認とチェックを使用し、ARM サービス接続を保護することです。

たとえば、サービス接続に次のチェックを追加したとします。承認、営業時間チェック、および Azure 関数の呼び出しチェック (異なるリージョン間で遅延を強制するため)。

ここで、修正プログラムの展開を行う必要があるとします。パイプラインの実行を開始しますが、続行されません。ほとんどのチェックが完了するまで待機します。承認とチェックが完了するまで待つことはできません。

このリリースでは、実行中の承認とチェックをバイパスできるようにしました。修正プログラムを完了できます。

実行中の承認、営業時間、Azure 関数の呼び出し、REST API チェックの呼び出しをバイパスできます。

承認をバイパスします。

[承認をバイパスする] のスクリーンショット。

営業時間チェックをバイパスします。

[営業時間のバイパス] チェックのスクリーンショット。

Azure 関数の呼び出しチェックをバイパスします。営業時間チェックをバイパスします。

[Azure 関数の呼び出しのバイパス] チェックのスクリーンショット。

チェックがバイパスされると、チェックパネルで確認できます。

バイパスされたチェックのスクリーンショット。

チェックをバイパスできるのは、チェックが定義されたリソースの管理者である場合のみです。

必要な YAML テンプレートのスクリーンショット。

Azure 関数チェックの呼び出しを再実行する

システムを複数のステージでデプロイするとします。 2 番目のステージをデプロイする前に、システムの既にデプロイされている部分に対してサニティチェックを実行する承認と Azure 関数の呼び出しチェックがあります。

承認要求を確認すると、サニティチェックが 2 日前に実行されたことがわかります。このシナリオでは、サニティチェックの結果に影響を与えた別のデプロイを認識している可能性があります。

この更新プログラムでは、Azure 関数の呼び出しと REST API の呼び出しチェックを再実行できます。この機能は、成功し、再試行がないチェックでのみ使用できます。

動的チェックのスクリーンショット。

Note

チェックを再実行できるのは、チェックが定義されたリソースの管理者である場合のみです。

必要なテンプレートチェックでの GitHub エンタープライズサーバーのサポート

テンプレートは、プロジェクトコレクション内のパイプラインのステージ、ジョブ、およびステップを制御できるセキュリティメカニズムです。

Require テンプレートチェックを使用すると、エージェントプールやサービス接続などの保護されたリソースにアクセスする前に、一連の承認済みテンプレートからパイプラインを拡張するように強制できます。

GitHub Enterprise Server リポジトリにあるテンプレートを指定できるようになりました。

すべての環境の管理者ロール

YAML パイプラインの環境は、AKS クラスターや VM のセットなど、アプリケーションをデプロイするコンピューティングリソースを表します。これらは、デプロイのセキュリティ制御と追跡可能性を提供します。

環境の管理は非常に困難な場合があります。これは、環境が作成されると、環境を作成するユーザーが自動的に唯一の管理者になるためです。たとえば、すべての環境の承認とチェックを一元的に管理する場合は、すべての環境管理者に特定のユーザーまたはグループを管理者として追加するよう依頼し、REST API を使用してチェックを構成する必要がありました。このアプローチは面倒でエラーが発生しやすく、新しい環境が追加されたときにスケーリングされることはありません。

このリリースでは、環境ハブレベルで Administrator ロールを追加しました。これにより、環境はサービス接続またはエージェントプールと同等になります。管理者ロールをユーザーまたはグループに割り当てるには、既に環境ハブ管理者またはプロジェクトコレクション所有者である必要があります。

管理者ロールのスクリーンショット。

この管理者ロールを持つユーザーは、アクセス許可の管理、管理、表示、および任意の環境の使用を行うことができます。これには、すべてのパイプラインへの環境の開放が含まれます。

環境ハブレベルでユーザー管理者ロールを付与すると、ユーザーは既存のすべての環境と将来の環境の管理者になります。

YAML 検証の改善

YAML 構文が正しいことを確認するには、Azure Pipelines Web エディターの Validate 機能を使用します。したがって、この機能は可能な限り多くの YAML の問題をキャッチすることが重要です。

YAML 検証のスクリーンショット。

式に関しては、YAML 検証がより徹底的になりました。

YAML パイプラインを記述するときは、 functions を使用して変数値を定義できます。

次の変数を定義するとします。

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

Patch変数は、counter関数と他の 2 つの変数を使用して定義されます。上記の YAML コードでは、 format という単語はミススペルです。以前は、このエラーは検出されません。これで、 Validate 機能はこれを検出し、エラーメッセージを表示します。

正しくない変数定義が検出されたスクリーンショット。

Azure Pipelines は、パイプライン/ステージ/ジョブレベルで不適切な変数定義を検出します。

YAML パイプラインでは、 conditions を使用してステージの実行をスキップできます。次の例のように、入力ミスもここに表示されます。

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

NuGetCommand タスクは、Patch変数の値が 0 の場合にのみ実行されます。ここでも、条件に入力ミスがあり、 Validate 機能によって表示されます。

Patch 変数のスクリーンショット。

Azure Pipelines は、パイプライン/ステージ/ジョブレベルで定義された不適切な YAML 条件を検出します。

環境用の REST API

Environment は、パイプラインからのデプロイでターゲットにできるリソースのコレクションです。環境には、展開履歴、作業項目とコミットの追跡可能性、アクセス制御メカニズムが用意されています。

プログラム的に環境を作成することがわかっているので、REST API のドキュメントを公開しました。

承認 REST API の機能強化

ユーザーが属しているグループを検索結果に含めることで、ユーザーに割り当てられた承認の検索が改善されました。

承認には、所属するパイプライン実行に関する情報が含まれるようになりました。

たとえば、次の GET REST API 呼び出し https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending 返されます。

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

パイプラインログにリソース使用率が含まれるようになりました

Azure パイプラインログで、メモリ、CPU 使用率、使用可能なディスク領域などのリソース使用状況メトリックをキャプチャできるようになりました。ログには、パイプラインエージェントと、ジョブで実行されるタスクを含む子プロセスによって使用されるリソースも含まれます。

パイプラインで使用されるリソースを含むログのスクリーンショット。

パイプラインジョブがリソースの制約に陥る可能性があると思われる場合は、 verbose ログを有効にしてリソース使用率情報をパイプラインログに挿入します。これは、ホスティングモデルとは関係なく、任意のエージェントで機能します。

Azure Pipelines エージェントで Alpine Linux がサポートされるようになりました

パイプラインエージェント v3.227 では、 Alpine Linux バージョン 3.13 以降がサポートされるようになりました。 Alpine Linux は、コンテナー (ベース) イメージに人気があります。エージェントは releases ページで確認できます。 Alpine Linux バージョンのエージェントには、vsts-agent-linux-musl-x64-3.227.1.tar.gzなどのプレフィックスvsts-agent-linux-muslがあります。

Azure Pipelines タスクで Node 16 を使用する

パイプライン内のタスクはランナーを使用して実行され、ほとんどの場合Node.js使用されます。ノードをランナーとして使用する Azure Pipelines タスクでは、すべて Node 16 が使用されるようになりました。 Node 16 は Apple シリコンをネイティブにサポートする最初の Node バージョンであるため、Apple シリコンでの macOS の完全なタスクサポートも完了します。 Apple シリコンで実行されているエージェントは、Rosetta を実行する必要はありません。

ノード 16 の有効期間の終了日が進んだのでノード 20 でタスクを実行する作業を開始しました。

Azure Resource Manager (ARM) テンプレートの最大サイズ 4 MB に合わせて Azure Pipeline の制限を引き上げた。

Azure Resource Manager テンプレートのデプロイタスクを使用して、Azure インフラストラクチャを作成できます。お客様からのフィードバックに応えて、Azure Pipelines の統合制限は 2 MB から 4 MB に引き上げされました。これは、大きなテンプレートの統合中にサイズの制約を解決 ARM テンプレート最大サイズ 4 MB に合わせて調整されます。

AzureRmWebAppDeployment タスクでは、Microsoft Entra ID 認証がサポートされます

AzureRmWebAppDeploymentV3 と AzureRmWebAppDeployment@4 タスクが更新され、基本認証が無効になっている App Service がサポートされました。 App Service で基本認証が無効になっている場合、AzureRmWebAppDeploymentV3/4 タスクは Microsoft Entra ID 認証を使用して App Service Kudu エンドポイントへのデプロイを実行します。これには、最新バージョンのmsdeploy.exeがエージェントにインストールされている必要があります。windows-2022/windows-latest Hosted エージェントの場合 ( task リファレンスを参照)。

ビルドが失敗したときにコードカバレッジポリシーの状態が [失敗] に無効にされたオーバーライド

以前は、PR のビルドが失敗した場合、コードカバレッジポリシーの状態は "Failed" にオーバーライドされていました。これは、ビルドをオプションのチェックとして使用し、PR の必要なチェックとしてコードカバレッジポリシーを使用した場合、PR がブロックされる一部のユーザーにとって阻害要因でした。

これで、ビルドが失敗した場合、コードカバレッジポリシーは "Failed" にオーバーライドされません。この機能は、すべての顧客に対して有効になります。

Artifacts

Cargo Crates に対する Azure Artifacts サポートの概要

Azure Artifacts が Cargo クレートのネイティブサポートを提供するようになったことをお知らせします。このサポートには、アップストリームソースとして利用できる crates.io に加えて、既存のプロトコルに関する機能パリティが含まれます。 Rust 開発者とチームは、Azure の堅牢なインフラストラクチャを使用し、使い慣れた Azure DevOps 環境を維持しながら、Cargo クレートをシームレスに使用、発行、管理、共有できるようになりました。

NuGet Restore v1 および NuGet Installer v0 パイプラインタスクの非推奨のお知らせ

NuGet Restore v1 および NuGet Installer v0 パイプラインタスクを使用している場合は、すぐに NuGetCommand@2 パイプラインタスクに移行します。移行を行わない場合、まもなくパイプラインにアラートが届くようになります。これに対するアクションがなければ、2023 年 11 月 27 日以降はビルドできなくなります。

npm 監査に対する Azure Artifacts のサポート

Azure Artifacts では、 npm audit コマンドと npm audit fix コマンドがサポートされるようになりました。この機能を使用すると、ユーザーは安全でないパッケージバージョンを自動的に更新することで、プロジェクトの脆弱性を分析して修正できます。詳細については、 npm 監査を使用してパッケージの脆弱性を検出して修正します。

レポート

新しいダッシュボードディレクトリエクスペリエンス

お客様のフィードバックに耳を傾け、新しいダッシュボードディレクトリエクスペリエンスを導入することに興奮しています。最新の UI デザインだけでなく、 Last Configured 列を追加して、各列で並べ替えることもできます。この列を使用すると、プロジェクトコレクション内のダッシュボードの全体的な使用状況に関するより良い分析情報が得られます。さらに、チームレベルまたはプロジェクトレベルのダッシュボードでフィルター処理できるようになり、表示しないダッシュボードを非表示にしながら、表示する必要のある情報の一覧にのみアクセスできるようになりました。

Gif を使用して新しいダッシュボードディレクトリをデモします。

今すぐお試しください。 Azure DevOps コミュニティで何を思うかをお知らせください

作業項目のフィルター処理

作業項目グラフのフィルター処理 お知らせします。 この機能を使用すると、作業項目グラフの上にマウスポインターを合わせて簡単な概要を確認し、特定のグラフセグメントにドリルダウンして詳細な分析情報を得ることができます。必要なデータの正確な部分にアクセスするためにカスタムクエリを作成する必要がなくなりました。作業項目グラフの作業項目を数回クリックするだけで調べることができるようになりました。

Gif を使用して作業項目のフィルター処理をデモします。

この機能の将来を形成する上で、フィードバックは非常に貴重です。今すぐお試しください。 Azure DevOps コミュニティで何を考え。

フォルダーのコードカバレッジの結果

コードカバレッジの結果は、最上位の数値としてだけでなく、個々のファイルとフォルダーごとに使用できるようになりました。 Folder ビューモード ボタンが切り替えると、コードカバレッジビューが表示されます。このモードでは、ドリルダウンして、選択したサブツリーのコードカバレッジを確認できます。切り替えボタンを使用して、新しいビューと古いビューを切り替えます。

Test Plans

テスト計画またはスイート ID を使用したクイックコピーとインポート

Azure Test Plans で複数のテストプランを簡単に処理できるようになりました。テストケースをインポート、コピー、または複製するための長いドロップダウンメニュー (特に広範なプランやスイートの場合) で以前に直面していた課題を認識し、ワークフローを合理化するための手順を実行しました。

テスト計画とスイート ID 検索機能をお知らせします。テストケースの迅速なインポートまたはコピーを遅延なく行う場合は、テスト計画またはスイート ID を入力します。この更新プログラムは、テスト管理エクスペリエンスを向上させるための継続的な取り組みの一環であり、より直感的で時間のかかる作業を減らします。

テスト計画、スイート ID 検索の詳細をデモする Gif。

Azure Test Runner の更新

Azure Test Runner が新しいバージョンに更新されたことを共有することに興奮しています。この更新プログラムにより、安定性とパフォーマンスが向上し、中断や遅延なしでテストを実行できます。以前のバージョンの Azure Test Runner はサポートされなくなりました。テスト操作のパフォーマンスと信頼性を最大限に高めるために、できるだけ早く最新バージョンに更新することをお勧めします。

新機能

安定性とパフォーマンスの向上: テストランナーが大幅に改善され、一部のユーザーが経験した問題に対処しました。このアップグレードにより、より信頼性の高いテストプロセスが保証され、作業の中断が最小限に抑えられます。
アップグレードプロンプト: 新しいバージョンへの移行をシームレスにするには、アップグレードを求めるメッセージが表示されます。これにより、すべてのユーザーが便利に改善されたバージョンに簡単に移行でき、互換性とパフォーマンスが向上します。

アップグレードプロンプトのスクリーンショット。

フィードバック

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

ページの先頭へ

次の方法で共有

Azure DevOps Server 2022 Update 2 リリース ノート