스테이지, 종속성, & 조건 추가

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

단계는 Azure DevOps 파이프라인의 논리적 경계입니다. 단계를 사용하여 소프트웨어 개발 프로세스에서 작업을 그룹화할 수 있습니다(예: 앱 빌드, 테스트 실행, 사전 프로덕션에 배포). 각 스테이지에는 하나 이상의 작업이 포함됩니다.

파이프라인에서 여러 스테이지를 정의하는 경우 기본적으로 하나씩 실행됩니다. 스테이지는 서로에 따라 달라질 수도 있습니다. 키워드(keyword) 사용하여 dependsOn 종속성을 정의할 수 있습니다. 스테이지는 조건이 있는 이전 단계의 결과에 따라 실행할 수도 있습니다.

단계가 병렬 작업 및 라이선싱에서 작동하는 방식을 알아보려면 병렬 작업 구성 및 비용을 참조 하세요.

단계가 작업과 같은 파이프라인의 다른 부분과 어떻게 관련되는지 알아보려면 주요 파이프라인 개념을 참조 하세요.

또한 YAML 스키마 단계 문서에서 스테이지가 파이프라인의 일부와 어떻게 관련되는지에 대해 자세히 알아볼 수 있습니다.

YAML

파이프라인 작업을 단계로 구성할 수 있습니다. 단계는 파이프라인의 주요 부서입니다. 이 앱을 빌드하고, 이러한 테스트를 실행하고, 사전 프로덕션에 배포하는 것이 단계의 좋은 예입니다. 파이프라인을 일시 중지하고 다양한 검사 수행할 수 있는 파이프라인의 논리적 경계입니다.

명시적으로 정의하지 않더라도 모든 파이프라인에는 하나 이상의 단계가 있습니다. 스테이지가 다른 스테이지 앞에 실행되도록 스테이지를 종속성 그래프 정렬할 수도 있습니다. 한 스테이지에는 256개의 작업 제한이 있습니다.

클래식

릴리스 파이프라인의 배포 작업을 단계로 구성합니다. 단계는 릴리스 파이프라인의 주요 부서입니다. 기능 테스트를 실행하고, 사전 프로덕션에 배포하고, 프로덕션에 배포하는 것이 릴리스 단계의 좋은 예입니다.

릴리스 파이프라인의 단계는 작업 및 작업으로 구성됩니다.

승인 및 게이트, 배포 조건 및 트리거 및 큐 정책은 릴리스가 스테이지에 배포되는 시기를 제어합니다.

단계 지정

YAML

가장 간단한 경우 파이프라인에 논리적 경계가 필요하지 않습니다. 이 경우 키워드(keyword) 명시적으로 사용할 stage 필요가 없습니다. YAML 파일에서 작업을 직접 지정할 수 있습니다.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

파이프라인을 여러 단계로 구성하는 경우 키워드(keyword) 사용합니다 stages .

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

단계 수준에서 지정 pool 하도록 선택한 경우 해당 단계에서 정의된 모든 작업은 작업 수준에서 지정하지 않는 한 해당 풀을 사용합니다.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

스테이지를 지정하는 전체 구문은 다음과 같습니다.

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

클래식

릴리스 파이프라인에 스테이지를 추가하려면 릴리스 페이지에서 릴리스 파이프라인을 선택하고 편집할 작업을 선택한 다음 파이프라인 탭을 선택합니다. 스테이지 정의의 가장 중요한 부분은 자동화 작업이지만 릴리스 파이프라인의 스테이지에 대한 몇 가지 속성과 옵션을 구성할 수도 있습니다. 마케팅 목록의 구성원을 관리할 수 있습니다.

• 필요한 경우 여기에서 스테이지의 이름을 편집합니다.
• 한 사용자 또는 그룹을 스테이지 소유자로 지정합니다. 스테이지 소유자는 해당 스테이지에 대한 배포가 실패할 때마다 알림을 받습니다. 스테이지 소유자가 되는 것은 자동으로 사용 권한이 제공되지 않습니다.
• 파이프라인에서 스테이지를 삭제합니다.
• 스테이지 순서를 변경합니다.
• 스테이지의 복사본을 스테이지 템플릿으로 저장합니다.
• 스테이지의 보안 설정을 관리합니다.

종속성 지정

YAML

파이프라인에서 여러 단계를 정의하는 경우 기본적으로 YAML 파일에서 정의하는 순서대로 순차적으로 실행됩니다. 종속성을 추가하는 경우는 예외입니다. 종속성을 사용하면 dependsOn 요구 사항의 순서대로 단계가 실행됩니다.

파이프라인에는 종속성이 없는 스테이지가 하나 이상 포함되어야 합니다.

여러 단계 및 해당 종속성을 정의하는 구문은 다음과 같습니다.

stages:
- stage: string
  dependsOn: string
  condition: string

순차적으로 실행되는 예제 단계:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

병렬로 실행되는 예제 단계:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

팬아웃 및 팬인의 예:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

클래식

릴리스 파이프라인의 각 단계에서 트리거를 설정하여 종속성을 제어합니다.

• 스테이지는 트리거를 사용하거나 수동으로 시작하여 실행됩니다.
• After 릴리스 트리거를 사용하면 릴리스가 시작되는 즉시 After 릴리스 트리거가 있는 다른 단계와 병렬로 스테이지가 시작됩니다.
• After 스테이지 트리거를 사용하면 모든 종속 단계가 완료된 후 스테이지가 시작됩니다. 이를 사용하여 스테이지에 대한 팬아웃 및 팬인 동작을 모델링할 수 있습니다.

조건 정의

각 단계가 식을 사용하여 실행되는 조건을 지정할 수 있습니다. 기본적으로 스테이지는 다른 스테이지에 의존하지 않거나 스테이지가 의존하는 모든 단계가 완료되고 성공했는지 여부에 따라 실행됩니다. 이전 단계가 실패하더라도 스테이지를 강제로 실행하거나 사용자 지정 조건을 지정하여 이 동작을 사용자 지정할 수 있습니다.

스테이지에 대한 이전 단계의 기본 조건을 사용자 지정하는 경우 완료 및 성공 조건을 제거합니다. 따라서 사용자 지정 조건을 사용하는 경우 이전 단계가 성공적으로 실행되었는지 여부를 검사 데 일반적으로 사용합니다and(succeeded(),custom_condition). 그렇지 않으면 이전 단계의 결과에 관계없이 스테이지가 실행됩니다.

참고 항목

다음 예제와 같이 실패('JOBNAME/STAGENAME') 및 성공('JOBNAME/STAGENAME')에 대한 조건은 YAML 파이프라인에 대해서만 작동합니다.

YAML

이전 단계를 실행하는 상태 따라 스테이지를 실행하는 예제:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

사용자 지정 조건 사용 예:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

클래식

릴리스 후 또는 After 스테이지 트리거를 지정할 때 릴리스에서 사용되는 아티팩트용 분기 필터를 지정할 수도 있습니다. 릴리스는 분기 필터가 충족되는 단계에만 배포됩니다.

큐 정책 지정

YAML

YAML 파이프라인은 큐 정책을 지원하지 않습니다. 파이프라인의 각 실행은 독립적이며 다른 실행을 인식하지 못합니다. 즉, 두 개의 연속 커밋은 두 개의 파이프라인을 트리거할 수 있으며, 둘 다 서로를 기다리지 않고 동일한 단계 시퀀스를 실행합니다. YAML 파이프라인에 큐 정책을 제공하기 위해 노력하고 있지만, 중요한 경우 수동으로 순서를 지정하고 실행을 제어하기 위해 수동 승인을 사용하는 것이 좋습니다.

클래식

경우에 따라 배포할 수 있는 것보다 더 빠르게 빌드를 생성할 수 있습니다. 또는 여러 에이전트를 구성하고, 예를 들어 다른 아티팩트 배포를 위해 동일한 릴리스 파이프라인에서 릴리스를 만들 수 있습니다. 이러한 경우 여러 릴리스가 스테이지에 큐에 대기되는 방식을 제어할 수 있는 것이 유용합니다. 큐 정책은 해당 제어를 제공합니다.

큐 정책에 대해 선택할 수 있는 옵션은 다음과 같습니다.

• 병렬 배포 수: 단계에서 새 리소스를 동적으로 프로비전하고 여러 릴리스의 배포를 병렬로 처리할 수 있지만 병렬 배포 수를 제한하려는 경우 이 옵션을 사용합니다.

• 최대 배포 수를 지정하면 다음 두 가지 옵션이 더 표시됩니다.

  • 모두 순서대로 배포: 모든 릴리스를 동일한 공유 물리적 리소스에 순차적으로 배포하려면 이 옵션을 사용합니다. 차례로 빌드를 배포하면 여러 빌드 및 릴리스 에이전트를 사용할 수 있더라도 두 배포 작업이 동일한 물리적 리소스를 동시에 대상으로 지정하지 않도록 합니다. 또한 스테이지에 대한 사전 배포 승인 요청이 순서대로 전송되는지 확인합니다.

  • 최신 배포 및 다른 항목 취소: 릴리스보다 빠르게 빌드를 생성하고 최신 빌드만 배포하려는 경우 이 옵션을 사용합니다.

이러한 옵션의 작동 방식을 이해하려면 단일 릴리스 파이프라인의 R1, R2, ..., R5 릴리스가 연속해서 만들어지는 시나리오를 고려하세요. 이 파이프라인의 첫 번째 단계는 QA라고 하며 배포 후 승인자와 배포 후 승인자가 모두 정의되어 있다고 가정합니다.

• 병렬 배포 수에 대한 제한을 지정하지 않으면 릴리스가 만들어지는 즉시 5개의 승인 요청이 모두 전송됩니다. 승인자가 모든 릴리스를 승인하면 모두 QA 단계에 병렬로 배포됩니다. (if the QA 단계에는 사전 배포 승인자가 정의되지 않았으며, 5개 릴리스가 모두 이 단계와 병렬로 자동으로 배포됩니다).

• 제한을 지정하고 모두 순서대로 배포하고 한도에 이미 도달한 경우 릴리스 R1 에 대한 배포 승인이 먼저 전송됩니다. 이 승인이 완료되면 릴리스 R1을 QA 단계에 배포하기 시작합니다. 다음으로, 릴리스 R1에 대한 배포 후 승인 요청이 전송됩니다. 이 배포 후 승인이 완료된 후에만 릴리스 R2 의 실행이 시작되고 배포 전 승인이 전송됩니다. 이 프로세스는 모든 릴리스에 대해 다음과 같이 계속됩니다.

• 제한을 지정하고 최신 배포하고 다른 항목을 취소하고 제한에 이미 도달한 경우 릴리스 R2, R3 및 R4는 건너뛰고 QA 단계에서 R5 에 대한 배포 전 승인은 릴리스 R1에 대한 배포 후 승인이 완료된 직후에 전송됩니다.

승인 지정

YAML

승인 검사 사용하여 스테이지가 실행되는 시기를 수동으로 제어할 수 있습니다. 일반적으로 프로덕션 환경에 대한 배포를 제어하는 데 사용됩니다. 검사는 파이프라인의 단계가 리소스를 사용할 수 있는지와 시기를 제어하기 위해 리소스 소유자가 사용할 수 있는 메커니즘입니다. 환경과 같은 리소스의 소유자로서 해당 리소스를 사용하는 스테이지를 시작하기 전에 충족해야 하는 검사 정의할 수 있습니다.

현재 수동 승인 검사 환경에서 지원됩니다. 자세한 내용은 승인 참조하세요.

클래식

파이프라인의 각 단계 시작 또는 끝에서 수동 승인을 추가할 수 있습니다. 자세한 내용은 릴리스 승인 및 게이트 개요를 참조하세요.