- GitHub Advanced Security for Azure DevOps
- Azure Boards
- Azure Repos
- Azure Pipelines
- Azure Test Plans
- Next steps
- How to provide feedback
今回の更新では、TFVC リポジトリの作成を無効にする新しい設定を導入します。この変更は、既存の TFVC リポジトリが影響を受けないようにしながら、新しいプロジェクトに焦点を当てています。
さらに、Azure Pipelines で、OIDC トークンを要求するための新しい REST API エンドポイントが利用可能になったことをお知らせします！これにより、タスク開発者は Entra ID 認証用の idTokens を生成できるようになり、セキュリティと使いやすさが向上します。
最後に、Azure Boards では、作業項目に関連付けられていない場合、エリアパスとイテレーションパスの削除ができるようになりました。この改善により、中断を防ぎ、チームがボードとバックログへのアクセスを維持できるようになりました。
詳細はリリースノートをご覧ください。
- Entra ID認証を使ったAzure Service Busへの接続ができるようになりました
- パイプラインとタスクでWorkload identityフェデレーション認証のREST APIエンドポイントの取得ができるようになりました
- サーバータスクの再試行が可能になりました
- OIDCに必要なidTokenの更新の要求ができるようになりました
- 保守が終了したNodeに依存しているタスク実行時に警告を出すようになります
- DockerCompose@0タスクはv1互換モードでDocker Compose v2を使用します
Advanced Security の概要リスクタブを提供する API のドキュメントが利用可能になりました。/{organization}/_apis/reporting/summary/alertsというエンドポイントを使用して、Advanced Security が有効なすべてのリポジトリにわたるアラートの重要度の概要を表示します。ADO PAT にアラート、結果インスタンス、分析結果インスタンスを読み取れる vso.advsec 権限があることを確認してください。
エリアやイテレーションパスを削除すると、混乱が生じる可能性があります。ワークアイテムが新しいパスに移動し、チームがボードやバックログにアクセスできなくなる可能性があります。警告やプロンプトが表示されるにもかかわらず、その結果を十分に理解せずにパスが削除されることがあります。これに対処するため、私たちはエリアパスとイテレーションパスは、どのワークアイテムでも使用されなくなった場合のみ削除できるように仕様を変更しました。
ここ数年、Team Foundation Version Control（TFVC）に新しい機能が追加されることはありませんでした。GitがAzure Reposで好まれるバージョン管理システムになったからです。セキュリティ、パフォーマンス、アクセシビリティにおける最近の改善はすべてGitリポジトリに対してのみ行われたため、TFVCの利用は減少の一途をたどっています。まだTFVCに依存しているものもあり、この機能セットを削除するつもりはありませんが、新しいプロジェクトや組織、現在TFVCを使用していないプロジェクトについては、段階的にTFVCを廃止していく予定です。
この移行の一環として、「TFVCリポジトリの作成を無効にする」という新しい設定を導入します。これは新しいTFVCリポジトリの作成にのみ影響し、既存のリポジトリには影響しません。
Azure Pipelines から Azure Service Bus へのアクセスに Entra ID 認証を使用できるようになりました。これにより、Workload ID フェデレーションを利用してシークレット管理をなくし、Azure RBAC を利用してきめ細かいアクセス制御が可能になりました。
Azure Service Bus にアクセスする ID には、アクセスする Service Bus 上で Azure Service Bus 用の Azure 組み込みロールのいずれかを付与する必要があります。
新しい PublishToAzureServiceBus@2 タスクでは、Azure Service Connectionが使用可能となりました。Azure Service Connectionを作成し、新しいタスクの serviceBusQueueName プロパティと serviceBusNamespace プロパティを入力します。
- task: PublishToAzureServiceBus@2
inputs:
azureSubscription: my-azure-service-connection
serviceBusQueueName: my-service-bus-queue
serviceBusNamespace: my-service-bus-namespace
useDataContractSerializer: false
messageBody: |
{
"foo": "bar"
}ServiceBus 実行を使用するカスタムサーバー (エージェントレス) タスクは、EndpointId として Azure Service Connection を指定することで、ConnectionStringの省略ができるようになりました。Server task authoringを参照してください。
OIDC tokenを要求する REST API エンドポイントが、System.OidcRequestUri パイプライン変数で利用できるようになりました。タスク開発者はこの変数を利用して、Entra ID で認証するための idToken を生成できます。
Azure へのデプロイに Marketplace タスクまたはカスタム タスクを使用している場合、これらのタスクはワークロード ID 連携をまだサポートしていない可能性があることに注意してください。タスク開発者は、セキュリティ対策を向上させるために、ワークロード ID 連携を有効にすることをお勧めします。
task.jsonにconnectedService:AzureRMを入力するタスクは、以下の手順を追加することで、ワークロードIDフェデレーションをサポートが可能になります。
- Oidctoken REST API を利用して idToken をリクエストする（上図の矢印 1）。
- OAuth API の連携クレデンシャルフローを使用して、idToken を
client_assertionとして指定し、idToken をアクセストークンと交換する（上図の矢印 2 と 4）。 または - 認証自体を実行するツールのラッパーとして機能するタスクの場合は、ツールの認証メソッドを使用して連携トークンを指定します。
Nodeタスクは、azure-pipelines-tasks-artifacts-common npm パッケージを使用して idToken を取得できます。実装の詳細については、コード例を参照してください。
AzureCLI@2タスクとAzurePowerShell@5タスクで公開されているSystem.OidcRequestUriパイプライン変数とAZURESUBSCRIPTION_SERVICE_CONNECTION_ID環境変数により、パイプライン作成者は独自のスクリプトから認証が可能になります。
- task: AzurePowerShell@5
inputs:
azureSubscription: 'my-azure-subscription'
scriptType: inlineScript
inline: |
# Request fresh idToken
Invoke-RestMethod -Headers @{
Authorization = "Bearer $(System.AccessToken)"
'Content-Type' = 'application/json'
} `
-Uri "${env:SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${env:AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}" `
-Method Post `
| Select-Object -ExpandProperty oidcToken
| Set-Variable idToken
# Fetch current context
$azContext = Get-AzContext
# Start new Az session
Connect-AzAccount -ApplicationId $azContext.Account.Id `
-TenantId $azContext.Tenant.Id `
-SubscriptionId $azContext.Subscription.Id `
-FederatedToken $idToken- task: AzureCLI@2
inputs:
addSpnToEnvironment: true
azureSubscription: 'my-azure-subscription'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
# Request fresh idToken
OIDC_REQUEST_URL="${SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}"
ARM_OIDC_TOKEN=$(curl -s -H "Content-Length: 0" -H "Content-Type: application/json" -H "Authorization: Bearer $(System.AccessToken)" -X POST $OIDC_REQUEST_URL | jq -r '.oidcToken')
# Save subscription context
ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
# New az-cli session
az login --service-principal -u $servicePrincipalId --tenant $tenantId --allow-no-subscriptions --federated-token $ARM_OIDC_TOKEN
az account set --subscription $ARM_SUBSCRIPTION_IDAzureFunctionやInvokeRESTAPIのような外部システムを呼び出すサーバータスクは、コンピュートリソースの枯渇のような一過性のエラーによって失敗することがあります。以前は、このような失敗により、ジョブ全体、そしてパイプラインが失敗する可能性がありました。
一時的なエラーに対する耐性を向上させるために、サーバータスクのretryCountOnTaskFailureプロパティのサポートを導入しました。パイプラインに次のようなYAMLコードがあるとします。
- stage: deploy
jobs:
- job:
pool: server
steps:
- task: AzureFunction@1
retryCountOnTaskFailure: 2
inputs:
function: 'https://api.fabrikamfiber.com'
key: $(functionKey)
method: 'POST'
waitForCompletion: 'false'https://api.fabrikamfiber.com で一過性のエラーが発生した場合、Azure Pipelines はリクエストを最大 3 回再試行します（最初の試行と、retryCountOnTaskFailure で指定された 2 回の再試行）。各再試行には、増加する待機期間が含まれます。許可される最大再試行回数は10回である。
retryCountOnTaskFailureは、ManualValidationタスクと外部システム・コールを伴わない他のタスクでは使用できません。
保守が終了した Node バージョンに依存するパイプライン・タスクは、警告を受け取り始めます。
Task
TaskNameversion<version>is dependent on a Node version (10) that is end-of-life. Contact the extension owner for an updated version of the task. Task maintainers should review Node upgrade guidance: https://aka.ms/node-runner-guidance
Task
TaskNameバージョン<version>はNode バージョン (10) に依存しており、保守が終了しています。タスクの更新バージョンについては、拡張機能の所有者に連絡してください。タスクメンテナは Node アップグレードガイダンス https://aka.ms/node-runner-guidance を確認してください。
これらの警告を抑制するには、パイプライン（ジョブ）またはタスクレベルで環境変数またはパイプライン変数を設定します。例えば以下のようになります。
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: falseDocker Compose v1は2024年7月にサポートが終了し、Hosted Agentから削除されます。v1互換モードでDocker Compose v2を使用するためにDockerCompose@0タスクを更新しました。
Azure DevOps Test and Feedback拡張機能の新しいアップデートをお知らせします！このアップグレードは、GoogleのManifest V2の非推奨スケジュールに合わせて、私たちの実装をManifest Version 2からVersion 3に移行します。
拡張機能のコア機能に変更はありませんが、このアップデートによりセキュリティとパフォーマンスが向上します。更新された拡張機能は、今後数週間かけてChromeとEdgeの両ブラウザに順次展開されます。パフォーマンスとフィードバックを監視し、スムーズな移行を確保した後、結果に基づいて展開を拡大します。
詳細については、このアップデートに関する最近のブログ投稿Test & Feedback Extension in Manifest V3をご覧ください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Silviu Andrica