다음을 통해 공유


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 설명서를 사용할 수 있습니다.

이제 고급 보안 개요 위험 탭을 구동하는 API에 대한 설명서를 사용할 수 있습니다. 엔드포인트 /{organization}/_apis/reporting/summary/alerts 를 사용하여 모든 고급 보안 사용 리포지토리에서 경고 중요도 요약을 볼 수 있습니다. ADO PAT에 vso.advsec 경고, 결과 인스턴스 및 분석 결과 인스턴스를 읽을 수 있는 권한을 부여하는 권한이 있는지 확인합니다.

Azure Boards

영역 및 반복 경로 삭제 변경

영역 또는 반복 경로를 삭제하면 중단될 수 있습니다. 작업 항목을 새 경로로 이동할 수 있으며 팀이 보드 및 백로그에 액세스할 수 없게 될 수 있습니다. 경고 및 프롬프트에도 불구하고 결과를 완전히 이해하지 못한 채 경로가 삭제되는 경우가 있습니다. 이 문제를 해결하기 위해 작업 항목에서 더 이상 사용하지 않는 경우에만 영역 및 반복 경로를 삭제할 수 있다는 동작을 변경했습니다.

삭제 영역의 스크린샷

Azure Repos

TFVC 리포지토리 만들기를 사용하지 않도록 설정하는 새 설정

Git이 Azure Repos에서 기본 버전 제어 시스템이 되었기 때문에 최근 몇 년 동안 TFVC(Team Foundation 버전 제어)에 새로운 기능이 추가되지 않았습니다. 보안, 성능 및 접근성의 최근 모든 개선 사항은 Git 리포지토리에만 적용되어 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 작업

Azure 서비스 연결을 사용하여 새 PublishToAzureServiceBus@2 작업을 구성할 수 있습니다. Azure 서비스 연결을 만들고 새 작업의 속성 및 serviceBusNamespace 채우기serviceBusQueueName:

- 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할 수 있습니다. 서버 작업 작성을 참조 하세요.

파이프라인 및 태스크는 변수를 채워 워크로드 ID 페더레이션 인증을 사용자 지정합니다.

이제 파이프라인 변수에서 OIDC 토큰을 요청하기 위한 REST API 엔드포인트를 System.OidcRequestUri 사용할 수 있습니다. 태스크 개발자는 이 변수를 활용하여 Entra ID로 인증할 idToken을 생성할 수 있습니다.

Marketplace 작업 또는 사용자 지정 작업을 사용하여 Azure에 배포하는 경우 이러한 작업은 아직 워크로드 ID 페더레이션을 지원하지 않을 수 있습니다. 작업 개발자는 보안 조치를 개선하기 위해 워크로드 ID 페더레이션을 사용하도록 설정하는 것이 좋습니다.

oidc 공동 작업의 스크린샷.

task.json 입력connectedService:AzureRM 수행하는 작업은 다음 단계를 수행하여 워크로드 ID 페더레이션을 지원하도록 업데이트할 수 있습니다.

  • Oidctoken REST API를 활용하여 idToken(위 다이어그램의 화살표 1)을 요청합니다.
  • idToken을 (위 다이어그램의 화살표 2 및 4)로 client_assertion 지정하여 OAuth API페더레이션 자격 증명 흐름을 사용하여 액세스 토큰에 대한 idToken을 교환합니다.
    또는:
  • 인증 자체를 수행하는 도구 주위의 래퍼 역할을 하는 작업의 경우 도구의 인증 방법을 사용하여 페더레이션된 토큰을 지정합니다.

노드 작업은 azure-pipelines-tasks-artifacts-common npm 패키지를 사용하여 idToken을 가져올 수 있습니다. 구현 세부 정보는 코드 예제를 참조하세요.

새 idToken 요청

System.OidcRequestUri 파이프라인 변수 및 AZURESUBSCRIPTION_SERVICE_CONNECTION_ID 태스크에 노출되는 환경 변수를 AzureCLI@2 AzurePowerShell@5 사용하면 파이프라인 작성자가 자체 스크립트에서 인증할 수 있습니다.

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는 요청을 최대 세 번(초기 시도와 지정된 retryCountOnTaskFailure두 번의 재시도)까지 다시 시도합니다. 각 재시도에는 증가하는 대기 기간이 포함됩니다. 허용되는 최대 재시도 횟수는 10개입니다.

retryCountOnTaskFailure 외부 시스템 호출을 ManualValidation 포함하지 않는 작업 및 기타 작업에는 사용할 수 없습니다.

종료 노드 실행기 버전을 사용하여 경고를 내보내는 작업

노드 버전을 사용하는 파이프라인 작업이 더 이상 유지 관리되지 않으면 경고가 수신되기 시작합니다.

작업 TaskName 버전은 <version> 수명이 종료된 노드 버전(10)에 따라 달라집니다. 업데이트된 버전의 작업에 대해서는 확장 소유자에게 문의하세요. 작업 유지 관리자가 노드 업그레이드 지침을 검토해야 합니다. https://aka.ms/node-runner-guidance

이러한 경고를 표시하지 않으면 파이프라인(작업) 또는 작업 수준에서 환경 또는 파이프라인 변수를 설정할 수 있습니다. 예시:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 v1 호환성 모드에서 Docker Compose v2를 사용합니다.

Docker Compose v1은 수명이 종료되며 2024년 7월 24일 호스티드 에이전트에서 제거됩니다. 에이전트에서 Docker Compose v1을 사용할 수 없는 경우 v1 호환 모드에서 Docker Compose v2를 사용하도록 DockerCompose@0 작업을 업데이트했습니다.

그러나 호환성 모드가 모든 호환성 문제를 해결하는 것은 아닙니다. Compose V2로 마이그레이션을 참조하세요. 일부 사용자는 Docker Compose v2 호환성을 위해 Docker Compose 프로젝트를 업데이트하는 데 더 많은 시간이 필요합니다. 이러한 경우 다음 지침에 따라 Docker-compose v1에서 DockerComposeV0 작업을 사용합니다.

참고: 이 가이드는 Compose 독립 실행형 설치 설명서를 기반으로 합니다.

Windows에서 docker-compose v1 사용

파이프라인에 powershell 단계를 추가하여 docker-Compose v1.29.2를 다운로드하고 WindowsDockerComposeV0 작업과 함께 사용합니다.

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를 다운로드하고 LinuxDockerComposeV0 작업과 함께 사용합니다.

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 테스트 및 피드백 확장에 대한 새로운 업데이트를 발표하게 되어 기쁩니다. 이 업그레이드는 매니페스트 버전 2에서 버전 3으로 구현을 전환하여 매니페스트 V2에 대한 Google의 사용 중단 일정에 맞춥니다.

확장의 핵심 기능은 변경되지 않지만 이 업데이트는 보안 및 성능을 향상시킵니다. 업데이트된 확장은 앞으로 몇 주 동안 Chrome 및 Edge 브라우저에 점진적으로 출시될 예정입니다. 결과에 따라 롤아웃을 확장하기 전에 원활한 전환을 보장하기 위해 성능 및 피드백을 모니터링합니다.

자세한 내용은 이 업데이트에 대한 최근 블로그 게시물을 확인하세요. 매니페스트 V3에서 테스트 및 피드백 확장

다음 단계

참고 항목

이러한 기능은 향후 2~3주 동안 출시될 예정입니다.

Azure DevOps로 이동하여 살펴보세요.

피드백을 제공하는 방법

이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.

제안하기

Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.

감사합니다,

실비우안드리카