Azure DevOps Server リリース ノート (26H2)

| Developer Community | システム要件と互換性 | ライセンス条項 | DevOps Blog | SHA-256 Hashes |

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

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

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

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

Azure DevOps Server RC (26H2) リリース日: 2026 年 10 月 27 日

General

高レベルの特権スコープ、パイプラインデコレーター、未公開の拡張機能を管理する

Azure DevOps 拡張機能では製品の機能とワークフローが向上しますが、特権スコープが高い場合は、さまざまなリスクが発生する可能性があります。 各コレクションの管理ページと Visual Studio Marketplace のインストール ページでこれらのスコープをフラグ付けする新しい機能が追加され、管理者が十分な情報に基づいて意思決定を行うのに役立ちます。 発行されていない拡張機能とパイプライン デコレーターにも、管理者の認識と適切なアクションのフラグが設定されます。

高い特権スコープを管理する

詳細については、パブリック ドキュメント のページを参照してください。

Boards

Azure Boardsの UI が更新され、ユーザー インターフェイスの高速化、製品の他の部分との一貫性、アクセシビリティの向上が実現しました。 機能は変わりませんが、次のことが期待できます。 • モダン デザイン • レスポンシブ リフロー • パフォーマンスの向上 • アクセシビリティ コンプライアンス

かんばんボードでの列位置への移動

かんばんボードは、チームの作業フローを視覚化するのに役立ちます。 かんばんボードの各列は作業ステージを表します。 各カードは、作業のその段階でのバックログ項目、ユーザー ストーリー、またはバグを表します。 かんばんボードの列内の作業項目を、[ Move to position ]（位置移動）を使用して並べ替えることができます。 これにより、多数の作業項目を含む列の作業項目の順序を変更しやすくなります。 作業項目を移動するには、アクション アイコン (***) をクリックし、[位置へ移動] を選択します。

かんばんボードの列の位置へ移動

カンバンカードで子どもに割り当てられた

かんばんボード カードのすべての子項目に [割り当て済み ]アバターが追加されました。 これにより、どの項目が割り当てられているのか、また誰に割り当てられているのかを簡単に理解できるようになりました。 コンテキスト メニューを使用して、作業項目をすばやく割り当てることもできます。

カンバンカードの子にある Assigned To のデモ GIF

作業項目の履歴をフィルター処理する

作業項目は、コラボレーションを念頭に置いて設計されています。 また、完全な追跡可能性のために、すべての変更を追跡します。 これにより、長いリビジョン履歴が作成され、特定のフィールドにいつ変更が発生するかを理解するのが困難になることがあります。 このスプリントでは、作業項目履歴タブにフィルター オプションを追加しました。これにより、特定のユーザーが個々のフィールドに加えた変更をすばやく見つけることができます。

作業項目の履歴のフィルターのデモ用 GIF

開発者コミュニティからの上位の提案のいずれかに基づいて、この機能を優先しました。

列に移動し、スイムレーンに移動する

アクセシビリティの向上の一環として、かんばんボードのカード アクション に [列に移動 ] オプションと [ レーンに移動 ] オプションが追加されました。 これらのアクションによって、アクセシビリティのニーズを持つユーザーは、かんばんボード上のカードを簡単に移動できるようになります。

GIF からデモへ、列に移動してスイムレーンに移動する

フィルターを使用して階層を維持するオプション

バックログでフィルター処理すると、階層が結果にフラット化され、長い項目の一覧が 1 つだけ表示されます。 これは、階層をフィルター処理して引き続き表示したいユーザーにとって、痛みを伴うエクスペリエンスです。 このスプリントでは、バックログでフィルター処理するときに階層を維持するための新しいオプションがリリースされます。 フィルターが適用されると、階層の一番下から開始し、戻って作業します。 一致する場合は、作業項目が強調表示 (太字) され、上の親チェーンが表示されます。

フィルターを使用して階層を維持するための GIF をデモに変換するオプション

作業項目の添付ファイルの URL をコピーする

作業項目の添付ファイルの URL をコピーして、説明とディスカッションで切り取って貼り付けることができるようにする機能が追加されました。 リンクをクリックすると、添付ファイルがダウンロードされます。

作業項目の添付ファイルURLをコピーするデモ用GIFのオプション

以前は、作業項目リンクを変更するには、少なくとも 3 つの手順が必要です。 たとえば、関連リンクへの親リンクを変更するには、作業項目 ID をコピーし、親リンクを削除し、関連する種類の新しい既存のリンクを追加して、最後にコピーした ID を貼り付けて保存する必要があります。 面倒なプロセスです。

リンクの種類を直接編集および変更できるようにすることで、問題を解決しました。 リンクの種類は、1 つの手順で簡単に変更できます。

作業項目リンクの種類を編集するオプションのデモ GIF

[リンクのコピー] アクションを使用して、特定の作業項目コメントへのリンクをコピーできるようになりました。 その後、そのリンクを別の作業項目のコメントまたは説明に貼り付けることができます。 クリックすると、作業項目が開き、コメントが強調表示されます。

この機能は、 このコミュニティ提案チケットに基づいて優先されました。

スイムレーンの色

かんばんボードでは、スイムレーンを使用して、さまざまなサービス レベル クラスをサポートする作業の状態を視覚化できます。 これで、スイムレーンに色を追加して、ボードで識別しやすくすることができます。

スイムレーンに色を追加するオプションのデモ GIF

Sticky Save と保存して閉じるボタン

作業項目の保存ボタンに小さな使いやすさ機能を追加しました。 保存 と 保存して閉じる のどちらのボタンを選択したかは、次回、作業項目を保存するときにも前回の選択が保持されるようになりました。 これにより、[保存] よりも [保存して閉じる] を選択する場合に、追加でクリックしなくて済みます。

固定の [保存] ボタンと [保存して閉じる] ボタンに関する画像

スイムレーンルール

スイムレーン ルールはスタイル ルールに似ていますが、代わりにかんばんボードに条件を設定して、作業項目を特定のレーンに自動的に移動することができます。

スイムレーンルールを表示するGIF

Azure Boards の複数の領域から作業項目の URL をコピーするように少し改善しました。 特定の作業項目への直接リンクを簡単に取得できるようにします。

作業項目へのリンクのコピーに関する画像

チームオートメーションルール

各バックログ レベルを構成して、子の状態に基づいて作業項目のオープンと終了/解決を自動化できるようになりました。 解決しようとしている主なシナリオは 2 つあります。

  1. 1 つの子項目がアクティブ化されたら、親をアクティブ化します。
  2. すべての子項目が閉じられたら、親を閉じます（または解決済みにします）。

これらの設定を有効にするには、チームのバックログ レベルの構成をクリックしてください。 次に、[ Automation > Rules タブに移動して、バックログに適用できる 2 つの異なるルールを確認します。 各バックログ レベル (要件、機能、エピック) は、チームの作業方法に合わせて構成できます。

チーム自動化ルールに関する画像

たとえば、子タスクのいずれかがアクティブに設定されたとき、親ユーザー ストーリーをアクティブにします。 次に、すべてのタスクが完了したら、[ユーザー ストーリー] を [終了] に設定します。

チーム自動化ルールの Gif to demo オプション

コメントと大きなテキスト フィールドに対する Markdown のサポート

作業項目のコメントやその他の大きなテキスト フィールドを作成および編集するときに、Markdown または HTML を使用できるようになりました。 最後に作成したコメントに使用されたエディターは記憶され、今後のコメントの既定値になります。 既存の HTML コメントは Markdown に変換できますが、Markdown でコメントが作成または更新されると、HTML に元に戻して変換することはできなくなります。

作業項目のマークダウン フィールドでは、対話型チェックリストもサポートされます。 pull request の説明と同様に、フィールドを離れることなく、項目をすばやくオンまたはオフにします。 この機能は、Markdown が有効になっている大きなテキスト フィールドまたはコメントで自動的に使用できます。

コメントと大きなテキスト フィールド向け Markdown サポートのデモ用 GIF オプション

添付ファイルを完全に削除する

場合によっては、作業項目から添付ファイルを削除するだけでは、特にファイルに悪意のあるフラグが設定されている場合に、セキュリティ リスクが完全に解決されない場合があります。 添付ファイルへの共有リンクは、他の作業項目、コメント、または外部チャネル間で引き続きアクセスできる場合があります。 これに対処するために、"作業項目を完全に削除する" アクセス許可を持つユーザーが添付ファイルを完全に削除できるようにする機能が追加されました。

添付ファイル削除用の画像

接続されている GitHub リポジトリの上限の引き上げ

GitHub リポジトリを Azure DevOps プロジェクトにリンクする際の接続ごとの制限を増やしました。 Web エクスペリエンスの新しい上限は 2,000 になり、 Update REST API で既に使用可能な制限に一致します。

継承されたプロセスの制限の増加

複雑なプロセスカスタマイズのニーズを持つ組織をより適切にサポートするために、継承されたプロセスの制限を 2 倍にしました。 組織は、以前の制限である 128 個から最大 256 個の継承されたプロセスを作成できるようになりました。

配送計画の制限の引き上げ

プロジェクトあたりの最大配信プラン数を 1,500 に増やしました。 配信プランの追加と編集の詳細については、こちらのドキュメントを参照 してください。

複製作業項目の非推奨化

製品から作業項目の複製機能が削除されました。 作業項目のコピーを引き続き使用できます。これにより、保存する前に作業項目を編集することもできます。

GitHub統合の機能強化

状態遷移のサポート

GitHub pull requests を Azure Boards の作業項目にリンクするためのサポートが拡張されました。 以前は、修正 AB#{ID} キーワードのみがサポートされていました。 この更新プログラムでは、{State or Category} AB#{ID} を使用して、マージ時に作業項目を目的の状態に自動的に移行できるようになりました。

GitHub pull request の説明に状態名 (例: AB#1234 の検証) が含まれている場合、リンクされた作業項目の状態が結果として更新されます。 状態名が認識されない場合は、状態カテゴリ (解決済みなど) と一致するかどうかを確認します。 その場合、作業項目はそのカテゴリ内で最初に使用可能な状態に遷移します。

状態遷移のサポート

一致する状態またはカテゴリが見つからない場合、キーワードは無視され、作業項目の状態は更新されません。

最後に、「修正番号 AB#{ID}」キーワードは引き続き期待どおりに動作し、既定で「Closed」の状態値に設定されます。

AB# リンクは、GitHub pull request の開発セクションに直接表示されるようになりました。これにより、説明やコメントを検索することなく、リンクされた作業項目に簡単にアクセスできるようになりました。

GitHub PR の AB# リンク

これらのリンクは、AB# が pull request の説明に含まれている場合にのみ表示されます。 作業項目から直接リンクした場合、[開発] セクションには表示されません。 さらに、説明から AB# リンクを削除すると、開発コントロールから削除されます。

コミット、ブランチ、プル リクエストへのリンクの機能強化

使いやすさのギャップを埋め、Azure Repos で使い慣れたエクスペリエンスに合わせて Boards + GitHub の統合を継続的に改善しています。

この更新プログラムでは、ブランチ、プル要求、コミットを作業項目にリンクする方法を効率化するためのいくつかの機能強化が導入されました。

  • GitHub ブランチが作業項目にリンクされると、関連付けられているすべてのプル要求が自動的にリンクされるようになります。 AB# を手動で使用する必要はありません。
  • プル要求がマージされると、マージ コミットは作業項目に自動的にリンクされます。
  • プル要求がマージされた後にブランチが削除された場合、ブランチ リンクは作業項目から自動的に削除されます。
  • プル リクエストが完了すると、マージ コミットを対応する作業項目に自動的にリンクします。

これらの改善により、開発の進捗状況を追跡し、作業項目の関連付けをクリーンかつ最新の状態に維持する作業が容易になります。

コミット、ブランチ、プルリクエストへのリンク改善を示すGIF

Pull Request Mentions

これで、!を使用できるようになりました。 任意の大きなテキストフィールドやコメントから GitHub のプルリクエストを直接参照して議論するメンション

GIF からデモへのプルリクエストメンション

YAML パイプラインのビルド状態を表示する

YAML とクラシック パイプラインの間の機能パリティの実現に取り組んでいます。 重要な欠落機能の1つは、リポジトリが GitHub にホストされている場合に、「ビルド統合」リンクを提供できる機能でした。 最新のリリースでは、YAML パイプラインの設定に次のことを確認するためのオプションを追加することで、このギャップに対処しました。

ビルドの状態を表示する

ビルドが完了すると、関連する作業項目に対応するリンクが自動的に表示され、全体的な追跡可能性のストーリーが向上します。

ビルドに組み込まれた画像

接続されている GitHub リポジトリの制限を増やす

上限を 500 から 2,000 個のリポジトリに引き上げ、より多くのプロジェクトを管理できるようになります。

Repos

Git ポリシー構成 API の強化

ポリシー構成 API が改善され、特定のリポジトリに適用されるすべてのポリシーを簡単かつ効率的に取得できるようになります。 リポジトリ レベルで定義されたポリシーと、そのリポジトリ内の任意のブランチまたは ReFS に適用されるポリシーをクエリできるようになりました。プロジェクト全体をスキャンする必要はありません。 この機能強化により、不要な API 呼び出しが減り、ポリシーを大規模に管理するサービスのパフォーマンスが向上します。 既存のポリシー動作は変更されません。

ポリシー構成 - Get - REST API (Azure DevOps Git)

破壊的変更: 古い TFVC チェックイン ポリシーの無効化

2025 年 4 月に、TFVC チェックイン ポリシーの格納方法の 変更を発表しました 。 これらの変更は、ビルド (最後のビルドを成功させる必要があります)、作業項目 (関連付けられている作業項目が必要)、変更セット コメント (ユーザーがチェックインにコメントを追加する必要がある) などのチェックイン ポリシーを使用するすべての TFVC プロジェクトに影響します。

この 1 年間で、既存の古いチェックイン ポリシーを新しいストレージ形式に移行するためのガイダンスを提供し、新しい古いポリシーの作成を無効にしました。

このリリースでは、古い形式をまだ使用している残りのチェックイン ポリシーはすべて無効になります。 これらのポリシーは機能しなくなり、チェックイン ポリシーを引き続き動作させるために新しい形式に移行する必要があります。

完全な詳細とステップ バイ ステップの移行ガイダンスについては、 ブログ記事を参照してください。

プルリクエスト通知の機能強化

チームが最も関連性の高い pull request アクティビティに集中できるように、Azure DevOps の電子メール通知を改善し、ノイズを減らし、意味のある変更を強調しました。 ドラフト切り替えや自動更新など、いくつかの低価値の通知が完全に削除されました。 残りの通知については、影響を受けるファイルなどの変更を強調するためにコンテンツを簡略化し、完全なレビュー担当者やコミット リストなどの冗長な詳細を削除しました。 これらの更新プログラムは、pull request メールのスキャンを容易にし、より実用的に、チームが共同作業を行う方法に合わせて設計されています。

マルチレベルブランチ用のプルリクエストテンプレート

プル要求テンプレートで、 複数レベルのブランチに対応する入れ子になったフォルダー構造がサポートされるようになりました。 feature/foo/december というブランチに対して PR を開くと、テンプレートは優先順に次の場所で検索されます。

  1. <pull request template path>/branches/feature/foo/december.md
  2. <pull request template path>/branches/feature/foo.md
  3. <pull request template path>/branches/feature.md

最も具体的なテンプレートが PR に適用されます。この場合、feature/foo/december.md が存在すれば、そのテンプレートが PR に適用されます。 そうでない場合は feature/foo.md が適用され、存在しない場合は feature.md が使用されます。

古い TFVC ポリシーの保存操作を無効にする

DevOps ブログで公開されているプランで既に説明したように、段階的な廃止の一環として、古い TFVC ポリシーの作成と変更を無効にしています。 既存の古いポリシーは、現在の状態で使用および表示できます。 このプロセスの次のフェーズが開始される前に、新しいポリシーの種類に移行することをお勧めします。

ご質問やフィードバックについては、 開発者コミュニティからお問い合わせください。

pull request エクスペリエンス内でのコメント ナビゲーションの動作が改善されました。 直接リンクを介して特定のコメントにアクセスする場合、システムは多数のコメントを含む pull request のフォーカスをより適切に処理するようになりました。

プル要求ブランチのドロップダウンでターゲット ブランチを使用できるようになりました

Pull Request Targets を使用しているお客様は、[ブランチ] ドロップダウンの新しい [ターゲット] セクションでターゲット ブランチが強調表示され、[Mine] セクションと [All] セクションの間に表示されるようになります。

プル リクエストでターゲット ブランチが利用可能になりました

ターゲット ブランチの使用を開始する方法については、 プル要求のターゲット ブランチの構成 に関するドキュメントを参照してください。

pull request スレッドとディスカッションのナビゲーションが改善されました

プル リクエストのディスカッションやスレッド内や間を移動できる新しいキーボード ショートカットが導入されました。

  • 前のディスカッションに移動する - Ctrl + alt + w
  • 次の会話に移動する - ctrl+alt+s
  • 選択したスレッドを折りたたむ - Ctrl + alt + c
  • 選択したスレッドを展開する - Ctrl + Alt + e

Azure DevOps で使用可能なキーボード ショートカットの詳細については、Azure DevOps の公式ドキュメント「Web ポータルとチーム エクスプローラーのキーボード ショートカット」を参照してください。

pull request エクスペリエンスに対するスクリーン リーダーのサポートの強化

pull request エクスペリエンスでのスクリーン リーダーのサポートが改善されました。 組み込みのコード エディターの新しいオプションを使用すると、行の変更とコメントに関するお知らせを有効にすることができます。

新しいオプションを有効にするには、pull request ページで [ ファイル ] タブをクリックします。

プル リクエストでファイルを表示する画像

次に、エディターの環境設定 ボタンをクリックします。

エディタの環境設定を示す画像

ポップアップ メニューで、[行の変更とコメントのお知らせを有効にしてスクリーン リーダーのアクセシビリティを強化する] オプションを選択し、[保存] をクリックします。

行の変更に関するお知らせを有効にする方法を示す画像

VSCode での Azure DevOps リモート インデックスのサポート

Azure DevOps では、Azure DevOps リポジトリにリンクされている IDE ワークスペースのリモート インデックスがサポートされるようになりました。 これにより、#codebase は初期化なしで関連するスニペットをほぼ瞬時に検索できます。 これは、数万個のインデックス可能なファイルを持つ大規模なリポジトリでも機能します。 リモート ワークスペースのサポートは、Visual Studio と VS Code に対する 7 月の更新プログラムからリリースされました。 詳細については、 VS Code リリース ノートを参照してください。

リモート インデックスは、Git を介して Azure DevOps にリンクされているワークスペースで作業するときに自動的に使用されます。 Azure DevOps リポジトリへのアクセスに使用する Microsoft アカウントを使用して、Visual Studio または VS Code にもログインしていることを確認します。

pull request コメントから作業項目を作成する

pull request のコメントから直接作業項目を作成できるようになりました。 PR を開き、コメントを追加し、新しい [作業項目の作成] ボタンをクリックするだけです。 次に、ドロップダウン メニューから目的の作業項目の種類を選択します。

PR コメントの作業項目を作成する方法を示す画像

Wiki ページとファイル プレビューでの強化された図のサポート

さまざまな人魚図の種類と視覚化のサポートが拡大され、ドキュメントとプロジェクト計画機能が強化されました。 このスプリントを含めた新しくサポートされるダイアグラムの種類は、エンティティリレーションシップとタイムラインダイアグラムです。

Mermaidサポートの詳細については、Mermaidダイアグラムに関するドキュメントを参照してください。

Kusto クエリ言語のためのシンタックスハイライトサポート

Azure DevOps では、ファイル ビューと編集エクスペリエンスでの Kusto クエリ言語の構文の強調表示がサポートされるようになりました。 この機能強化は、.csl、.kql、.kusto 拡張子を持つファイルに適用され、プラットフォーム内で直接 KQL スクリプトを読み取って編集しやすくなります。

Kusto クエリの構文強調表示のサポートを示す画像

PR での Jupyter Notebook の相違のサポート

お客様からのフィードバックに応じて、Jupyter Notebook 拡張機能の PR で .ipynb ファイルを差分するサポートが追加されました。 生の JSON を解析する代わりに、コードセルと Markdown セルの変更を強調表示するサイドバイサイドノートブックビューが表示されます。 出力とメタデータは折りたたみ可能なセクションに表示され、これらのセクションの変更は太字でマークされます。

pull request での side-by-side Jupyter Notebook diff

TFVC チェックイン ポリシーの変更

Microsoft.TeamFoundationServer.ExtendedClient NuGet パッケージの新しいバージョン (19.255.0-preview)

NuGet Microsoft.TeamFoundationServer.ExtendedClient パッケージが新しい TFVC ポリシー クラスとメソッドで更新されました。

ポリシーの変更

TFVC チェックイン ポリシーを Azure DevOps に格納する方法を変更しています。これは、NuGet Microsoft.TeamFoundationServer.ExtendedClient がサービスと通信する方法の更新も意味します。

TFVC プロジェクトでチェックイン ポリシーを使用している場合は、それらのポリシーを新しい形式に移行します。 これを行うには、次の 2 つの方法があります。

  1. Visual Studio の使用。

Warning

アクションの危険な特定の結果。次に進む前に、Visual Studioを最新バージョンに更新してください (VS 2022、 最小バージョン 17.14 Preview 3、17.13.6、17.12.7、17.10.13、17.8.20、16.11.46、15.9.72 の VS 2019 および VS 2017 は、新しいポリシーをサポートしています)。

Visual Studio プロジェクト管理者を使用して新しいポリシーを作成するには 、Settings -> Team Project -> Source Control -> Check-in Policy を開き、古いポリシーと同じパラメーターを持つ新しいポリシー ("廃止" マークなし) を追加する必要があります。

  1. Microsoft.TeamFoundationServer.ExtendedClient のカスタム実装を使用してサーバーと通信する場合は、 移行ガイドに従ってください。

TFVC チェックインと将来の Azure DevOps バージョンとの互換性を維持するには、移行が必要です。 当面は、古い (古い) ポリシーと新しいポリシーの両方が有効であり、機能したままです。 今後の計画については、 ブログ記事を参照してください。

GetRepository API の機能強化

リポジトリの応答に creationDate プロパティが追加されました。リポジトリの作成日を返すリポジトリ API を取得します。 このプロパティは、API バージョン 7.2-preview 以降で使用できます。

Pull Requests Query API の機能強化

Pull Request Query - Get API の応答に新しい Label プロパティが導入されました。 すべてのクエリに関連するプル要求のラベル (タグ) を含めるかどうかを指定できるようになりました。 新しい Include プロパティを使用できます。ラベルに設定されている場合、応答には指定された PR のラベルが含まれます。 null のままにすると、ラベルは含まれません。 意図しないエラーを防ぐには、NotSet が明示的に割り当てられていないことを確認します。これにより、無効な要求が発生します。

Note

ラベル エンリッチメント リソースの使用率は、割り当てられたラベルの数とその長さによって異なります。 ラベルを要求すると、スロットルに影響し、ネットワーク負荷が増加する可能性があります。 パフォーマンスを最適化するために、不要なラベル要求を回避することをお勧めします。

要求ペイロードの例：

{
"queries": [
{
"type": "lastMergeCommit",
"include": "Labels",
"items": [
"0d6c9b2b524113113fced41aecbf8631a4649dec"
]
},
{
"type": "lastMergeCommit",
"items": [
"b524113113f0dd41aecbf8631a4649dec6c9b2ce"
]
}
]
}

Pipelines

サービス接続の機能強化

サービス接続の管理ページが強化され、接続の可視性が向上しました。 接続の種類や認証方法など、追加の詳細を表示できるようになりました。

また、これらのフィールドのフィルター処理のサポートも追加され、サービス接続の目的をすばやく見つけて整理し、理解しやすくなります。

サービス接続の詳細とフィルター処理のオプション

Note

追加のサービス接続の詳細は、新しく作成されたサービス接続でのみ使用できます。

YAML パイプラインでの継続的デプロイの可視性の向上

以前は、継続的デプロイ (CD) シナリオに YAML ベースの Azure Pipelines を使用しているときに、ギブ実行でデプロイされた成果物を特定することは困難でした。 このスプリントでは、パイプライン実行全体におけるアーティファクトの可視性が向上しました。

パイプラインの実行の概要ページで、各実行で使用されている成果物を確認できるようになり、デプロイされた内容を一目で理解しやすくなります。

デプロイされた成果物を示すパイプライン実行の概要

個々の実行を表示すると、Azure Pipelines は実行の詳細ページの上部にその実行で使用される成果物を表示するようになりました。

デプロイされた成果物を示すパイプライン実行の詳細

この機能は、パイプライン リソースとして定義されたパイプライン成果物で動作します。 複数の成果物が定義されている場合、Azure Pipelines には最初の成果物が一覧表示されます。

ステージのデプロイ履歴

同じサービスを複数のインスタンスにデプロイする場合、各インスタンスに現在デプロイされているシステムのバージョンを理解するのが難しい場合があります。

このスプリントでは、パイプライン レベルで明確なデプロイの可視性を提供する新しい ステージ エクスペリエンスを Azure Pipelines に導入します。 [ステージ] ビューには、現在デプロイされている最新のパイプライン実行、またはパイプライン内の各ステージへのデプロイプロセスが表示されます。

たとえば、複数のデプロイ ステージがリージョン別にグループ化された次の YAML パイプラインを考えてみましょう。

stages:
- stage: deploy_WUS
 group: US Deployment
 displayName: Deploy to WUS
 jobs:
 - job:
 steps:
 - script: ./deploy.sh WUS
- stage: deploy_CUS
 group: US Deployment
 displayName: Deploy to CUS
 jobs:
 - job:
 steps:
 - script: ./deploy.sh CUS
- stage: deploy_WEU
 group: EU Deployment
 displayName: Deploy to WEU
 jobs:
 - job:
 steps:
 - script: ./deploy.sh WEU
- stage: deploy_CEU
 group: EU Deployment
 displayName: Deploy to CEU
 jobs:
 - job:
 steps:
 - script: ./deploy.sh CEU

パイプラインを数回実行し、[ ステージ ] タブに移動すると、これが表示されます。

デプロイ リージョン別にグループ化されたパイプライン ステージ

WUS への展開という名前のステージに触れた最新の実行が、システム バージョン 20260316.1 を展開した #20260317であることがわかります。 ステージの場合、そのステージを実行するパイプラインの実行が成功したか進行中であることがわかります。

ステージ名 (たとえば、 WUS へのデプロイ) をクリックすると、ステージのログが表示されます。 #20260317 • ビルド バージョン 20260316.1 のデプロイをクリックすると、そのパイプラインが実行されます。

ステージの行をクリックすると、そのデプロイ履歴が表示されます。 履歴には、ステージを参照する完了した実行と進行中の実行が含まれています。

パイプライン ステージのデプロイ履歴

デプロイ パイプラインでは、リング構造など、さまざまなグループに数百のステージを編成できます。 ステージのグループを指定するためのサポートを追加しています。 前のスクリーンショットでは、 米国展開 と EU 展開の 2 つのグループを確認できます。

グループ ステージ プロパティは、複数のレベルの入れ子をサポートしています。 つまり、次の場合のように、EU Deployment\Italy という名前のグループを持つことができます。

- stage: deploy_IT
 group: EU Deployment\Italy
 displayName: Deploy to Italy
 jobs:
 - job:
 steps:
 - script: echo ./deploy.sh IT

このステージを実行すると、次のスクリーンショットのように [ステージ] ビューが更新されます。

入れ子になったデプロイ グループのパイプライン ステージ

ステージは、それらを参照する実行がある限り表示されます。

ステージが Stages タブに表示されるには、名前が必要です。つまり、- stage: deploy_WUS は表示されますが、- stage: の場合は表示されません。

パイプライン実行のデバッグの強化

このスプリントでは、パイプラインの実行をデバッグする機能が向上しています。

実行を取り消す必要がありますが、ジョブまたはステージは引き続き実行されるため、混乱します。 警告メッセージが追加され、これがいつ、なぜ発生したかをお知らせします。

次の YAML があるとします。

stages:
- stage: WUS1
 jobs:
 - job: DeployWUS1
 condition: eq(variables['Build.SourceBranchName'], 'main')
 steps:
 - task: CmdLine@2
 inputs:
 script: echo "Deploying $(System.StageName)"
 - task: CmdLine@2
 inputs:
 script: sleep 60
- stage: WUS2
 condition: eq(variables['Build.SourceBranchName'], 'main')
 jobs:
 - job: DeployWUS2
 steps:
 - task: CmdLine@2
 inputs:
 script: echo "Deploying $(System.StageName)"

ここで、ジョブ DeployWUS1 の実行時に実行を取り消すとします。 ジョブは引き続き実行され、WUS2 ステージも引き続き実行されます。 Azure Pipelines は、ジョブとステージが実行を継続する理由を通知します。

取り消されたジョブとステージの実行が続行される理由を説明する警告

もう 1 つの改善点は、ステージがスキップされる理由をユーザーに知らせる点です。

たとえば、別のブランチ (たとえば、release_123) から同じ YAML を実行し、ステージ WUS2 のみを実行することを選択したとします。 以前は、WUS1 ステージと WUS2 ステージの両方が同じ状態でスキップされていましたが、各ステージがスキップされた理由は明らかではありませんでした。 これで、キューの実行時にステージの選択を解除したため、または実行時の状態が原因でステージがスキップされたかどうかがわかります。

ステージがスキップされた理由を示すパイプライン実行

YAML CD デプロイのより明確な成果物の選択

CD シナリオでの YAML パイプラインのセキュリティとデプロイのエクスペリエンスが強化されました。 以前は、デプロイするパイプライン成果物の管理は面倒でエラーが発生しやすくなっていました。 どの実行がデフォルトでデプロイされるかが必ずしも明確ではなく、実行ブランチなど、異なるアーティファクトの選択はサポートされていませんでした。

更新されたデプロイ パネルでは、最初にパラメーターを構成し、デプロイするパイプライン成果物を決定する前にパラメーターが確実に適用されるようにします。 これにより、デプロイ エラーが減り、成果物の選択がより予測可能で安全になります。

パイプライン パラメーターの入力を求めるデプロイ パネル

[次へ: リソース] を選択すると、デプロイ パネルに、どのパイプライン成果物が選択されたかが明確に表示され、デプロイされる内容が正確に信頼されます。

選択したパイプライン アーティファクトを表示するデプロイ パネル

パイプライン成果物を変更する場合は、ブランチ セレクターを使用して検索を絞り込むことができます。

パイプライン成果物を選択するためのブランチ セレクター

パイプラインでパラメーターを定義するが、パイプライン成果物を使用しない場合、UI は混乱を避けるためにこれを明確に示します。

パイプライン成果物が見つからなかったことを示すデプロイ パネル

パイプラインでパラメーターが定義されていない場合、[パイプラインの実行] パネルは現在のエクスペリエンスと一貫性を保ちます。 パイプラインでパイプライン成果物が使用されている場合、次に示すように、更新されたパネルにそのフローが反映されます。

パイプライン成果物を使用してパイプラインを実行する

パイプラインでパイプライン成果物が使用されていない場合のエクスペリエンスの外観を次に示します。

パイプライン アーティファクトなしでパイプライン パネルを実行する

新しい実行パイプライン パネル

このスプリントでは、継続的デプロイ (CD) シナリオに YAML パイプラインを使用する際のセキュリティとエクスペリエンスが向上しました。 以前は、デプロイするパイプライン成果物の管理は面倒でエラーが発生しやすくなっていました。 どの実行をデフォルトでデプロイするかが不明確でした。 成果物を変更する場合は、実行ブランチで選択できませんでした。

  • 新しいパネルでは、パラメータを入力できます。これは、どのパイプラインアーティファクトをデプロイするかが決定される可能性があるためです。

パラメーターを入力するための新しい実行パイプライン パネル

  • [次へ:リソース] をクリックすると、選択されたパイプライン成果物が表示されます。 これにより、デプロイする内容が確実に確認できます。

選択したアーティファクトを示す新しい実行パイプライン パネル

  • パイプライン成果物を変更する場合は、 ブランチ セレクターを使用して検索を絞り込むことができます。

アーティファクト検索を絞り込むためのブランチセレクター

  • パイプラインでパラメーターが定義されているのにアーティファクトが使用されていない場合、UI はパイプライン成果物が見つからなかったことを通知します。

アーティファクトが見つからなかったことを示す実行パイプライン パネル

  • パイプラインでパラメーターが定義されていない場合、[パイプラインの 実行 ] パネルは、現在と同様の 1 つのステップです。

パイプラインがパイプライン成果物を使用する場合の外観は次のようになります。

パイプライン成果物を含む 1 ステップの実行パイプライン パネル

パイプラインでパイプライン成果物が使用されていない場合の外観は次のようになります。

パイプライン成果物を含まない 1 ステップの実行パイプライン パネル

承認タイムアウトを減らす

YAML パイプラインの実行が、サービス接続やエージェント プールなどの保護可能なリソースに初めてアクセスできるようにするには、承認が必要です。 承認プロセス中に実行が一時停止され、多くの実行が一時的に停止する可能性があります。 承認が付与されると、一時停止中のすべての実行が再開され、意図しない影響が生じることがあります。

再開される実行の数を制限するために、承認タイムアウトを 30 日から 7 日に減らしています。 既にブロックされ、承認を待機している実行は、この変更の影響を受けなくなります。 場合によっては、ブロックされた実行で、負のタイムアウトを含む UI の不規則性が表示されることがあります。

パイプライン パラメーター

デプロイ パイプラインの実行を検査またはデバッグするときは、実行の入力を理解することが不可欠です。 この情報は、パイプラインの動作を明確にし、実行の目的を説明するのに役立ちます。

このスプリントでは、新しい [パラメーター] パネルが追加されました。

パイプライン実行の [パラメーター] パネル

パネルの情報は次のように設定されます。

  • 次のパラメーターを使用してパイプラインの実行を開始するとします。

パイプラインの実行を開始するときに選択されたパラメーター

  • さらに、 defaultTimeout という名前の変数の値を 240 に変更し、最後のステージの選択を解除します。

パイプライン変数の値とステージの選択オプション

  • [パラメーター] パネルには、パイプライン パラメーターの値、UI で定義されている (シークレット以外の) 変数、選択したステージが表示されます。

パラメーター値:

パイプライン実行のために表示されるパラメーター値

UI で定義されている変数:

パイプライン実行用に表示されるユーザー インターフェイス変数

選択したステージ:

パイプライン実行で表示される選択済みステージ

Azure サービス接続に対するシークレット ローテーションのサポートの強化

サービス プリンシパルを使用し、Azure DevOps によってシークレットが作成されるサービス接続の場合、サービス接続を更新することでシークレットをローテーションできます。 ただし、これは構成エクスペリエンスでは明示的に伝えられなかった。 シークレットの有効期限を検出し、シークレットのローテーションを提供するように Azure サービス接続のエクスペリエンスを更新しました。

期限切れのシークレットをローテーションする Azure サービス接続オプション

AzureAppServiceManageV0 のバージョン対応拡張機能のサポート

App Service 拡張機能をname@versionとして指定できるようになりました (例: PythonExtension@3.9.0)。 バージョンが指定されている場合は、その正確なバージョンがインストールされます。 バージョンに latest を指定すると、使用可能な最新バージョンがインストールされます (既に最新バージョンがインストールされている場合は、インストールはスキップされます)。 バージョンが指定されていない場合、拡張機能がまだ存在しない場合にのみインストールされます。 例: ExtensionsList: MyExtension@1.2.3、OtherExtension@latest、LegacyExtension。

詳細については、 AzureAppServiceManage@0ドキュメントを参照してください。

リリース パイプラインを無効にする機能

リリース パイプラインが使用されなくなった場合、または再利用される予定がない場合に、リリース パイプラインを無効にできるようになりました。 この機能は、パイプライン管理を効率化し、煩雑さを軽減するのに役立ちます。 無効なパイプラインは引き続きアクセス可能であり、必要に応じていつでも再び有効にすることができます。

リリース パイプラインを無効にするオプション

新しいトリガーページ

YAML パイプラインには、パイプラインを実行するタイミングを定義するための強力なオプションが複数用意されています。 パイプラインがイベントに応答して実行されるように構成されているかどうかを判断するのは、必ずしも簡単ではありません。たとえば、フィーダーパイプラインが完了した場合などです。

このリリースでは、パイプラインで定義したトリガーの概要を示す トリガー ページが導入されました。

YAML パイプラインの [トリガー] ページ

リポジトリのメイン ブランチに次の YAML パイプラインが定義されている場合を想像してください。 同じ YAML パイプライン コードを持つ機能ブランチもあると考えてください。

trigger:
- main
schedules:
 - cron: 0 0 * * *
 always: true
 displayName: Nightly build
 branches:
 include:
 - main
resources:
 pipelines:
 - pipeline: FabrikamFiber
 source: FabrikamFiber
 trigger: true

[トリガー] ページに移動すると、次の情報が表示されます。

既定のブランチの継続的インテグレーション トリガーの詳細

パイプラインの既定のブランチ (main) が事前に選択されていることに注意してください。

このブランチには 継続的インテグレーション トリガー があり、YAML ファイルで定義されていることがわかります。

スケジュール トリガーに移動すると、トリガーが定義され、その詳細が表示されます。

YAML パイプラインのスケジュール トリガーの詳細

[リソース トリガー] セクションに移動すると、定義されたリソース トリガーとその詳細が表示されます。

YAML パイプラインのリソース トリガーの詳細

ブランチを main から feature に切り替えて、feature ブランチに対して定義したトリガーを確認できます。

機能ブランチの継続的インテグレーション トリガー

機能ブランチのトリガーを設定する

既定以外のブランチに対する警告をトリガーするリソース

[ リソース トリガー ] タブで、既定のブランチにない場合は、このブランチに対して定義されているトリガーが無視されていることを示す警告が表示されます。

トリガー定義がシステムによって正しく処理されなかった場合は、問題を解決する方法に関する警告と指示が表示されます。

処理できなかったトリガー定義の警告

StringList パラメーター型

開発者コミュニティで要求された上位の YAML パイプライン機能の 1 つは、 項目の一覧を含むパラメーターを定義することです。

このスプリント以降、この機能を提供する StringList という名前の新しいパラメーター型が追加されました。

たとえば、パイプライン実行をキューに入れるユーザーに、ペイロードを展開するリージョンの選択を許可するとします。 次の例に示すように、これを行うことができます。

parameters:
- name: regions
 type: stringList
 displayName: Regions
 values:
 - WUS
 - CUS
 - EUS
 default:
 - WUS
 - CUS
 - EUS

stages:
- ${{ each stage in parameters.regions}}:
 - stage: ${{stage}}
 displayName: Deploy to ${{stage}}
 jobs:
 - job:
 steps:
 - script: ./deploy ${{stage}}

このパイプラインをキューに入れると、次のスクリーンショットに示すように、デプロイする複数のリージョンを選択できます。

stringList パラメーターを使用した複数の領域の選択

Note

stringList データ型はテンプレートでは使用できません。 代わりに、テンプレートではオブジェクト データ型を使用してください。

パイプライン実行の完全な YAML コードを確認する

YAML パイプラインは構成可能です。 テンプレートを拡張して、パイプラインで必要な静的分析ツールを確実に実行し、一般的なステージまたはジョブまたはタスクを実行するためのテンプレートを含めることができます。

このようなパイプラインのデバッグは、実行されている完全な YAML コードが表示されないため、簡単ではありません。

次のパイプラインがあるとします。

parameters:
- name: PoolName
 type: string
 default: Azure Pipelines
- name: VmImage
 type: string
 default: ubuntu latest

extends:
 template: security-enforcing-template.yml
 parameters:
 jobs:
 - template: job.monitoring.yml
 - template: job.build.yml
 parameters:
 PoolName: ${{parameters.PoolName}}
 VmImage: ${{parameters.VmImage}}

ここでは、3 つのテンプレートを使用します。 各テンプレートでは、パラメーターと変数の値に基づいて条件式を使用して、実行する実際のジョブまたはステップを決定できます。

さらに、古いパイプラインの実行を見ると、パイプラインのコードが実行の実行時と同じかどうかがわかりません。

このリリースでは、パイプライン実行の完全な YAML コードを簡単に確認できる新しい機能が追加されています。

パイプライン実行の完全に拡張された YAML

YAML パイプライン ステージの依存関係の可視性の向上

YAML パイプラインを使用すると、複雑なワークフローを柔軟に管理できますが、ステージの依存関係を視覚化することは、特に複数リージョンのデプロイでは困難でした。

複雑な依存関係を持つパイプライン ステージ

ステージの接続方法が常に明確になっているわけではありません。 たとえば、CUS3 が WUS2 と WUS3 に加えて WUS1 に依存しているかどうかを判断するには、YAML を直接確認する必要があります。

このリリースでは、ステージの展開時にステージの依存関係が表示されるようになりました。これにより、実行順序とアップストリームの要件に関する即時の分析情報が提供されます。

依存関係を示す拡張パイプライン ステージ

新しいエージェント CDN

Edgio CDN の廃止が予定されているため、Edgio https://vstsagentpackage.azureedge.net が所有するドメイン URL も廃止されます。 新しい CDN でサポートされる新しいドメイン URL を追加しています。 この新しいドメイン URL をファイアウォールの許可リストに追加してください。 セルフホステッド エージェントのエージェント パッケージのダウンロードは、古いドメイン URL が削除されると失敗します。 詳細については、 投稿 を参照してください。

ノード 16 はパイプラインから削除されます-* パイプライン エージェント パッケージ

エージェント タスクは、PowerShell または Node で実装できます。 エージェントには、タスクがターゲットにできる複数のバージョンの Node が付属しています。

新しい Node バージョンがリリースされると、新しい Node バージョンを使用するように タスク が更新されます。 ランタイムはエージェントに含まれます。

ノード バージョンがアップストリームメンテナンス期間を終了しても、一部のパイプライン タスクは引き続きそれに依存します。 Azure DevOps は、サポートされているタスクをサポートされている Node バージョンに更新します。 サード パーティのタスクでは、以前のバージョンの Node を実行する必要がある場合があります。

これに対応するために、次の 2 種類のパイプライン エージェント パッケージがあります。

パッケージ ノードのバージョン Description
vsts-agent-* 6, 10, 16, 20 タスク実行ハンドラーとして使用できるすべての Node バージョンが含まれています
pipelines-agents-* 20 最新の Node バージョンのみが含まれます。 これらのパッケージの目標は、Node の有効期間が終了したバージョンを含めないようにすることです。

Node 16 がバンドルされていないエージェントで Node 16 実行ハンドラーを必要とするタスクを実行する場合は、パイプラインに NodeTaskRunnerInstaller@0 タスクを挿入して実行ハンドラーをインストールできます。

steps:

- task: NodeTaskRunnerInstaller@0

inputs:

runnerVersion: 16

パイプライン エージェントとタスクが Node.js 24 のサポート向けにアップグレードされました

パイプライン エージェントはバージョン 270 にアップグレードされ、Node.js 24 がサポートされるようになりました。 ほとんどの組み込みタスクも、既定で Node.js 24 を使用するように更新されています。 残りの組み込みタスクでは、現時点では引き続き Node.js 20 を使用しますが、今後のパッチ リリースで Node.js 24 をサポートするようにアップグレードされる予定です。

VS2026 のタスク サポート

VS2026 をサポートするために次のタスクがアップグレードされました

  • VsBuildV1
  • MSBuildV1
  • VSTestv3
  • NugetCommandV2

Test Plans

新しいテスト実行ハブ

新しいテスト実行ハブがAzure DevOps サーバーで使用できるようになったことをお知らせします。 主な機能と更新は次のとおりです。

  • テスト実行ハブのユーザー インターフェイス内の任意のページから情報を選択してコピーできるようになりました。
  • 自動テスト実行の場合、スタック トレース コンポーネントが強化され、完全なスタック トレースの読みやすさが向上しました
  • テストの実行中にキャプチャされたイメージを、各テスト結果ページでインラインでプレビューできるようになりました
  • 実行タイトルを使用した実行の検索機能ロジックが、検索語句で始まる実行タイトルと一致するようになりました
  • [実行の概要] ページの使いやすさと読みやすさが、列の最小および既定の幅の構成を更新して改善されました
  • 作業項目をリンクして、異なるプロジェクト間で実行をテストできるようになりました
  • パイプライン ログから特定の実行の概要に直接移動できるようになり、時間を節約し、余分なナビゲーション手順を排除できるようになりました
  • 自動実行の場合、すべてのサブ結果の添付ファイルが各テスト結果ページに表示され、詳細な結果を簡単に確認できるようになりました
  • 選択した時刻とロケールの形式に従って、時刻と日付の値が表示されるようになりました
  • 他のフィルターとは関係なく、プロジェクト内の実行 ID で検索する
  • 新しいテスト実行ハブの任意の画面からテキストをコピーして、共有と生産性の向上を容易にする
  • 読みやすさを向上させるために、テスト結果テーブルの列幅を最適化しました
  • 自動実行用に強化されたスタックトレースプレビューで分析を容易にする
  • 追跡を向上するためのテスト 所有者 と 最終更新日時 の列を追加しました
  • 自動サブ実行のすべての添付ファイルが、想定どおりに UI で使用できるようになりました
  • 探索的セッション中に作成されたテスト ケースが元のテスト ケースに正しくリンクされない問題を修正しました。

テスト ケースのインポート ウィザードの強化

テスト ケースのインポート ウィザードが改善され、生産性が向上しました。 これには、強化された自動マッピング、チーム間で共有できる再利用可能なマッピング テンプレート、インポートを効率化するための追加の機能強化が含まれます。 詳細については、インポート テスト ケースのパブリック ドキュメント を参照してください。

フォーカスされたテスト ポイント履歴パネル

以前は、[テスト計画] ページからポイント固有の履歴を簡単に確認する方法がありませんでした。結果履歴のテスト ポイントを区別するのが困難でした。

これで、[テスト プラン] ページから個々のテスト ポイントの実行履歴を直接表示できるようになりました。 さらに、[ すべての履歴の表示 ] を選択して、関連するテスト ケースの完全な実行履歴を確認できます。

個々のテスト ポイントの実行履歴パネル

一時停止されたテストケースの標準アクションが「再開」に変更されました。

再開の一時停止テスト ケース エクスペリエンスの強化により、再開はすべての一時停止された手動テスト フローの既定のアクションになり、中断したところから簡単に続行できます。 別のアクションを試みると、偶発的な進行状況の損失を防ぎ、よりスムーズなテスト エクスペリエンスを確保するために役立つ明確な警告が表示されます。

作業項目に関連付けられたテストケースが一般利用可能になりました

前の ブログ記事 で紹介した自動テスト関連付けフローが一般公開されたことをお知らせします。 自動テストを言語やフレームワーク間でリンクするだけでなく、テスト ケース自体から直接同じ関連付けを作成し、エクスペリエンスをより簡単に、より速く、より直感的にすることができます。

テスト ケースからの自動テストの関連付け

VSTest タスクを使用したデータ ドリブン テストのサポート

MSTest、NUnit、および xUnit フレームワークで、静的入力を使用するデータ ドリブン (パラメーター化) テストのサポートを追加しました。 パイプラインの実行では、各データ セットが実行され、個別のテスト試行として報告されるようになり、テスト カバレッジと実行結果の可視性が向上します。

データドリブン テストの各試行の個別の結果

Visual Studio Test v3 タスクの詳細については 、こちらをご覧ください。

バグ修正とアクセシビリティの向上

このリリースには、テスト ワークフロー、検索の信頼性、スクリーン リーダーの使いやすさの向上に重点を置いた、一連の対象となるバグ修正とアクセシビリティの強化が含まれています。 これらの更新プログラムは、開発者コミュニティによって報告された問題に対処し、主要なエクスペリエンスをより包括的かつ簡単にナビゲートできるようにします。

  • Web テスト ランナー内でインライン テスト ケース イメージをレンダリングする際の不整合に対処しました。

  • テスト ケース ビューのリンクされたアイテムが、開発者コミュニティで報告されたランダムな作業項目の問題を示す問題を修正しました。

  • [ 割り当て先] フィルターが適用されている間に実行状態を変更した後、テスト ケースが実行グリッドから消えるという開発者コミュニティで報告された問題を修正しました。

  • テスト ケースを削除するときの Boards と関連するテスト スイート間の同期の問題を修正しました。

  • イテレーションが指定されていない場合のより明確なガイダンスを提供するように、テストおよびフィードバック拡張機能のエラー メッセージを改善しました。

  • テスト計画の戻るボタンナビゲーションを修正しました。 [戻る] ボタンの機能を修正し、テスト ケース ビューからテスト プラン ビューへの正確な切り替えを可能にすることで、ナビゲーションの問題を解決しました。

  • テスト ポイントでは [テスト担当者] 列の名前が [現在のテスター] に変更されました。 テスト ポイントの割り当てに関する明確さを高めるために、以前に Tester というラベルが付いた列の名前が Current Tester に変更されました。 この変更は純粋に外観的であり、基になるシステム ロジックや機能には影響しません。

  • クエリ結果ウィンドウのサイズ変更の問題を修正しました。 要件ベースのスイートの作成時にクエリと結果領域のサイズが変更されない問題を解決しました。

  • 共有ステップを削除するときの欠落したリンクのクリーンアップを修正しました。 テスト ケースから共有ステップが削除されたときに[関連作業]リンクが削除されない不具合を解決しました。

  • 個々の手順のスクリーンショットが見つからない問題を修正しました。 テストおよびフィードバック拡張機能を使用する際に、個々の手順で一貫性のないスクリーンショット キャプチャを引き起こす不具合を解決しました。

  • テスト担当者の割り当てメールのハイパーリンクは、割り当てられたテスト担当者をテスト実行ページに移動します。 (テスト定義タブにリダイレクトするために使用されます)。

テスト実行ページへのテスト担当者の割り当てメール リンク

  • インポートされたテスト スイートは、設定された順序に従います。
  • テスト スイートに新しくインポートされたテスト ケースは、順序の一番下に表示されます。
  • テスト実行ページの所有者検索が修正され、期待される実行結果が表示されます。
  • ケースのエクスポートにおける非ラテン文字の問題を修正し、すべてのユーザー設定フィールド名が UI に表示されるとおりに正しくエクスポートされるようにしました。

アクセシビリティの向上

  • ナレーターは、[ 新しいテスト ケース ] ウィンドウ内のグリッド内の行と列の正しい数を発表するようになりました。
  • スクリーン リーダーのサポートを向上させるために、[新しい作業ウィンドウ] の [説明] テキスト ボックスにビジュアル ラベルの説明を追加しました。

自動テストをテスト ケースに関連付ける

以前に、さまざまな言語で記述 された自動テストを パイプラインから直接テスト ケースに関連付けるサポートが導入されました。 この機能が拡張され、テスト ケース自体から直接関連付けを開始できるようになりました。

テスト ケースでの自動テスト関連付けコントロール

テスト担当者の割り当てと構成変更のメッセージングの改善

テスト スイートまたはケースでテスト担当者または構成が更新された場合のプロンプトと完了メッセージが強化され、より明確なガイダンスが提供され、一時停止したテスト ポイントの進行状況が失われるリスクが軽減されます。

新しい Test Plans ディレクトリの概要

新しいテスト 計画ディレクトリを使用して整理し、時間を節約します。 テスト計画をより効率的に管理し、ワークスペースをより詳細に制御し、反復的なタスクを減らすのに役立ついくつかの機能強化が導入されています。

並べ替えとフィルター処理を使用した新しい Test Plans ディレクトリ

新機能は次のとおりです。

  • よりクリーンな UI デザイン: 読みやすさを向上させ、煩雑さを軽減する最新のインターフェイスを使用して、テスト計画を簡単にナビゲートし、タスクに集中することができます。
  • 列の並べ替え: 名前、状態、またはその他のキー属性に基づいて列を並べ替えることで、必要なものを迅速に見つけることができます。 この機能は、生産性を向上させるためのテスト計画をすばやく整理して優先順位を付けるのに役立ちます。
  • [すべて] タブの [チーム フィルター]: チーム別にテスト 計画をフィルター処理することで、重要なことに焦点を当て、作業と目標に合った関連する計画のみが表示されるようにします。
  • 永続的なフィルター: 設定を記憶する永続的なフィルターを使用して時間を節約します。 ページに戻ると、以前に適用したフィルターはそのまま残り、毎回フィルターを再適用しなくても整理されたビューが提供されます。

これらの更新プログラムは、ワークフローを合理化し、反復的なタスクを減らし、テスト計画の追跡と管理を容易にするように設計されています。 それを試してみて、ご意見を電子メールでお知らせください!

高度なテスト ケースの結果履歴

テスト ケースの結果ページの新しい機能強化により、主要なテスト実行の詳細を簡単に追跡できます。 実行 ID、パイプライン ID、所有者、反復パス、エリア パスなどの重要な情報がページに表示され、各テストの実行の概要が表示されます。

長い値とカスタマイズ可能な列の水平スクロールを追加しました。これにより、レイアウトをカスタマイズし、ユーザー レベルでユーザー設定を保存したままにできます。 すばやく移動できるように、実行 ID と行はクリック可能であり、より詳細な分析情報を得るために [テスト実行] ビューにすばやくアクセスできます。 これらの更新は、可視性の向上、時間の節約、ワークフローの合理化を目的としているため、テストの実行を効率的に追跡および管理しやすくなります。 お試しください。フィードバックがある場合は、メールでお知らせください。 皆様のご意見をお待ちしております。

[実行] タブでテスト ケースの状態を表示する

[実行] タブに [テスト ケースの状態] 列を追加して、各テスト ケースの状態をすばやく確認できるようになりました。 承認、進行中、またはその他の状態のいずれであっても、この更新プログラムを使用すると、ブラウザーのタブを切り替えたり、複雑なクエリを実行したりすることなく、テストの準備状態をより明確に把握できます。

列は省略可能であり、列ピッカーを使用して有効にすることができます。 また、既存の状態フィルターに合わせて調整されるため、テスト ケースの状態をすべて 1 か所で並べてフィルター処理して表示できます。

この機能強化により、テスト担当者は、真に準備完了または承認されたテスト ケースで実行を開始し、不完全な項目や下書きの項目を実行するリスクが軽減され、テストの実行が最初から効率的になります。

一時停止されたテスト ケースのデフォルトの再開

1 回のクリックで一時停止したテスト ケースをすばやく再開できます。 一時停止したテスト ケースの既定のアクションとして "再開" を行いました。これにより、余分なナビゲーションなしで中断したところから右に移動できます。 この更新プログラムを使用すると、中断することなく作業を迅速かつ簡単に続行できます。

進行状況をさらに保護するために、一時停止したテストの進行状況が誤って上書きされるのを防ぐための確認プロンプトが導入されています。 このセーフガードにより、部分的に保存された作業はそのまま維持され、テストの実行を管理しながら安心できます。 それを試してみて、ご意見を電子メールでお知らせください!

テスト 計画での YAML パイプラインのサポート

従来のパイプラインに加えて、テスト プランを構成するとき、またはテスト プランから自動テストを実行するときに、YAML パイプラインを使用できるようになりました。

この要求は、次の開発者コミュニティの提案チケットに基づいて優先順位が付けられます。

テスト プランでの YAML パイプラインの構成

テスト ケースで最近のテスト結果を表示する

テスト ケースの作業項目に新しい [最近のテスト結果 ] セクションが追加され、ビューを切り替えたり、テスト 計画を移動したりすることなく、テストの進行状況を簡単に監視できるようになりました。

この更新プログラムでは、次のことができます。

  • テスト ケースから直接上位 4 件の最新のテスト結果を表示する
  • 主要な詳細をひとめで確認する: 結果、実行者、構成、完了日
  • ワンクリックで完全な実行履歴にアクセスして詳細な分析を行う

テスト ケースに表示された最近のテスト結果

これらの機能強化により、実行の分析情報をテスト ケースが存在する場所に近づけることで、テスト レビューが効率化され、要件ベースの追跡可能性がサポートされます。 この機能は段階的にロールアウトされ、今後数週間以内に利用可能になります。

アクション ログの廃止と画面記録への切り替え

デスクトップの Azure Test Runner クライアントは、Windows 7 で導入されたツールである 問題ステップ レコーダー (PSR) に依存しています。このツールは、新しい Windows バージョンで 非推奨になりました 。 その結果、デスクトップ テスト ランナーのアクション ログ機能は、今後の更新では機能しなくなる可能性があります。

テストの追跡を中断しないように、Web ランナーのテスト とフィードバック拡張機能で画面記録に切り替えることをお勧めします。これにより、最新の信頼性の高い方法でテスト手順をキャプチャおよび管理できます。 テストおよびフィードバック拡張機能への移行に関するサポートが必要な場合は、サポート チームにお問い合わせください。

手動テストの実行を自動一時停止する

テストケースの自動一時停止実行を利用すれば、テストの進行状況を失うことはありません。 この新機能は、作業が中断された場合にテスト ケースの実行を自動的に一時停止し、手動による一時停止を必要とせずに部分的な進行状況を確実に保存します。 セッションを離れるか閉じるかに関係なく、中断した場所からテスト ケースを簡単に再開でき、データ損失のリスクが軽減され、ワークフローが改善されます。 一時停止と再開のプロセスを簡略化することで、自動一時停止は、進行状況を失うことを心配することなく、テストに集中するのに役立ちます。

GIFで自動一時停止の手動テスト実行をデモ

Reporting

バックログで利用可能なロールアップ列データ

ロールアップ列が更新され、利用可能な最新のデータが表示されます。 以前は、頻繁に更新される作業項目に対してこれらの列が空白で表示され、混乱が生じることがあります。 また、データが最後に更新された日時を示すタイムスタンプも表示されます。

Analytics 処理の遅延は通常どおりですが、これらの改善により、ロールアップ列を使用する際の透明性とスムーズなエクスペリエンスが提供されます。

データ更新タイムスタンプを持つバックログ ロールアップ列

  • 最終更新: