Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
단계는 Azure DevOps 파이프라인의 논리적 경계입니다. 소프트웨어 개발 프로세스에서 그룹 작업(예: 앱 빌드, 테스트 실행 및 사전 프로덕션에 배포)을 준비합니다. 각 스테이지에는 하나 이상의 작업이 포함됩니다.
파이프라인에서 여러 스테이지를 정의하는 경우 기본적으로 하나씩 실행됩니다. 스테이지는 서로에 따라 달라질 수도 있습니다. 키워드를 dependsOn 사용하여 종속성을 정의 할 수 있습니다. 스테이지는 조건이 있는 이전 단계의 결과에 따라 실행할 수도 있습니다.
단계가 병렬 작업 및 라이선싱에서 작동하는 방식을 알아보려면 병렬 작업 구성 및 비용을 참조 하세요.
단계가 작업과 같은 파이프라인의 다른 부분과 어떻게 관련되는지 알아보려면 주요 파이프라인 개념을 참조 하세요.
또한 YAML 스키마 단계 문서에서 스테이지가 파이프라인의 일부와 어떻게 관련되는지에 대해 자세히 알아볼 수 있습니다.
파이프라인 작업을 단계로 구성할 수 있습니다. 단계는 파이프라인의 주요 부서입니다. 이 앱을 빌드하고, 이러한 테스트를 실행하고, 사전 프로덕션에 배포하는 것이 단계의 좋은 예입니다. 파이프라인을 일시 중지하고 다양한 검사를 수행할 수 있는 파이프라인의 논리적 경계입니다.
모든 파이프라인에는 명시적으로 정의하지 않더라도 하나 이상의 단계가 있습니다. 스테이지가 다른 스테이지 앞에 실행되도록 스테이지를 종속성 그래프 정렬할 수도 있습니다. 스테이지에는 최대 256개의 작업이 있을 수 있습니다.
단계 지정
가장 간단한 경우에는 파이프라인에 논리적 경계가 필요하지 않습니다. 이러한 시나리오의 경우 키워드 없이 YAML 파일에서 작업을 직접 지정할 수 있습니다 stages . 예를 들어 별도의 환경이나 배포 단계 없이 작은 애플리케이션을 빌드하고 테스트하는 간단한 파이프라인이 있는 경우 단계를 사용하지 않고 모든 작업을 직접 정의할 수 있습니다.
pool:
vmImage: 'ubuntu-latest'
jobs:
- job: BuildAndTest
steps:
- script: echo "Building the application"
- script: echo "Running tests"
이 파이프라인에는 하나의 암시적 단계와 두 개의 작업이 있습니다. 스테이지가 stages 하나뿐이므로 키워드가 사용되지 않습니다.
jobs:
- job: Build
steps:
- bash: echo "Building"
- job: Test
steps:
- bash: echo "Testing"
파이프라인을 여러 단계로 구성하려면 키워드를 stages 사용합니다. 이 YAML은 각 단계에 여러 작업이 포함되고 각 작업에는 실행할 특정 단계가 있는 두 단계가 있는 파이프라인을 정의합니다.
stages:
- stage: A
displayName: "Stage A - Build and Test"
jobs:
- job: A1
displayName: "Job A1 - build"
steps:
- script: echo "Building the application in Job A1"
displayName: "Build step"
- job: A2
displayName: "Job A2 - Test"
steps:
- script: echo "Running tests in Job A2"
displayName: "Test step"
- stage: B
displayName: "Stage B - Deploy"
jobs:
- job: B1
displayName: "Job B1 - Deploy to Staging"
steps:
- script: echo "Deploying to staging in Job B1"
displayName: "Staging deployment step"
- job: B2
displayName: "Job B2 - Deploy to Production"
steps:
- script: echo "Deploying to production in Job B2"
displayName: "Production deployment step"
스테이지 레벨에서 a 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
종속성 지정
파이프라인에서 여러 단계를 정의하면 YAML 파일에서 정의한 순서대로 기본적으로 순차적으로 실행됩니다. 종속성을 추가하는 경우는 예외입니다. 종속성을 사용하면 dependsOn 요구 사항의 순서대로 단계가 실행됩니다.
파이프라인에는 종속성이 없는 스테이지가 하나 이상 포함되어야 합니다.
스테이지를 정의하는 방법에 대한 자세한 내용은 YAML 스키마의 스테이지를 참조하세요.
다음 예제 단계는 순차적으로 실행됩니다. 키워드를 dependsOn 사용하지 않으면 스테이지가 정의된 순서대로 실행됩니다.
stages:
- stage: Build
displayName: "Build Stage"
jobs:
- job: BuildJob
steps:
- script: echo "Building the application"
displayName: "Build Step"
- stage: Test
displayName: "Test Stage"
jobs:
- job: TestJob
steps:
- script: echo "Running tests"
displayName: "Test Step"
병렬로 실행되는 예제 단계:
stages:
- stage: FunctionalTest
displayName: "Functional Test Stage"
jobs:
- job: FunctionalTestJob
steps:
- script: echo "Running functional tests"
displayName: "Run Functional Tests"
- stage: AcceptanceTest
displayName: "Acceptance Test Stage"
dependsOn: [] # Runs in parallel with FunctionalTest
jobs:
- job: AcceptanceTestJob
steps:
- script: echo "Running acceptance tests"
displayName: "Run Acceptance Tests"
팬아웃(fan-out) 및 팬인(fan-in) 동작의 예:
stages:
- stage: Test
- stage: DeployUS1
dependsOn: Test # stage runs after Test
- stage: DeployUS2
dependsOn: Test # stage runs in parallel with DeployUS1, after Test
- stage: DeployEurope
dependsOn: # stage runs after DeployUS1 and DeployUS2
- DeployUS1
- DeployUS2
조건 정의
각 단계가 식을 사용하여 실행되는 조건을 지정할 수 있습니다. 기본적으로 스테이지는 다른 스테이지에 의존하지 않거나 스테이지가 의존하는 모든 단계가 완료되고 성공했는지 여부에 따라 실행됩니다. 이전 단계가 실패하더라도 스테이지를 강제로 실행하거나 사용자 지정 조건을 지정하여 이 동작을 사용자 지정할 수 있습니다.
스테이지에 대한 이전 단계의 기본 조건을 사용자 지정하는 경우 완료 및 성공 조건을 제거합니다. 따라서 사용자 지정 조건을 사용하는 경우 이전 단계가 성공적으로 실행되었는지 여부를 확인하는 데 일반적으로 사용합니다 and(succeeded(),custom_condition) . 그렇지 않으면 이전 단계의 결과에 관계없이 스테이지가 실행됩니다.
비고
다음 예제와 같이 실패('JOBNAME/STAGENAME') 및 성공('JOBNAME/STAGENAME')에 대한 조건은 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'))
대기열 정책 지정
YAML 파이프라인은 큐 정책을 지원하지 않습니다. 파이프라인의 각 실행은 독립적이며 다른 실행을 인식하지 못합니다. 즉, 두 개의 연속 커밋은 두 개의 파이프라인을 트리거할 수 있으며, 둘 다 서로를 기다리지 않고 동일한 단계 시퀀스를 실행합니다. YAML 파이프라인에 큐 정책을 제공하기 위해 노력하고 있지만, 중요한 경우 수동으로 순서를 지정하고 실행을 제어하기 위해 수동 승인을 사용하는 것이 좋습니다.
승인 내역 지정
승인 검사를 사용하여 스테이지를 실행하는 시기를 수동으로 제어할 수 있습니다. 일반적으로 프로덕션 환경에 대한 배포를 제어하는 데 사용됩니다. 검사는 파이프라인의 단계가 리소스를 사용할 수 있는지와 시기를 제어하기 위해 리소스 소유자가 사용할 수 있는 메커니즘입니다. 환경과 같은 리소스의 소유자는 해당 리소스를 사용하는 단계를 시작하기 전에 충족해야 하는 검사를 정의할 수 있습니다.
현재 수동 승인 검사는 환경에서 지원됩니다. 자세한 내용은 승인을 참조 하세요.
수동 트리거 추가
수동으로 트리거된 YAML 파이프라인 단계를 사용하면 항상 완료까지 실행하지 않고도 통합 파이프라인을 사용할 수 있습니다.
예를 들어 파이프라인에는 스테이징 환경에 빌드, 테스트, 배포 및 프로덕션에 배포하는 단계가 포함될 수 있습니다. 프로덕션 배포를 제외한 모든 스테이지가 자동으로 실행되도록 할 수 있습니다. 준비되면 수동으로 트리거하는 것이 좋습니다.
이 기능을 사용하려면 스테이지에 trigger: manual 속성을 추가합니다.
다음 예제에서는 개발 단계가 자동으로 실행되지만 프로덕션 단계에서는 수동 트리거가 필요합니다. 두 단계 모두 hello world 출력 스크립트를 실행합니다.
stages:
- stage: Development
displayName: Deploy to development
jobs:
- job: DeployJob
steps:
- script: echo 'hello, world'
displayName: 'Run script'
- stage: Production
displayName: Deploy to production
trigger: manual
jobs:
- job: DeployJob
steps:
- script: echo 'hello, world'
displayName: 'Run script'
스테이지를 건너뛸 수 없음으로 표시
파이프라인 사용자가 단계를 isSkippable: false 건너뛰지 못하도록 스테이지를 표시합니다. 예를 들어 모든 파이프라인에서 맬웨어 감지를 수행하는 단계를 삽입하는 YAML 템플릿이 있을 수 있습니다. 이 단계를 설정하면 isSkippable: false 파이프라인에서 맬웨어 감지를 건너뛸 수 없습니다.
다음 예제에서 맬웨어 감지 단계는 건너뛸 수 없는 것으로 표시되며, 이는 파이프라인 실행의 일부로 실행되어야 함을 의미합니다.
- stage: malware_detection
displayName: Malware detection
isSkippable: false
jobs:
- job: check_job
...
스테이지를 건너뛸 수 없는 경우 Stages to run 구성 패널에 비활성화된 확인란이 표시됩니다.
