- General
- Azure Boards
- Azure Repos
- Azure Pipelines
- Azure Test Plans
- Next steps
- How to provide feedback
お使いの Azure DevOps 環境を引き続き安全に保つために、重要なサービス更新を行っています。これには、2025 年 4 月から新しい OAuth アプリ登録のサポートを終了することが含まれますが、既存のアプリは 2026 年の完全な廃止まで引き続き動作します。さらに、2025 年 4 月 23 日から、すべての HTTPS 接続に対してServer Name Indication (SNI) が必要になり、Azure Repos の TFVC チェックイン ポリシーが更新されます。
これらのアップデートに加えて、Azure Boards + GitHub 統合の最新の改善を発表できることを嬉しく思います。これにより、ブランチ、pull request、およびコミットを作業項目にリンクすることが容易になります。さらに、Pipelines は YAML ステージの依存関係の可視性を向上させ、チームがより複雑なワークフローを効率的に管理できるようにします。
詳細については、リリース ノートをご覧ください。
- 2025年4月よりAzure DevOps OAutアプリケーション新規登録を停止します
- Azure DevOps サービスにおいて、Server Name Indication (SNI)が必須になります
- GitHub 統合: コミットとの関連付けの改善を行いました。ブランチやpull requestが対象です
- GitHub 統合: YAMLパイプラインでビルド結果を表示する
- Delivery Plansの制限を緩和しました
2025 年 4 月から、Azure DevOps OAuth アプリの新規登録のサポートを終了します。これは、Azure DevOps OAuth プラットフォームを廃止するという長期的なビジョンに向けた最初のステップです。Azure DevOps REST API を使用してアプリケーションを構築するすべての開発者は、Microsoft identity platform を検討し、代わりに 新しい Entra アプリケーション を登録することをお勧めします。
既存のすべての Azure DevOps OAuth アプリは、2026 年のプラットフォームの公式廃止まで引き続き動作します。詳細については、こちらのブログ投稿 をご覧ください。
2025 年 4 月 23 日から、Azure DevOps Services へのすべての受信 HTTPS 接続に Server Name Indication (SNI) が必要になります。
SNI は TLS プロトコルの拡張機能で、クライアントが接続先のホスト名を指定できるようにします。すべての最新のブラウザーおよびクライアント ソフトウェアは SNI をサポートしており、デフォルトで使用するため、ほとんどのユーザーにとってシームレスな移行が保証されます。実際、当社のサーバーに到達する顧客トラフィックの 99.995% 以上が SNI 対応です。
ただし、古く誤って、構成されたネットワーク ライブラリ、ランタイム、またはオペレーティング システムなど、さまざまな要因により、一部のクライアント ソフトウェアが SNI と互換性がない場合があります。プロキシや NGFW ファイアウォールによっても問題が発生する可能性があります。Azure DevOps で使用される次のツールは、SNI の問題の影響を受ける可能性があります。
- Git クライアント
- IDEプラグインおよび、拡張機能(Team Explorer Everywhere)
- SNI をサポートしていない古い Java バージョン (Java 6 およびそれ以前) で実行されているソフトウェア、またはデフォルトで SNI が有効になっていない Java 7 および 8 の一部のバージョン
- 古いブラウザ バージョン (https://caniuse.com/sniを参照)
SNI の問題は通常、次のような接続エラーとして表示されます。
- ERR_SSL_PROTOCOL_ERROR , ERR_CERT_COMMON_NAME_INVALID
- javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
- Couldn't establish trust relationship for the SSL/TLS secure channel
Azure DevOps のステータス エンドポイントは SNI をサポートしているので、呼び出すことで、システムの SNI 互換性を検証できます。この呼び出しが成功した場合、それは、オペレーティング システムやネットワーク環境を含むホストが SNI と互換性があることを示しています。テスト方法の詳細な手順については、ブログ投稿 をご覧ください。
われわれは、使いやすさのギャップを解消し、Azure Repos でお馴染みのエクスペリエンスに合わせるために、Boards + GitHub 統合を継続的に改善しています。
今回の更新により、ブランチ、pull request、およびコミットが作業項目に関連付けされる方法を合理化するためのいくつかの改善を導入しました。
- GitHub ブランチが作業項目にリンクされると、関連するpull requestが自動的にリンクされるようになりました。AB# を手動で使用する必要はありません。
- pull requestがマージされると、マージコミットが自動的に作業項目にリンクされます。
- pull requestがマージされた後にブランチが削除された場合、ブランチリンクは作業項目から自動的に削除されます。
これらの改善により、開発の進捗状況を追跡し、最新の作業項目の関連付けを維持することが容易になります。
YAML パイプラインとClassic パイプラインの機能の均等化を目指しています。重要な欠落機能の 1 つは、リポジトリが GitHub にホストされている場合に"Integrated in build"リンクを提供する機能でした。最新リリースでは、YAML パイプライン設定にオプションを追加して、このギャップに対処しました。
ビルドが完了すると、対応するリンクが関連する作業項目に自動的に表示され、全体的なトレーサビリティが向上します。
以前は、プロジェクトごとのDelivery Plansが 1,000 件に制限されていました。今回の更新により、プロジェクトごとのDelivery Plansの最大数を 1,500 に増加させました。 Delivery Plansの追加と編集の詳細については、ドキュメント をご覧ください。
NuGet パッケージ Microsoft.TeamFoundationServer.ExtendedClient が新しい TFVC ポリシー クラスとメソッドで更新されました。
TFVC チェックイン ポリシーの Azure DevOps への保存方法を変更しています。これにより、NuGet Microsoft.TeamFoundationServer.ExtendedClient がサービスと通信する方法も更新されます。
TFVC プロジェクトでチェックイン ポリシーを使用している場合は、それらのポリシーを新しい形式に移行する必要があります。 これを行う方法は 2 つあります。
- Visual Studio を使用します。
Warning
実行前の危険な注意事項: 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 を開き、古いポリシーと同じパラメーターで新しいポリシー ( "Obsolete"マークなし) を追加する必要があります。
- サーバーと通信するために
Microsoft.TeamFoundationServer.ExtendedClientのカスタム実装を使用している場合は、移行ガイド に従ってください。
将来の Azure DevOps バージョンとTFVC チェックインの互換性を保つためには、移行が必要です。当面の間、古い (Obsolete) ポリシーと新しいポリシーの両方が有効で機能します。将来の計画については、ブログ投稿 をご覧ください。
Wリポジトリの作成日を返す Repositories - Get Repository API のレスポンスに creationDate プロパティが追加されました。このプロパティは API バージョン 7.2-preview 以降で利用可能です。
Pull Request Query - Get API のレスポンスに新しい Label プロパティを導入しました。これで、関連するpull requestのラベル (tags) をすべてのクエリに含めるかどうかを指定できるようになりました。新しい Include プロパティが利用可能です - Labels に設定すると、レスポンスに指定された PR のラベルが含まれます。null のままにすると、ラベルは含まれません。意図しないエラーを防ぐために、NotSet が明示的に割り当てられていないことを確認してください - これにより Bad Request になります。
注意
ラベルの強化リソースの使用率は、割り当てられたラベルの数とその長さに依存します。ラベルのリクエストはスロットリングに影響を与え、ネットワーク負荷を増加させる可能性があります。パフォーマンスを最適化するために、不要なラベルリクエストは避けることをお勧めします。
リクエスト ペイロードの例。
{
"queries": [
{
"type": "lastMergeCommit",
"include": "Labels",
"items": [
"0d6c9b2b524113113fced41aecbf8631a4649dec"
]
},
{
"type": "lastMergeCommit",
"items": [
"b524113113f0dd41aecbf8631a4649dec6c9b2ce"
]
}
]
}YAML パイプラインは、複雑なワークフローを管理するための柔軟性を提供しますが、ステージの依存関係を視覚化することは、特にマルチリージョン展開では課題となっていました。
ステージがどのように接続されているかは常に明確ではありませんでした。たとえば、CUS3 が WUS2 および WUS3 に加えて WUS1 に依存しているかどうかを判断するには、YAML を直接確認する必要がありました。
このスプリントでは、ステージが展開されるとステージの依存関係が表示されるようになり、実行順序と上流の要件に関する依存関係がすばやく確認できます。
Edgio CDN が廃止されるため、Edgio が所有するドメイン URL https://vstsagentpackage.azureedge.net も廃止されます。新しい CDN によってサポートされる新しいドメイン URL https://download.agent.dev.azure.com を追加しています。この新しいドメイン URL をファイアウォールの許可リストに追加してください。古いドメイン URL が削除されると、セルフホスト型エージェントのエージェント パッケージのダウンロードが失敗します。詳細については、投稿を参照してください。
エージェント タスクは PowerShell または Node で実装できます。エージェントには、タスクがターゲットにできる複数のバージョンの Node が付属しています。
新しい Node バージョンがリリースされると、タスクは新しい Node バージョンを使用するように更新されます。ランタイムはエージェントに含まれています。
Node バージョンが上流のメンテナンス ウィンドウから外れたとしても、一部の Pipelines タスクは引き続きそれに依存しています。Azure DevOps は、サポートされているタスクをサポートされている Node バージョンに更新します。サードパーティのタスクは、実行するために古い Node バージョンが必要な場合があります。
この問題に対応するために、2 種類のパイプラインエージェントパッケージがあります。
| パッケージ名 | Node バージョン | 説明 |
|---|---|---|
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 Runner クライアントは、Windows 7 で導入されたツールであり、現在は新しい Windows バージョンで非推奨となっている Problem Steps Recorder (PSR) に依存しています。その結果、デスクトップテストランナーのアクションログ機能は、将来の更新で機能しなくなる可能性があります。
テスト追跡機能が使えなくならないようにするために、Web ランナーである Test & Feedback Extension の画面記録に切り替えることをお勧めします。これにより、テスト手順をキャプチャおよび管理するための最新の信頼できる方法が提供されます。Test & Feedback Extension への移行に関して支援が必要な場合は、サポート チームにお問い合わせください。
自動一時停止テスト ケースの実行により、テスト実行の進行状況が失われることはありません。この新機能は、作業が中断された場合にテストケースの実行を自動的に一時停止し、手動で一時停止することなく部分的な進行状況が保存されるようにします。 離席する場合でもセッションを閉じる場合でも、テスト ケースを中断した場所から簡単に再開できるため、データ損失のリスクが軽減され、ワークフローが改善されます。 一時停止と再開のプロセスを簡素化することで、自動一時停止により、進行状況を失うことを心配することなく、テストに集中できます。ぜひお試しいただき、ご意見をメールでお知らせください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。 ありがとうございました。
Silviu Andrica