Azure DevOpsでGitHub Secret ProtectionおよびGitHub Code Securityをスタンドアロンの製品として利用できるようになりました。Secret Protectionはシークレットスキャン、プッシュ保護、セキュリティ概要機能を提供します。Code Securityはすべての依存関係スキャン、コードスキャン、セキュリティ概要機能を提供します。
Test Plansでは、新しいTest Plansディレクトリをリリースし、整理しやすく、時間を節約できるようになりました。これにより、作業スペースをより効率的に管理でき、繰り返し作業を減らすことができます。
詳細については、リリースノートをご確認ください。
- 組織ポリシーでパーソナルアクセストークン（PAT）の作成を制限する機能がパブリックプレビューとして利用可能になりました
- 180日以上有効期限が切れたAzure DevOps OAuthアプリを削除します
- Azure DevOpsへのログインフローがAzure Resource Manager（ARM）に依存しなくなりました
- 新しいMicrosoft Entra OAuthスコープを追加しました
- アクセス権リクエストURLを提供開始しました
- Managed DevOps Poolsでのイメージ非推奨
- 新しいTriggersページを導入しました
- StringListパラメーター型を追加しました
- YAMLパイプラインの実行時に、実際に実行されている完全なYAMLコードを確認できるようになりました
- 新しいTest Plansディレクトリを紹介します
- テストケース結果履歴の機能強化を行いました
- Executeタブにテストケースの状態を表示できるようになりました
- 既定で一時停止中のテストケースをワンクリックで再開できるようになりました
Azure DevOpsでGitHub Advanced SecurityがGitHub Secret ProtectionおよびGitHub Code Securityとしてスタンドアロン製品として利用できるようになりました
GitHub Secret ProtectionおよびGitHub Code Securityが、新規のお客様向けにAzure DevOpsでスタンドアロン製品として購入できるようになりました。
Secret Protectionはシークレットスキャン、プッシュ保護、セキュリティ概要機能を提供します。Code Securityはすべての依存関係スキャン、コードスキャン、セキュリティ概要機能を提供します。
既存のAdvanced Securityのお客様は、これまで通りバンドル製品として利用を継続できます。スタンドアロン製品への切り替えを希望される場合は、Azure PortalからAzure DevOpsサポートにお問い合わせください。GitHub Advanced Security for Azure DevOpsサービスのサポートチケットを作成し、問題の種類としてBilling migration from bundled to standalone productsを選択してください。
詳細はDev Blogをご覧ください。
Azure DevOpsに新しい組織レベルのポリシー「パーソナルアクセストークン（PAT）の作成制限」がパブリックプレビューで追加されました。この長らく要望されていた機能により、プロジェクトコレクション管理者がPATの作成や再生成を許可するユーザーを制御でき、トークンの乱立を防ぎ、セキュリティを向上させます。有効化すると、許可リストに登録されたユーザーのみがPATを生成でき、パッケージスコープのサポートもオプションで利用できます。また、明示的に許可されていない限り、グローバルPATの使用もブロックされます。このポリシーや導入のベストプラクティスについてはこちらのブログ記事をご覧ください。
2026年のAzure DevOps OAuthアプリのサポート終了に向けて、有効期限が6か月（180日）以上前に切れたシークレットを持つアプリを定期的に削除します。該当する非アクティブなアプリの所有者には通知され、2026年のサポート終了までにアプリ登録が必要な場合は、6月9日までにアプリシークレットをローテーションしてください。詳細はこちらのブログ記事をご覧ください。
Azure DevOpsへのログインやEntraアクセストークンのリフレッシュ時に、Azure Resource Manager（ARM）リソースへの依存がなくなりました。ARMリソースはAzureポータルと関連付けられることが多く、管理者は条件付きアクセス ポリシー（CAP）でポータルへのアクセスを制限したい場合があります。
これまでADOがARMに依存していたため、管理者はすべてのADOユーザーにARM CAPをバイパスする許可を与える必要がありましたが、サインインやトークンリフレッシュ時のARMリソース要件がなくなったことで、これが不要になりました。
ただし、以下のユーザーグループは引き続きARMへのアクセスが必要です。
- 請求管理者は請求設定やサブスクリプションへのアクセスのためにARMが必要です
- サービス接続の作成者は、ARMロールの割り当てやMSIの更新のためにARMへのアクセスが必要です
Azure DevOpsのパーソナルアクセストークン（PAT）のライフサイクル管理APIのセキュリティと制御を強化するため、vso.patsおよびvso.pats_manageという2つの新しいMicrosoft Entra OAuthスコープが導入されました。これらのスコープは、PATの作成や管理を伴う委任フローで必要となり、従来の広範なuser_impersonationスコープに代わるものです。この変更により、アプリ所有者はPAT APIへのアクセスに必要な権限を最小限に抑えることが可能となります。user_impersonationアプリは、必要最小限のスコープにダウンスコープしてください。
Azure DevOps管理者は、Request Accessポリシーを無効にし、組織やプロジェクトへのアクセスリクエスト用のURLをユーザーに提供できます。このURLは従来新規ユーザーのみに表示されていましたが、既存ユーザーにも404ページで表示されるようになりました。プロジェクトの存在に関わらず、リクエストアクセスURLは表示され、機密性が維持されます。
Windows Server 2019ホストイメージの非推奨およびUbuntu 20.04の非推奨に伴い、Managed DevOps Poolsでは「Azure Pipelines – Windows Server 2019」イメージおよびUbuntu 20.04イメージが非推奨となります。詳細はこちらをご覧ください。Managed DevOps Poolsで提供されるイメージのライフサイクルについてはこちらをご参照ください。
YAMLパイプラインでは、パイプラインの実行タイミングを柔軟に定義できますが、イベント（例：フィーダーパイプラインの完了）に応じてパイプラインが実行されるかどうかを把握するのは簡単ではありません。
今回のスプリントでは、パイプラインで定義されているトリガーの概要を確認できるTriggersページを導入しました。
例えば、リポジトリのmainブランチに次のYAMLパイプラインが定義されているとします。また、同じYAMLパイプラインコードを持つfeatureブランチも存在すると仮定します。
trigger:
- main
schedules:
- cron: 0 0 * * *
always: true
displayName: Nightly build
branches:
include:
- main
resources:
pipelines:
- pipeline: FabrikamFiber
source: FabrikamFiber
trigger: trueTriggersページに移動すると、次のような画面が表示されます。
パイプラインのデフォルトブランチであるmainがあらかじめ選択されています。
このブランチにはContinuous integration triggerがあり、YAMLファイルで定義されています。
スケジュールトリガーのセクションに移動すると、定義されているトリガーとその詳細が確認できます。
Resource Triggerのセクションに移動すると、定義されているリソーストリガーとその詳細が表示されます。
mainブランチからfeatureブランチに切り替えて、そのブランチで定義されているトリガーを確認することもできます。
Resource Triggerタブでデフォルトブランチ以外を選択している場合、そのブランチで定義されたトリガーは無視される旨の警告が表示されます。
トリガー定義がシステムで正しく処理されなかった場合、警告と解決方法の案内が表示されます。
Developer Communityで最も要望の多かったYAMLパイプライン機能の1つが、define parameters that contain a list of itemsです。
今回のスプリントで、この機能を実現する新しいパラメーター型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}}このパイプラインを実行する際、以下のスクリーンショットのように複数のリージョンを選択できます。
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コードを簡単に確認できる新機能が追加されました。
新しいTest Plansのディレクトリは、整理しやすく、時間の節約ができます。テスト計画管理をより効率的に行えるよう、複数の機能強化が導入され、作業スペースの管理性が向上し、繰り返し作業が削減されます。
新機能は以下の通りです。
- UIが一新され、読みやすく、煩雑さが軽減され、作業に集中しやすくなりました。
- 名前やステータスなどの主要属性で列を並べ替えられるようになり、必要な情報を素早く見つけて優先順位付けできます。
- Allタブでチームごとにテストプランをフィルタリングでき、関連するプランだけを表示できます。
- フィルター設定が保持され、ページを再訪しても以前のフィルターが維持されます。毎回フィルターを再設定する必要がありません。
これらのアップデートは、ワークフローの効率化、繰り返し作業の削減、テスト計画の追跡・管理の容易化を目的としています。ぜひお試しいただき、ご意見をメールでお知らせください！
テストケース結果ページの機能強化により、テスト実行の主要な詳細を簡単に追跡できるようになりました。Run ID、Pipeline ID、Owner、Iteration Path、Area Pathなどの重要な情報がページ上に表示され、各テスト実行の全体像を一目で把握できます。
値が長い場合の横スクロールやカスタマイズ可能な列が追加され、レイアウトを個人ごとに調整できるようになりました。Run IDや行はクリック可能で、テスト実行ビューに素早くアクセスできます。これらのアップデートは、可視性の向上、時間の節約、ワークフローの効率化を目的としています。ぜひお試しいただき、ご意見をメールでお知らせください！
ExecuteタブにTest Case State列を追加できるようになり、各テストケースの状態（Approved、In Progressなど）をすぐに確認できるようになりました。これにより、ブラウザタブを切り替えたり複雑なクエリを実行したりせずに、テストの準備状況が明確に把握できます。
この列はオプションで、カラムピッカーから有効化できます。既存のStateフィルターとも連動し、1か所で状態のフィルタリングと表示が可能です。
この機能強化により、テスターは本当にReadyまたはApprovedなテストケースから実行を開始でき、不完全または下書き状態の項目を実行してしまうリスクが減り、テスト実行の効率が向上します。
一時停止中のテストケースをワンクリックで素早く再開できるようになりました。Resumeがデフォルトアクションとなり、余計な操作なしで中断した場所からすぐに作業を再開できます。
進捗をさらに保護するため、一時停止中のテスト進捗が誤って上書きされないよう確認プロンプトが導入されました。これにより、途中まで保存した作業が安全に保たれ、安心してテスト実行を管理できます。ぜひお試しいただき、ご意見をメールでお知らせください！
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。 質問がある場合はStack Overflowコミュニティでお尋ねください。
ありがとうございました。