TFVC リポジトリの作成を無効にする設定

この更新プログラムでは、TFVC リポジトリの作成を無効にする新しい設定が導入されています。 この変更は、既存の TFVC リポジトリが影響を受けないようにしながら、新しいプロジェクトに焦点を当てています。

さらに、Azure Pipelines では、OIDC トークンを要求するために新しい REST API エンドポイントを使用できるようになったことをお知らせします。 これにより、タスク開発者は Entra ID 認証用の idToken を生成でき、セキュリティと使いやすさが向上します。

最後に、Azure Boards では、領域とイテレーションのパスは、作業項目に関連付けられていない場合にのみ削除できるようになりました。 この改善により、中断が防止され、チームはボードやバックログにアクセスできます。

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

Azure DevOps 用の GitHub Advanced Security

Azure Boards:

Azure Repos

Azure Pipelines

Azure Test Plans:

Azure DevOps 用の GitHub Advanced Security

セキュリティの概要 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 リポジトリには影響しません。

GIF を使用して 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 フェデレーションを有効にしてセキュリティ対策を改善することをお勧めします。

oidc コラボレーションのスクリーンショット。

task.jsonconnectedService: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

サーバー タスクの再試行

AzureFunctionInvokeRESTAPIなど、外部システムを呼び出すサーバー タスクは、コンピューティング リソースの枯渇などの一時的なエラーが原因で失敗することがあります。 以前は、このようなエラーが発生すると、ジョブ全体、およびパイプラインが失敗する可能性があります。

一時的なエラーに対する回復性を向上させるために、サーバー タスクの 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 タスクを更新しました。

ただし、互換性モードはすべての互換性の問題に対処するわけではありません。 「 Migrate to Compose V2を参照してください。 一部のユーザーは、Docker Compose v2 の互換性のために Docker Compose プロジェクトを更新するためにより多くの時間が必要になります。 このような場合は、次の手順に従って、 DockerComposeV0 タスクを docker-compose v1 で使用します。

: このガイドは、Install Compose スタンドアロンに関するドキュメントに基づいています

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 のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

シルヴィウ アンドリカ