YAML에서 리소스 정의

  • 아티클

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

YAML의 리소스는 파이프라인, 빌드, 리포지토리, 컨테이너, 패키지 및 웹후크의 원본을 나타냅니다. 또한 리소스는 버전, 아티팩트, 연결된 커밋 및 작업 항목을 포함하여 파이프라인에 사용되는 서비스의 전체 추적 기능을 제공합니다. 리소스를 정의하면 파이프라인 어디에서나 사용할 수 있습니다. 또한 리소스에서 이벤트를 트리거하도록 구독하여 DevOps 워크플로를 완전히 자동화할 수 있습니다.

자세한 내용은 리소스 및 리소스 YAML 스키마 정의를 참조하세요.

스키마

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

variables

리소스가 파이프라인을 트리거하면 다음 변수가 설정됩니다.

resources.triggeringAlias
resources.triggeringCategory

리소스가 파이프라인 실행을 트리거하지 않는 경우 이러한 값은 비어 있습니다. 이러한 값을 설정하려면 변수 Build.Reason 여야 ResourceTrigger 합니다.

pipelines 리소스 정의

아티팩트를 생성하는 파이프라인이 있는 경우 리소스를 정의하여 아티팩트를 pipelines 사용할 수 있습니다. pipelines 는 Azure Pipelines 전용 리소스입니다. CD 워크플로에 대한 파이프라인 리소스에 트리거를 설정할 수도 있습니다.

리소스 정의 pipeline 에서 나중에 파이프라인 리소스를 참조하는 데 사용할 수 있는 고유한 값입니다. source 는 아티팩트를 생성하는 파이프라인의 이름입니다. 파이프라인 리소스 변수를 사용하거나 아티팩트 다운로드하는 경우와 같이 정의된 레이블 pipeline 을 사용하여 파이프라인의 다른 부분에서 파이프라인 리소스를 참조합니다.

파이프라인을 다운로드하는 다른 방법은 파이프라인 아티팩트에서 작업을 참조하세요.

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
    version: string  # the pipeline run number (Build.BuildNumber) to pick the artifact, defaults to latest pipeline successful run across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider for the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

Important

리소스 트리거를 정의할 때 파이프라인 리소스가 현재 파이프라인과 동일한 리포지토리(즉, 자체)에 있는 경우 트리거는 동일한 분기를 따르고 이벤트가 발생하는 커밋을 수행합니다. 그러나 파이프라인 리소스가 다른 리포지토리에서 온 경우 현재 파이프라인은 자체 리포지토리의 기본 분기 트리거됩니다.

아티팩트 버전 평가

리소스 파이프라인 아티팩트의 버전은 파이프라인이 트리거되는 방식에 따라 달라집니다.

파이프라인을 수동으로 트리거했거나 예약된 실행으로 인해 파이프라인이 실행되는 경우 아티팩트 버전의 버전은 , branch및 tags 속성의 version값에 의해 정의됩니다.

지정된 속성 아티팩트 버전
version 지정된 실행 번호가 있는 빌드의 아티팩트
branch 지정된 분기에서 수행된 최신 빌드의 아티팩트
tags 목록 지정된 태그가 모두 있는 최신 빌드의 아티팩트
branch 및 tags 목록 지정된 분기 에서 수행되고 지정된 모든 태그가 있는 최신 빌드의 아티팩트
None 모든 분기에서 최신 빌드의 아티팩트

예를 살펴보겠습니다. 파이프라인에 다음 리소스 정의가 포함되어 있다고 가정합니다.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main      ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
    tags:               ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
    - Production        ### Tags are AND'ed
    - PreProduction

파이프라인을 실행하도록 수동으로 트리거하는 경우 파이프라인 아티팩트 MyCIAlias 버전은 분기에서 main 수행된 최신 빌드 중 하나이며 해당 빌드에는 Production 태그가 PrepProduction 있습니다.

리소스 파이프라인 중 하나가 완료되어 파이프라인이 트리거되면 아티팩트 버전은 트리거 파이프라인 중 하나입니다. 및 branchtags 속성의 version값은 무시됩니다.

지정된 트리거 결과
branches 리소스 파이프라인이 분기에서 실행을 성공적으로 완료할 때마다 현재 파이프라인의 새 실행이 include 트리거됩니다.
tags 현재 파이프라인의 새 실행은 리소스 파이프라인이 지정된 모든 태그로 태그가 지정된 실행을 성공적으로 완료할 때마다 트리거됩니다.
stages 현재 파이프라인의 새 실행은 리소스 파이프라인이 지정된 파이프라인을 성공적으로 실행할 때마다 트리거됩니다. stages
branches, tags 및 stages 리소스 파이프라인 실행이 모든 분기, 태그 및 스테이지 조건을 충족할 때마다 현재 파이프라인의 새 실행이 트리거됩니다.
trigger: true 현재 파이프라인의 새 실행은 리소스 파이프라인이 실행을 성공적으로 완료할 때마다 트리거됩니다.
없음 리소스 파이프라인이 실행을 성공적으로 완료하면 현재 파이프라인의 새 실행이 트리거되지 않습니다.

예를 살펴보겠습니다. 파이프라인에 다음 리소스 정의가 포함되어 있다고 가정합니다.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

파이프라인이 분기 중 하나 또는 main 분기에서 실행될 때마다 SmartHotel-CI 파이프라인이 실행되고, 태그가 둘 다 Verified 로 지정되고Signed, 단계와 PreProduction 단계가 모두 Production 완료됩니다.releases

download 파이프라인용

현재 파이프라인 및 모든 리소스의 모든 pipeline 아티팩트가 자동으로 다운로드되고 각 deployment 작업의 시작 부분에서 사용할 수 있게 됩니다. 이 동작을 재정의할 수 있습니다. 자세한 내용은 파이프라인 아티팩트(Pipeline Artifacts)를 참조 하세요. 일반 '작업' 아티팩트가 자동으로 다운로드되지 않습니다. 필요한 경우 명시적으로 사용합니다 download .

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional

리소스의 아티팩트가 pipeline 폴더에 $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> 다운로드됩니다.

파이프라인 리소스 변수

각 실행에서 파이프라인 리소스에 대한 메타데이터는 미리 정의된 변수의 형태로 모든 작업에 사용할 수 있습니다. 파이프라인 <Alias> 리소스에 대해 제공한 식별자입니다. 파이프라인 리소스 변수는 런타임에만 사용할 수 있습니다.

변수 구문에 대한 자세한 내용은 변수 정의를 참조 하세요.

resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

자세한 내용은 파이프라인 리소스 메타데이터를 미리 정의된 변수로 참조 하세요.

builds 리소스 정의

아티팩트를 생성하는 외부 CI 빌드 시스템이 있는 경우 리소스와 함께 아티팩트를 builds 사용할 수 있습니다. 리소스는 builds Jenkins, TeamCity, CircleCI 등과 같은 외부 CI 시스템일 수 있습니다.

resources:        # types: pipelines | builds | repositories | containers | packages
  builds:
  - build: string   # identifier for the build resource
    type: string   # the type of your build service like Jenkins, circleCI etc.
    connection: string   # service connection for your build service.
    source: string   # source definition of the build
    version: string   # the build number to pick the artifact, defaults to Latest successful build
    trigger: boolean    # Triggers aren't enabled by default and should be explicitly set

builds 는 확장 가능한 범주입니다. 확장을 작성하여 빌드 서비스의 아티팩트를 사용하고 새 유형의 서비스를 도입할 builds수 있습니다. Jenkins는 .의 리소스 유형입니다 builds.

Important

트리거는 Azure DevOps에서 Jenkins 서버와 시야를 가진 호스티드 Jenkins에 대해서만 지원됩니다.

downloadBuild 빌드 작업

작업을 사용하여 작업의 일부로 리소스의 아티팩 build 트를 downloadBuild 사용할 수 있습니다. 정의된 리소스 유형 build 에 따라 이 작업은 런타임 동안 서비스에 대한 해당 다운로드 태스크로 자동으로 확인됩니다.

리소스의 아티팩트가 build 폴더에 $(PIPELINE.WORKSPACE)/<build-identifier>/ 다운로드됩니다.

Important

build 리소스 아티팩트가 작업/배포 작업에서 자동으로 다운로드되지 않습니다. 아티팩트 사용 작업을 명시적으로 추가 downloadBuild 해야 합니다.

- downloadBuild: string # identifier for the resource from which to download artifacts
  artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
  patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded

repositories 리소스 정의

파이프라인에 다른 리포지토리에 템플릿이 있거나 서비스 연결이 필요한 리포지토리에서 다중 리포지토리 검사out을 사용하려는 경우 해당 리포지토리에 대해 시스템에 알려야 합니다. repository 키워드(keyword) 외부 리포지토리를 지정할 수 있습니다.

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

Type

파이프라인은 리포지토리 형식gitgithubgithubenterprisebitbucket에 대해 다음 값을 지원합니다. 이 형식은 git Azure Repos Git 리포지토리를 참조합니다.

지정된 형식 결과 예시
type: git 값은 name 동일한 프로젝트의 다른 리포지토리를 참조합니다. name: otherRepo 동일한 조직 내의 다른 프로젝트의 리포지토리를 참조하려면 해당 프로젝트의 이름을 접두사로 지정합니다. 예제는 name: OtherProject/otherRepo입니다.
type: github 이 값은 name GitHub 리포지토리의 전체 이름이며 사용자 또는 조직을 포함합니다. name: Microsoft/vscode
type: githubenterprise 값 name 은 GitHub Enterprise 리포지토리의 전체 이름이며 사용자 또는 조직을 포함합니다. name: Microsoft/vscode
type: bitbucket 값은 name Bitbucket Cloud 리포지토리의 전체 이름이며 사용자 또는 조직을 포함합니다. name: MyBitbucket/vscode

GitHub Enterprise 리포지토리는 권한 부여를 위해 GitHub Enterprise 서비스 연결 이 필요합니다.

Bitbucket Cloud 리포지토리는 권한 부여를 위해 Bitbucket Cloud 서비스 연결 이 필요합니다.

variables

각 실행에서 리포지토리 리소스에 대한 메타데이터는 런타임 변수 형식의 모든 작업에 사용할 수 있습니다. 리 <Alias> 포지토리 리소스에 대해 제공한 식별자입니다.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

variables

각 실행에서 리포지토리 리소스에 대한 메타데이터는 런타임 변수 형식의 모든 작업에 사용할 수 있습니다. 리 <Alias> 포지토리 리소스에 대해 제공한 식별자입니다.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

리포지토리를 사용하는 데 사용 checkout

키워드(keyword) 사용하여 리소스의 일부로 정의된 리포지토리를 repository 사용합니다 checkout .

스키마

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

리소스의 repository 리포지토리는 작업에서 자동으로 동기화되지 않습니다. 작업의 일부로 리포지토리를 가져오는 데 사용합니다 checkout .

자세한 내용은 파이프라인에서 여러 리포지토리를 확인하세요.

containers 리소스 정의

CI/CD(지속적인 통합/지속적인 업데이트) 파이프라인의 일부로 컨테이너 이미지를 사용해야 하는 경우 다음을 사용하여 containers구현할 수 있습니다. 컨테이너 리소스는 퍼블릭 또는 프라이빗 Docker 레지스트리 또는 Azure Container Registry일 수 있습니다.

Docker 레지스트리의 이미지를 파이프라인의 일부로 사용해야 하는 경우 일반 컨테이너 리소스를 정의할 수 있습니다(키워드(keyword) 필요 없음 type ).

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory

제네릭 컨테이너 리소스를 작업의 일부로 사용되는 이미지로 사용하거나 컨테이너 작업에 사용할 수도 있습니다. 파이프라인에 하나 이상의 서비스를 지원해야 하는 경우 서비스 컨테이너를 만들고 연결할 수 있습니다. 볼륨을 사용하여 서비스 간에 데이터를 공유할 수 있습니다.

ACR(Azure Container Registry)에 대한 첫 번째 클래스 컨테이너 리소스 유형을 사용하여 ACR 이미지를 사용할 수 있습니다. 이 리소스 유형은 작업의 일부로 사용할 수 있으며 자동 파이프라인 트리거를 사용하도록 설정할 수도 있습니다. 자동 파이프라인 트리거를 사용하려면 ACR에 대한 기여자 또는 소유자 권한이 있어야 합니다. 자세한 내용은 Azure Container Registry 역할 및 권한을 참조하세요.

resources:          # types: pipelines | repositories | containers | builds | packages
  containers:
  - container: string # identifier for the container resource      
    type: string # type of the registry like ACR, GCR etc. 
    azureSubscription: string # Azure subscription (ARM service connection) for container registry;
    resourceGroup: string # resource group for your ACR
    registry: string # registry for container images
    repository: string # name of the container image repository in ACR
    trigger: # Triggers aren't enabled by default and need to be set explicitly
      enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
      tags:
        include: [ string ]  # image tags to consider the trigger events, optional; defaults to any new tag
        exclude: [ string ]  # image tags on discard the trigger events, optional; defaults to none

참고 항목

모든 이미지 태그(enabled: 'true')에 컨테이너 트리거를 사용하도록 설정하는 데 사용되는 구문은 다른 리소스 트리거에 사용되는 구문과 다릅니다. 특정 리소스에 올바른 구문을 사용하려면 주의해야 합니다.

참고 항목

워크로드 ID 페더레이션을 사용하는 서비스 연결은 .에서 azureSubscription지원되지 않습니다.

컨테이너 리소스 변수

컨테이너를 리소스로 정의하면 컨테이너 이미지 메타데이터가 변수 형식으로 파이프라인에 전달됩니다. 이미지, 레지스트리 및 연결 세부 정보와 같은 정보는 컨테이너 배포 태스크에서 사용할 모든 작업에서 액세스할 수 있습니다.

컨테이너 리소스 변수는 Docker 및 Azure Container Registry에서 작동합니다. 로컬 이미지 컨테이너에는 컨테이너 리소스 변수를 사용할 수 없습니다.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

위치 변수는 컨테이너 리소스 유형에 ACR 만 적용됩니다.

packages 리소스 정의

YAML 파이프라인에서 NuGet 및 npm GitHub 패키지를 리소스로 사용할 수 있습니다.

리소스를 package 지정할 때 패키지를 NuGet 또는 npm으로 설정합니다. 새 패키지 버전이 릴리스될 때 자동화된 파이프라인 트리거를 사용하도록 설정할 수도 있습니다.

GitHub 패키지를 사용하려면 PAT(개인 액세스 토큰) 기반 인증을 사용하고 PAT를 사용하는 GitHub 서비스 연결을 만듭니다.

기본적으로 패키지는 작업에 자동으로 다운로드되지 않습니다. 다운로드하려면 .를 사용합니다 getPackage.

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # GitHub service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

webhooks 리소스 정의

참고 항목

웹후크는 Azure DevOps Server 2020.1에서 릴리스되었습니다.

다른 리소스(예: 파이프라인, 컨테이너, 빌드 및 패키지)를 사용하면 아티팩트 사용 및 자동화된 트리거를 사용할 수 있습니다. 그러나 다른 외부 이벤트 또는 서비스에 따라 배포 프로세스를 자동화할 수는 없습니다. 리소스 webhooks 를 사용하면 파이프라인을 외부 서비스와 통합하고 워크플로를 자동화할 수 있습니다. 웹후크(GitHub, GitHub Enterprise, Nexus, Artifactory 등)를 통해 외부 이벤트를 구독하고 파이프라인을 트리거할 수 있습니다.

웹후크 트리거를 구성하려면 다음 단계를 수행합니다.

  1. 외부 서비스에 웹후크를 설정합니다. 웹후크를 만들 때 다음 정보를 제공해야 합니다.

    • 요청 URL

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview

    • 비밀 - 선택 사항입니다. JSON 페이로드를 보호해야 하는 경우 비밀 값을 제공합니다.

  2. 새 "들어오는 웹후크" 서비스 연결을 만듭니다. 이 연결은 다음과 같은 중요한 정보를 정의할 수 있는 새로 도입된 서비스 연결 유형입니다.

    • 웹후크 이름: 웹후크의 이름은 외부 서비스에서 만든 웹후크와 일치해야 합니다.
    • HTTP 헤더 - 요청 확인을 위한 페이로드의 HMAC-SHA1 해시 값을 포함하는 요청의 HTTP 헤더 이름입니다. 예를 들어 GitHub의 경우 요청 헤더는 "X-Hub-Signature"입니다.
    • 비밀 - 비밀은 들어오는 요청을 확인하는 데 사용되는 페이로드의 HMAC-SHA1 해시를 확인하는 데 사용됩니다(선택 사항). 웹후크를 만들 때 비밀을 사용한 경우 동일한 비밀 키를 제공해야 합니다.

    들어오는 웹후크 서비스 연결

  3. YAML 파이프라인에 호출 webhooks 된 새 리소스 종류가 도입되었습니다. 웹후크 이벤트를 구독하려면 파이프라인에서 웹후크 리소스를 정의하고 들어오는 웹후크 서비스 연결을 가리킵니다. JSON 페이로드 데이터를 기반으로 웹후크 리소스에 대한 더 많은 필터를 정의하여 각 파이프라인에 대한 트리거를 사용자 지정할 수도 있습니다. 작업에서 변수 형식으로 페이로드 데이터를 사용합니다.

  4. 들어오는 웹후크 서비스 연결이 웹후크 이벤트를 받을 때마다 웹후크 이벤트를 구독하는 모든 파이프라인에 대해 새 실행이 트리거됩니다. 형식을 사용하여 작업에서 JSON 페이로드 데이터를 사용할 수 있습니다. ${{ parameters.<WebhookAlias>.<JSONPath>}}

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias           ### Webhook alias
      connection: IncomingWebhookConnection    ### Incoming webhook service connection
      filters:                                 ### List of JSON parameters to filter; Parameters are AND'ed
        - path: JSONParameterPath              ### JSON path in the payload
          value: JSONParameterExpectedValue    ### Expected value in the path provided

웹후크는 파이프라인, 빌드, 컨테이너 및 패키지와 같은 일류 리소스에서 지원되지 않는 외부 웹후크 이벤트를 기반으로 워크플로를 자동화합니다. 또한 Azure DevOps에서 프로세스에 대한 가시성이 없는 온-프레미스 서비스의 경우 서비스에서 웹후크를 구성하고 파이프라인을 자동으로 트리거할 수 있습니다.

만들기 실행 대화 상자의 리소스에 대한 수동 버전 선택기

CD YAML 파이프라인을 수동으로 트리거하는 경우 제공된 입력에 따라 파이프라인에 정의된 리소스의 기본 버전을 자동으로 평가합니다. 그러나 실행을 만들 때 리소스 버전 선택기에서 다른 버전을 선택하도록 선택할 수 있습니다.

  1. 실행 창 만들기에서 리소스를 선택합니다. 이 파이프라인에서 사용되는 리소스 목록이 표시됩니다.

  2. 리소스를 선택하고 사용 가능한 버전 목록에서 특정 버전을 선택합니다. 리소스 버전 선택기는 파이프라인, 빌드, 리포지토리, 컨테이너 및 패키지 리소스에 대해 지원됩니다.

    파이프라인 버전 선택기

파이프라인 리소스의 경우 모든 분기에서 사용 가능한 모든 실행을 볼 수 있습니다. 파이프라인 번호 또는 분기에 따라 검색합니다. 또한 성공, 실패 또는 진행 중인 실행을 선택합니다. 이러한 유연성을 통해 필요한 모든 아티팩트가 생성되었다고 확신하는 경우 CD 파이프라인을 실행할 수 있습니다. CI 실행의 관련 없는 단계 오류로 인해 CI 실행이 완료되거나 다시 실행될 때까지 기다릴 필요가 없습니다. 그러나 예약된 트리거에 대한 기본 버전을 평가하거나 수동 버전 선택기를 사용하지 않는 경우에만 성공적으로 완료된 CI 실행을 고려합니다.

GitHub 패키지와 같이 사용 가능한 버전을 가져올 수 없는 리소스의 경우 선택할 실행 버전을 제공할 수 있도록 텍스트 상자를 버전 선택기의 일부로 표시합니다.

YAML 파이프라인 권한 부여

리소스를 사용하려면 먼저 권한을 부여해야 합니다. 리소스 소유자는 해당 리소스에 액세스할 수 있는 사용자 및 파이프라인을 제어합니다. 파이프라인은 리소스를 사용할 수 있는 권한을 부여받아야 합니다. YAML 파이프라인에 권한을 부여할 수 있는 다음 방법을 참조하세요.

  • 리소스의 관리 환경으로 이동합니다. 예를 들어 변수 그룹 및 보안 파일은 파이프라인 아래의 라이브러리 페이지에서 관리됩니다. 에이전트 풀 및 서비스 연결은 프로젝트 설정에서 관리됩니다. 여기에서 모든 파이프라인에 해당 리소스에 액세스하도록 권한을 부여할 수 있습니다. 이 권한 부여는 리소스(예: 테스트 리소스)에 대한 액세스를 제한할 필요가 없는 경우에 편리합니다.

  • 파이프라인을 처음으로 만들 때 YAML 파일에서 참조되는 모든 리소스는 해당 리소스에 대한 사용자 역할의 멤버인 경우 파이프라인에서 사용할 수 있는 권한이 자동으로 부여됩니다. 따라서 파이프라인을 만들 때 YAML 파일에서 참조되는 리소스는 자동으로 권한이 부여됩니다.

  • YAML 파일을 변경하고 리소스를 추가하면 다음 오류와 유사한 오류와 함께 빌드가 실패합니다. Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    이 경우 실패한 빌드에서 리소스에 권한을 부여하는 옵션이 표시됩니다. 리소스에 대한 사용자 역할의 멤버인 경우 이 옵션을 선택할 수 있습니다. 리소스에 권한이 부여되면 새 빌드를 시작할 수 있습니다.

  • 프로젝트의 에이전트 풀 보안 역할이 올바른지 확인합니다.

리소스에 대한 승인 검사 설정

승인 검사 및 템플릿을 사용하여 리소스가 실행되는 시기를 수동으로 제어할 수 있습니다. 필요한 템플릿 승인 검사 리소스 또는 환경을 사용하는 파이프라인도 특정 YAML 템플릿에서 확장하도록 요구할 수 있습니다. 필요한 템플릿 승인을 설정하여 보안을 강화합니다. 템플릿을 사용하는 특정 조건에서만 리소스가 사용되는지 확인합니다. 템플릿 및 리소스를 사용하여 파이프라인 보안을 강화하는 방법에 대해 자세히 알아봅니다.

추적 가능성

파이프라인 또는 배포 작업 수준에서 사용되는 모든 리소스에 대한 전체 추적 기능을 제공합니다.

파이프라인 추적 가능성

모든 파이프라인 실행에 대해 다음 정보를 표시합니다.

  • 파이프라인이 리소스에 의해 트리거된 경우 파이프라인을 트리거한 리소스입니다.

    파이프라인의 리소스 트리거

  • 사용된 리소스 및 아티팩트 버전입니다.

    파이프라인 실행에서 사용된 아티팩트

  • 각 리소스와 연결된 커밋입니다.

    파이프라인 실행에서 커밋

  • 각 리소스와 연결된 작업 항목입니다.

환경 추적 가능성

파이프라인이 환경에 배포될 때마다 사용된 리소스 목록을 볼 수 있습니다. 다음 보기에는 배포 작업의 일부로 사용되는 리소스와 연결된 커밋 및 작업 항목이 포함됩니다.

환경에서 커밋

CI 파이프라인에 연결된 CD 파이프라인 정보 표시

엔드 투 엔드 추적 기능을 제공하기 위해 제공 CI 파이프라인을 사용하는 CD 파이프라인을 추적할 수 있습니다. 리소스를 통해 pipeline CI 파이프라인 실행이 사용되는 CD YAML 파이프라인 실행 목록을 볼 수 있습니다. 다른 파이프라인에서 CI 파이프라인을 사용하는 경우 실행 보기에 "연결된 파이프라인" 탭이 표시됩니다. 여기에서 파이프라인 및 아티팩트에서 사용하는 모든 파이프라인 실행을 찾을 수 있습니다.

CI 파이프라인의 CD 파이프라인 정보

YAML 리소스 트리거 문제 지원 및 추적 가능성

파이프라인 트리거가 실행되지 않을 때 혼동될 수 있습니다. 트리거가 실행되지 않는 이유를 알아볼 수 있는 트리거 문제라는 새 메뉴 항목을 파이프라인 정의 페이지에 추가했습니다. 이 페이지에 액세스하려면 파이프라인 기록을 엽니다. 트리거 문제는 리포지토리가 아닌 리소스에만 사용할 수 있습니다.

탐색에서 트리거 문제를 선택합니다.

리소스 트리거는 다음과 같은 이유로 실행되지 못할 수 있습니다.

  • 제공된 서비스 연결의 원본이 잘못되었거나 트리거에 구문 오류가 있는 경우 트리거가 구성되지 않아 오류가 발생합니다.

  • 트리거 조건이 일치하지 않으면 트리거가 실행되지 않습니다. 조건이 일치하지 않는 이유를 이해할 수 있도록 경고가 표시됩니다.

    트리거 문제 지원 가능성

다음 단계

변수 그룹 추가 및 사용

FAQ

바로 가기 대신 download 파이프라인을 resources 사용해야 하는 이유는 무엇인가요?

리소스를 pipelines 사용하는 것은 CI 파이프라인에서 아티팩트를 사용하고 자동화된 트리거를 구성하는 방법입니다. 리소스를 사용하면 사용된 버전, 아티팩트, 커밋 및 작업 항목을 표시하여 프로세스에 대한 모든 가시성을 제공합니다. 파이프라인 리소스를 정의하면 연결된 아티팩트가 배포 작업에서 자동으로 다운로드됩니다.

빌드 작업에서 아티팩트 다운로드를 선택하거나 배포 작업에서 다운로드 동작을 재정의하도록 선택할 수 있습니다 download. 자세한 내용은 steps.download를 참조 하세요.

파이프라인 아티팩트 다운로드 작업 대신 사용해야 resources 하는 이유는 무엇인가요?

파이프라인 아티팩트 다운로드 작업을 직접 사용하면 추적 가능성 및 트리거가 누락됩니다. 파이프라인 아티팩트 다운로드 작업을 직접 사용하는 것이 좋습니다. 예를 들어 스크립트 태스크가 다른 템플릿에 저장되어 있을 수 있으며 스크립트 태스크를 다운로드하려면 빌드의 아티팩트가 필요합니다. 또는 템플릿을 사용하는 사용자가 파이프라인 리소스를 추가하려고 하는지 알 수 없습니다. 종속성을 방지하려면 파이프라인 아티팩트 다운로드 작업을 사용하여 모든 빌드 정보를 작업에 전달할 수 있습니다.

Docker Hub 이미지가 업데이트되면 파이프라인 실행을 트리거하려면 어떻게 해야 하나요?

YAML 파이프라인용 Docker Hub에 컨테이너 리소스 트리거를 사용할 수 없으므로 클래식 릴리스 파이프라인을 설정해야 합니다.

  1. 새 Docker Hub 서비스 연결을 만듭니다.

  2. 클래식 릴리스 파이프라인을 만들고 Docker Hub 아티팩트를 추가합니다. 서비스 연결을 설정합니다. 네임스페이스, 리포지토리, 버전 및 원본 별칭을 선택합니다.

    Docker 허브 아티팩트를 추가합니다.

  3. 트리거를 선택하고 연속 배포 트리거를 사용으로 전환합니다. 선택한 리포지토리에 Docker 푸시가 발생할 때마다 릴리스를 만듭니다.

  4. 새 단계 및 작업을 만듭니다. Docker 로그인 및 Bash라는 두 가지 작업을 추가합니다.

  • Docker 작업에는 login 작업이 있으며 Docker 허브에 기록됩니다.

  • Bash 태스크가 실행됩니다 docker pull <hub-user>/<repo-name>[:<tag>]. hub-user, repo-name, tag을 사용자 값으로 바꿉니다.

    Docker 로그인 및 Bash 작업을 추가합니다.

웹후크의 유효성을 검사하고 문제를 해결하려면 어떻게 해야 하나요?

  1. 서비스 연결을 만듭니다.

  2. 서비스 연결을 참조하고 섹션에서 웹후크의 webhooks 이름을 지정합니다.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. 파이프라인을 실행합니다. 파이프라인을 실행하면 웹후크가 Azure에서 조직의 분산 작업으로 만들어집니다.

  4. 본문에서 POST 유효한 JSON을 사용하여 API 호출을 수행합니다 https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. 200개의 상태 코드 응답을 받으면 웹후크가 파이프라인에서 사용할 준비가 된 것입니다. 오류Cannot find webhook for the given webHookId ...와 함께 500 상태 코드 응답을 받으면 코드가 기본 분기 아닌 분기에 있을 수 있습니다.

    1. 파이프라인을 엽니다.
    2. 편집을 선택합니다.
    3. 더 많은 작업 메뉴를 추가 작업 선택 메뉴 선택합니다.
    4. 트리거>YAML>원본 가져오기를 선택합니다.
    5. 수동 및 예약된 빌드의 기본 분기로 이동하여 기능 분기 업데이트합니다.
    6. 저장 큐를 선택합니다.
    7. 이 파이프라인이 성공적으로 실행되면 본문에서 유효한 JSON을 POST 사용하여 API 호출을 수행합니다 https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. 이제 200개 상태 코드 응답을 받게 됩니다.