다음을 통해 공유

YAML 파이프라인 파일에서 와일드카드 및 조건식 지원

  • 아티클

이 스프린트에서는 YAML 파이프라인 파일에 대한 와일드카드 및 조건식에 대한 지원을 포함했습니다. 또한 Azure Pipelines 호스팅 이미지를 여러 번 업데이트했습니다.

자세한 내용은 다음 기능 설명을 확인하세요.

Azure Pipelines

Azure Repos

Azure Pipelines

새 YAML 조건식

YAML 파일에서 조건식을 작성하면 식을 사용하는 ${{ else }} ${{ elseif }} 것이 더 쉬워졌습니다. 다음은 YAML 파이프라인 파일에서 이러한 식을 사용하는 방법의 예입니다.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

경로 필터에서 와일드카드 지원

와일드카드는 파이프라인 YAML 파일에서 CI 또는 PR 트리거에 대한 포함 및 제외 분기를 지정할 때 사용할 수 있습니다. 그러나 경로 필터를 지정할 때는 사용할 수 없습니다. 예를 들어 일치하는 src/app/**/myapp*모든 경로를 포함할 수는 없습니다. 이것은 몇몇 고객에 의해 불편으로 지적되었습니다. 이 업데이트는 이 간격을 채웁니다. 이제 경로 필터를 지정할 때 와일드카드 문자(***또는?)를 사용할 수 있습니다.

Bitbucket의 여러 상태 지원

Azure Pipelines는 Bitbucket 리포지토리와 통합되고 CI 및 PR 트리거를 지원합니다. 단일 Bitbucket 리포지토리에서 여러 파이프라인을 설정할 수 있습니다. 그러나 이러한 파이프라인이 완료되면 Bitbucket에서 하나의 상태만 볼 수 있었습니다. Bitbucket에서 각 파이프라인의 상태를 개별적으로 보도록 요청하는 개발자 커뮤니티 의 피드백을 들었습니다. 이 업데이트를 통해 Bitbucket에 대한 API 호출을 업데이트하고 파이프라인 이름에 대한 추가 정보를 전달했습니다.

빌드 상태

기여가 빌드 유효성 검사 전에 PR 주석 검색을 건너뛸 수 있도록 허용

GitHub 리포지토리에서 Azure Pipelines를 사용하는 경우 포크된 리포 지토리에서 받은 기여에 대해 PR 유효성 검사 파이프라인을 자동으로 실행하지 않는 것이 좋습니다 . 여기서 모범 사례는 먼저 리포지토리의 협력자 중 한 명이 변경 사항을 검토한 다음 PR에 주석을 추가하여 파이프라인을 트리거하도록 하는 것입니다. 파이프라인 웹 편집기에서 트리거 메뉴(YAML 파이프라인의 경우) 또는 트리거 탭(클래식 빌드 파이프라인의 경우)을 선택하여 이러한 설정을 구성할 수 있습니다. 포크의 모든 PR을 팀 구성원이 먼저 검토하도록 요구하는 대신, 팀 구성원이 아닌 멤버로부터 시작된 기여에 대해서만 이 정책을 적용할 수 있습니다.

이 업데이트를 사용하면 참가자가 받은 기여에서 PR 주석 검색을 건너뛸 수 있습니다. 비팀 멤버로서 포크를 만들고 업스트림에 PR을 만들 때 PR이 병합될 때까지 업스트림 리포지토리의 기여자로 간주되지 않습니다. PR이 병합되면 참가자로 간주됩니다. 아래에 표시된 새 옵션을 선택하면 팀 구성원이 아닌 구성원이 처음으로 포크에서 PR을 제출하면 팀의 누군가가 PR을 검토하고 주석을 추가하여 파이프라인을 트리거해야 합니다. 그러나 PR이 병합되면 해당 팀 구성원이 추가 기여한 내용은 PR 주석을 기다리지 않고 파이프라인을 직접 트리거합니다.

끌어오기 요청을 작성하기 전에 팀 구성원의 설명 필요

이제 Microsoft 호스팅 에이전트에서 Windows Server 2022와 Visual Studio 2022 사용 가능(미리 보기)

Windows Server 2022 및 Visual Studio Enterprise 2022 미리 보기 는 이제 Microsoft 호스팅 에이전트에서 미리 보기로 제공됩니다. 파이프라인에서 이미지로 참조하여 windows-2022 사용할 수 있습니다.

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

YAML 파이프라인에서 Windows-Latest 풀을 참조하는 경우 Windows-2022가 아닌 windows-2019를 의미하며, 후자는 미리 보기로 제공됩니다.

Windows Server 2022 파이프라인 이미지에는 Windows Server 2019와 비교할 때 다양한 도구 및 도구 버전이 있습니다. 소프트웨어 공지 문제 및 설명서 가상 환경 리포지토리에서 세부 정보를 볼 수 있습니다.

Microsoft 호스팅 에이전트에서 macOS 11의 일반 공급

macOS 11은 이제 Microsoft 호스팅 에이전트에서 일반 공급됩니다. 파이프라인에서 이미지로 참조하여 macos-11 사용할 수 있습니다.

pool:
  vmImage: macos-11

Microsoft 호스팅 에이전트에서 Ubuntu 16.04 이미지 제거

앞에서 발표한 대로 2021년 9월 20일에 Microsoft 호스팅 에이전트에서 Ubuntu 16.04 이미지를 제거할 예정입니다. Canonical에 의한 Ubuntu 16.04의 전통적인 5년 지원은 2021년 4월에 종료되었습니다. Ubuntu-16.04 파이프라인을 Ubuntu 20.04 LTS에서 실행되는 ubuntu-18.04 또는 ubuntu-latest로 마이그레이션해야 합니다.

Ubuntu-16.04를 사용하는 빌드에는 이미 경고가 로그인되어 있습니다. 모든 사용자가 이 변경 사항을 인식할 수 있도록 짧은 2개의 "브라운아웃"을 예약했습니다. Ubuntu 16.04 빌드는 브라운아웃 기간 동안 실패합니다. 따라서 2021년 9월 6일 이전에 워크플로를 마이그레이션하는 것이 좋습니다.

브라운아웃은 다음 날짜 및 시간에 대해 예약됩니다(이전 발표된 시간부터 1시간 연장됨): 2021년 9월 6일 오후 4:00PM UTC – 2021년 9월 14일 오후 4:00pm UTC – 10:00pm UTC

Azure Repos

새 TFVC 페이지가 일반 공급됨

다양한 서비스에서 환경을 보다 일관되고 접근성 있게 만들기 위해 새 웹 플랫폼을 사용하도록 Azure DevOps의 다양한 페이지를 업데이트하고 있습니다. TFVC 페이지는 새 웹 플랫폼을 사용하도록 업데이트되었으며, 이러한 변경 내용은 몇 달 동안 미리 보기로 제공됩니다. 이 업데이트를 통해 새 TFVC 페이지를 일반 공급하게 되었습니다. 이 업데이트를 사용하면 사용자 설정에 "새 TFVC 페이지"라는 미리 보기 기능이 더 이상 표시되지 않습니다.

분기에 대한 “관리 권한”을 갖지 않도록 분기 작성자 구성

새 분기를 만들 때 해당 분기에 대해 "권한 관리"가 표시됩니다. 이 권한을 사용하면 다른 사용자의 사용 권한을 변경하거나 해당 분기에 기여할 추가 사용자를 허용할 수 있습니다. 예를 들어 분기 작성자는 이 권한을 사용하여 다른 외부 사용자가 코드를 변경할 수 있도록 할 수 있습니다. 또는 파이프라인(빌드 서비스 ID)이 해당 분기의 코드를 변경하도록 허용할 수 있습니다. 규정 준수 요구 사항이 높은 특정 조직에서는 사용자가 이러한 변경을 수행할 수 없습니다.

이 업데이트를 사용하면 팀 프로젝트의 모든 리포지토리와 모든 리포지토리를 구성하고 분기 작성자가 "권한 관리" 권한을 얻지 못하도록 제한할 수 있습니다. 이렇게 하려면 프로젝트 설정으로 이동하고, 리포지토리를 선택한 다음, 모든 리포지토리 또는 특정 리포지토리에 대한 설정을 선택합니다.

모든 리포지토리 설정

이 설정은 기본적으로 기존 동작을 모방하도록 설정됩니다. 그러나 이 새로운 보안 기능을 사용하려는 경우 해제할 수 있습니다.

포크 사용자가 해당 업스트림 PR에 투표하지 못하도록 방지

Azure Repos를 사용하면 리포지토리에 대한 "읽기" 권한이 있는 사용자는 리포지토리를 포크하고 포크를 변경할 수 있습니다. 업스트림에 대한 변경 내용이 포함된 끌어오기 요청을 제출하려면 사용자는 업스트림에 대한 "끌어오기 요청에 기여" 권한이 필요합니다. 그러나 이 권한은 업스트림 리포지토리에서 끌어오기 요청에 투표할 수 있는 사용자도 제어합니다. 결과적으로 리포지토리에 기여하지 않는 사용자가 끌어오기 요청을 제출하고 분기 정책을 설정하는 방법에 따라 병합될 수 있는 상황이 발생할 수 있습니다.

내부 원본 모델을 홍보하는 조직에서 포크 및 기여는 일반적인 패턴입니다. 이 패턴을 더 안전하게 보호하고 승격하기 위해 끌어오기 요청에 대한 투표 권한을 "끌어오기 요청에 기여"에서 "기여"로 변경하고 있습니다. 그러나 이 변경은 기본적으로 모든 조직에서 수행되지 않습니다. 이 권한을 전환하려면 리포지토리에서 "엄격한 투표 모드"라는 새 정책을 옵트인하고 선택해야 합니다. Azure Repos에서 포크를 사용하는 경우 이 작업을 수행하는 것이 좋습니다.

리포지토리 설정

다음 단계

참고 항목

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

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

Azure DevOps로 이동

피드백을 제공하는 방법

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

제안하기

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

감사합니다,

아론 할버그