TFVC リポジトリの作成を無効にする設定
この更新プログラムでは、TFVC リポジトリの作成を無効にする新しい設定が導入されています。 この変更は、既存の TFVC リポジトリが影響を受けないようにしながら、新しいプロジェクトに焦点を当てています。
さらに、Azure Pipelines では、OIDC トークンを要求するために新しい REST API エンドポイントを使用できるようになったことをお知らせします。 これにより、タスク開発者は Entra ID 認証用の idToken を生成でき、セキュリティと使いやすさが向上します。
最後に、Azure Boards では、領域とイテレーションのパスは、作業項目に関連付けられていない場合にのみ削除できるようになりました。 この改善により、中断が防止され、チームはボードやバックログにアクセスできます。
詳細については、リリース ノートを参照してください。
GitHub Advanced Security for Azure DevOps
Azure Boards:
Azure Repos
Azure Pipelines
- Microsoft Entra ID 認証を使用してパイプラインから Azure Service Bus にアクセスする
- パイプラインとタスクによって変数が設定され、ワークロード ID フェデレーション認証がカスタマイズされます
- サーバー タスクの再試行
- 有効期間終了のノード ランナー バージョンを使用して警告を出力するタスク
- DockerCompose0 では、v1 互換モードで Docker Compose v2 を使用する
Azure Test Plans:
GitHub Advanced Security for Azure DevOps
セキュリティの概要 API ドキュメントが利用可能になりました
[Advanced Security overview risk]\(高度なセキュリティの概要リスク\) タブを強化する API のドキュメントが利用可能になりました。 エンドポイント /{organization}/_apis/reporting/summary/alerts
を使用して、Advanced Security が有効なすべてのリポジトリのアラートの重要度の概要を表示します。 ADO PAT に vso.advsec
アクセス許可があることを確認します。これにより、アラート、結果インスタンス、分析結果インスタンスを読み取る機能が付与されます。
Azure Boards
領域と反復パスを削除するための変更
領域または反復パスを削除すると、中断が発生する可能性があります。 作業項目を新しいパスに移動でき、チームがボードやバックログにアクセスできなくなる可能性があります。 警告やプロンプトにもかかわらず、結果を完全に理解せずにパスが削除されることがあります。 これに対処するために、動作を変更しました:区分パスと反復パスは、作業項目で使用されなくなった場合にのみ削除できるようになりました。
Azure Repos
TFVC リポジトリの作成を無効にする新しい設定
Git が Azure Repos の推奨されるバージョン コントロール システムになったため、近年、Team Foundation バージョン管理 (TFVC) に新機能は追加されていません。 セキュリティ、パフォーマンス、アクセシビリティに関する最近の改善はすべて Git リポジトリにのみ行われ、TFVC の使用が継続的に減少しています。 一部のユーザーはまだ TFVC に依存しており、この機能セットを削除する予定はありませんが、新しいプロジェクトや組織、および現在 TFVC を使用していないプロジェクトについては、TFVC を段階的に廃止する予定です。
この移行の一環として、"TFVC リポジトリの作成を無効にする" という新しい設定が導入されています。これは、新しい TFVC リポジトリの作成にのみ影響し、既存の TFVC リポジトリには影響しません。
Azure Pipelines
Microsoft Entra ID 認証を使用してパイプラインから Azure Service Bus にアクセスする
Microsoft Entra ID 認証を使用して、Azure Pipelines から Azure Service Bus にアクセスできるようになりました。 これにより、ワークロード ID フェデレーションを利用して、きめ細かなアクセス制御のためにシークレット管理と Azure RBAC を削除できます。
Azure Service Bus にアクセスする ID には、アクセスされた Service Bus 上の Azure Service Bus の Azure 組み込みロール のいずれかを付与する必要があります。
PublishToAzureServiceBus@2 タスク
新しいPublishToAzureServiceBus@2 タスクは、Azure サービス接続を使用して構成できます。 Azure サービス接続を作成し新しいタスクの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
実行を使用するカスタム サーバー (エージェントレス) タスクでは、Azure サービス接続をEndpointId
として指定し、ConnectionString
を省略できます。 Server タスクの作成を参照してください。
パイプラインとタスクによって変数が設定され、ワークロード ID フェデレーション認証がカスタマイズされます
OIDC トークンを要求するための REST API エンドポイントが、 System.OidcRequestUri
パイプライン変数で使用できるようになりました。 タスク開発者は、この変数を利用して、Entra ID を使用した認証用の idToken を生成できます。
Marketplace タスクまたはカスタム タスクを使用して Azure にデプロイする場合は、これらのタスクがまだワークロード ID フェデレーションをサポートしていない可能性があることに注意してください。 タスク開発者は、ワークロード ID フェデレーションを有効にしてセキュリティ対策を改善することをお勧めします。
task.jsonでconnectedService:AzureRM
入力を受け取るタスクは、次の手順に従ってワークロード ID フェデレーションをサポートするように更新できます。
- Oidctoken REST API を使用して idToken を要求します (上の図の矢印 1)。
- idToken を
client_assertion
として指定して、OAuth API のフェデレーション資格情報フローを使用して idToken をアクセス トークンと交換します (上の図の矢印 2 & 4)。
または: - 認証自体を実行するツールのラッパーとして機能するタスクの場合は、ツールの認証方法を使用してフェデレーション トークンを指定します。
ノード タスクでは、 azure-pipelines-tasks-artifacts-common npm パッケージを使用して idToken を取得できます。 実装の詳細については、 code の例 を参照してください。
新しい idToken の要求
AzureCLI@2
タスクとAzurePowerShell@5
タスクで公開されているSystem.OidcRequestUri
パイプライン変数とAZURESUBSCRIPTION_SERVICE_CONNECTION_ID
環境変数を使用すると、パイプライン作成者は独自のスクリプトから認証できます。
PowerShell Az
- 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
Azure CLI
- 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_ID
サーバー タスクの再試行
AzureFunction
や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 バージョンに依存するパイプライン タスクは、 が維持されなくなりました 警告の受信が開始されます。
タスク
TaskName
バージョン<version>
は、有効期間が終了した Node バージョン (10) に依存します。 更新されたバージョンのタスクについては、拡張機能の所有者にお問い合わせください。 タスクの保守担当者は、ノードのアップグレード ガイダンスを確認する必要があります。 https://aka.ms/node-runner-guidance
これらの警告を抑制するには、パイプライン (ジョブ) レベルまたはタスク レベルで環境変数またはパイプライン変数を設定します。 次に例を示します。
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false
v1 互換モードで Docker Compose v2 を使用するDockerCompose@0
Docker Compose v1 は有効期間が終了し、2024 年 7 月 24 日にホストされるエージェントから削除されます。 Docker Compose v1 がエージェントで使用できない場合は、v1 互換モードで Docker Compose v2 を使用するように、 DockerCompose@0 タスクを更新しました。
ただし、互換モードはすべての互換性の問題に対応しているわけではありません。 「Compose V2 に移行する」を参照してください。 一部のユーザーは、Docker Compose v2 の互換性のために Docker Compose プロジェクトを更新するためにより多くの時間が必要になります。 このような場合は、次の手順に従って、 DockerComposeV0 タスクを docker-compose v1 で使用します。
Windows で docker-compose v1 を使用する
powershell ステップをパイプラインに追加して、docker-Compose v1.29.2 をダウンロードしDockerComposeV0 タスクと共に使用しますWindows
variables:
dockerComposePath: C:\docker-compose
steps:
- powershell: |
mkdir -f $(dockerComposePath)
# GitHub now requires TLS1.2. In PowerShell, run the following
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: '**/docker-compose.yml'
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)\docker-compose.exe
Linux で docker-compose v1 を使用する
bash ステップをパイプラインに追加して Docker-Compose v1.29.2 をダウンロードし、Linux の DockerComposeV0 タスクで使用します
variables:
dockerComposePath: /tmp/docker-compose
steps:
- bash: |
sudo mkdir $(dockerComposePath)
sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
sudo chmod 755 $(dockerComposePath)/docker-compose
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)/docker-compose
Azure Test Plans
マニフェスト V3 でのテストとフィードバックの拡張機能
Azure DevOps のテストとフィードバック拡張機能の新しい更新プログラムをお知らせします。 このアップグレードにより、マニフェスト V2 の Google の非推奨スケジュールに合わせて、実装がマニフェスト バージョン 2 からバージョン 3 に移行されます。
拡張機能のコア機能は変更されませんが、この更新プログラムによってセキュリティとパフォーマンスが向上します。 更新された拡張機能は、今後数週間にわたって Chrome と Edge の両方のブラウザーに徐々にロールアウトされます。 結果に基づいてロールアウトを拡大する前に、パフォーマンスとフィードバックを監視してスムーズに移行できるようにします。
詳細については、この更新プログラムに関する最近のブログ記事を参照してください。 マニフェスト V3 でのテストとフィードバック拡張機能
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
シルヴィウ アンドリカ