次の方法で共有

Azure DevOps サービスの更新と統合の機能強化

Azure DevOps 環境を確実にセキュリティで保護するために、Microsoft は主要なサービス更新を行っています。 これには、2025 年 4 月から新しい OAuth アプリの登録のサポートが終了しますが、既存のアプリは 2026 年に完全に提供終了するまで動作し続けます。 さらに、2025 年 4 月 23 日からのすべての HTTPS 接続に対して、Azure Repos の TFVC チェックイン ポリシーの更新と共に、サーバー名表示 (SNI) が必要になります。

これらの更新プログラムに加えて、Azure Boards + GitHub 統合の最新の機能強化が発表され、ブランチ、プル要求、作業項目へのコミットを簡単にリンクできるようになりました。 さらに、Pipelines では、YAML ステージの依存関係の可視性が向上し、チームがより複雑なワークフローを効率良く管理できるようになりました。

詳細については、リリース ノートを参照してください。

全般

Azure Boards:

Azure Repos

Azure Pipelines

Azure テストプランズ

全般

2025 年 4 月以降、新しい Azure DevOps OAuth アプリはありません

2025 年 4 月以降、Azure DevOps OAuth アプリの新しい登録はサポートされなくなりました。 これは、Azure DevOps OAuth プラットフォーム廃止に向けた長期的な取り組みの第一歩です。 すべての開発者が Azure DevOps REST API 上にアプリケーションを構築し、 代わりに Microsoft ID プラットフォーム を探索し、 新しい Entra アプリケーション を登録することをお勧めします。

既存の Azure DevOps OAuth アプリはすべて、2026 年にプラットフォームが正式に廃止されるまでは動作し続けます。 詳細については、 こちらのブログ記事を参照してください。

Azure DevOps Services でサーバー名表示 (SNI) が必須になりました

2025 年 4 月 23 日より、Azure DevOps Services へのすべての受信 HTTPS 接続に サーバー名表示 (SNI) が必要になります。

SNI は TLS プロトコルの拡張機能であり、クライアントは接続先のホスト名を指定できます。 最新のブラウザーとクライアント ソフトウェアはすべて SNI をサポートし、既定で使用するため、ほとんどのユーザーがシームレスに移行できます。 実際、サーバーに到達する顧客トラフィックの 99.995% 以上が SNI 対応です。

ただし、古い、正しく構成されていないネットワーク ライブラリ、ランタイム、オペレーティング システムなど、さまざまな要因により、一部のクライアント ソフトウェアが SNI と互換性がない可能性があります。 プロキシまたは NGFW ファイアウォールからも問題が発生する可能性があります。 Azure DevOps で使用される次のツールは、SNI の問題の影響を受ける可能性があります。

  • Git クライアント
  • IDE プラグインと拡張機能 (Team Explorer Everywhere)
  • SNI (Java 6 以前) をサポートしていない、または SNI が既定で有効になっていない古い Java バージョン (Java 7 および 8 の一部のバージョン) で実行されているソフトウェア
  • 以前のバージョンのブラウザー ( https://caniuse.com/sniを参照)

SNI の問題は、通常、次のような接続エラーによって発生します。

  • ERR_SSL_PROTOCOL_ERROR（SSLプロトコルエラー）、ERR_CERT_COMMON_NAME_INVALID（証明書の共通名が無効）
  • javax.net.ssl.SSLHandshakeException、javax.net.ssl.SSLException
  • SSL/TLS セキュリティで保護されたチャネルの信頼関係を確立できませんでした

システムの SNI 互換性を検証するには、SNI を要求するように構成した Azure DevOps の状態エンドポイントを呼び出します。 この呼び出しが成功した場合は、ホスト (オペレーティング システムとネットワーク環境を含む) が SNI と互換性があることを示します。 テスト方法の詳細については、 ブログ記事をご覧ください。

Azure Boards

GitHub 統合: コミット、ブランチ、プル要求へのリンクの改善

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

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

  • GitHub ブランチが作業項目にリンクされると、関連付けられているすべてのプル要求が自動的にリンクされるようになります。 AB# を手動で使用する必要はありません。

  • プル要求がマージされると、マージ コミットは作業項目に自動的にリンクされます。

  • プル要求がマージされた後にブランチが削除された場合、ブランチ リンクは作業項目から自動的に削除されます。

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

GIF から GitHub へのボード統合の機能強化。

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

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

作業項目を自動的にリンクするスクリーンショット。

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

ビルドに統合されているスクリーンショット。

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

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

Azure Repos

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 の使用。

警告

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

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

修正前のスクリーンショット

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

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

GetRepository API の機能強化

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

Pull Requests Query API の機能強化

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

注

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

要求ペイロードの例:

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

Azure Pipelines

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

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

複数の Azure リージョンにデプロイされるパイプラインのスクリーンショット。

ステージの接続方法が常に明確になっているわけではありません。 たとえば、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 種類のパイプライン エージェント パッケージがあります。

パッケージ ノードのバージョン 説明
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

Azure Test Plans

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

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

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

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

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

Web およびデスクトップ ランナーで元に戻すテスト ステップをデモする Gif。

次のステップ

注

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

提案を行う

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

シルヴィウ アンドリカ

  • Last updated on