파이프라인에서 작업 지정

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

파이프라인을 작업으로 구성할 수 있습니다. 모든 파이프라인에는 하나 이상의 작업이 있습니다. 작업은 단위로 순차적으로 실행되는 일련의 단계입니다. 즉, 작업은 실행하도록 예약할 수 있는 가장 작은 작업 단위입니다.

파이프라인을 구성하는 주요 개념 및 구성 요소에 대해 알아보려면 새 Azure Pipelines 사용자의 주요 개념을 참조 하세요.

Azure Pipelines는 YAML 파이프라인에 대한 작업 우선 순위를 지원하지 않습니다. 작업 실행 시기를 제어하기 위해 조건 및 종속성을 지정할 수 있습니다.

단일 작업 정의

YAML

가장 간단한 경우 파이프라인에는 단일 작업이 있습니다. 이 경우 템플릿을 사용하지 않는 한 키워드를 job 명시적으로 사용할 필요가 없습니다. YAML 파일의 단계를 직접 지정할 수 있습니다.

이 YAML 파일에는 Microsoft 호스팅 에이전트에서 실행되고 출력되는 작업이 있습니다Hello world.

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

해당 작업에 더 많은 속성을 지정할 수 있습니다. 이 경우 키워드를 job 사용할 수 있습니다.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

파이프라인에 여러 작업이 있을 수 있습니다. 이 경우 키워드를 jobs 사용합니다.

jobs:
- job: A
  steps:
  - bash: echo "A"

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

파이프라인에는 각각 여러 작업이 있는 여러 단계가 있을 수 있습니다. 이 경우 키워드를 stages 사용합니다.

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

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

작업을 지정하는 전체 구문은 다음과 같습니다.

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

작업의 기본 의도가 앱을 빌드하거나 테스트하는 것이 아니라 앱을 배포하는 것이라면 배포 작업이라는 특수한 유형의 작업을 사용할 수 있습니다.

배포 작업의 구문은 다음과 같습니다.

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

배포 작업에 job대한 단계를 추가할 수 있지만 대신 배포 작업을 사용하는 것이 좋습니다. 배포 작업에는 몇 가지 이점이 있습니다. 예를 들어 배포한 내용의 기록을 볼 수 있는 것과 같은 이점을 포함하는 환경에 배포할 수 있습니다.

클래식

빌드 파이프라인에 작업을 추가하려면 파이프라인 페이지에서 파이프라인을 편집합니다. 작업을 추가하려면 ...를 선택합니다.

릴리스 파이프라인에 작업을 추가하려면 파이프라인 릴리스에서 파이프라인을>편집합니다. 작업을 추가할 스테이지의 스테이지 작업을 봅니다. 작업을 추가하려면 ...를 선택합니다.

작업 유형

작업은 실행 위치에 따라 다른 형식일 수 있습니다.

YAML

• 에이전트 풀 작업은 에이전트 풀의 에이전트에서 실행됩니다.
• 서버 작업은 Azure DevOps Server에서 실행됩니다.
• 컨테이너 작업 은 에이전트 풀의 에이전트에 있는 컨테이너에서 실행됩니다. 컨테이너 선택에 대한 자세한 내용은 컨테이너 작업 정의를 참조 하세요.

클래식

• 에이전트 풀 작업은 에이전트 풀의 에이전트에서 실행됩니다.
• 서버 작업은 Azure DevOps Server에서 실행됩니다.
• 배포 그룹 작업은 배포 그룹의 컴퓨터에서 실행됩니다. 이러한 작업은 릴리스 파이프라인에서만 사용할 수 있습니다. 배포를 위한 대상 서버 그룹을 정의하는 방법에 대한 자세한 내용은 배포 그룹 작업을 참조 하세요.

에이전트 풀 작업

이러한 작업은 가장 일반적인 유형의 작업이며 에이전트 풀의 에이전트에서 실행됩니다.

• Microsoft 호스팅 에이전트를 사용하는 경우 파이프라인의 각 작업은 새 에이전트를 가져옵니다.
• 자체 호스팅 에이전트와 함께 요구를 사용하여 에이전트가 작업을 실행해야 하는 기능을 지정합니다. 파이프라인의 요구와 일치하는 에이전트 풀에 둘 이상의 에이전트가 있는지 여부에 따라 연속 작업에 대해 동일한 에이전트를 가져올 수 있습니다. 파이프라인의 요구와 일치하는 에이전트가 풀에 하나만 있는 경우 파이프라인은 이 에이전트를 사용할 수 있을 때까지 기다립니다.

참고 항목

요구 사항 및 기능은 작업의 요구 사항을 충족하는 에이전트와 작업을 일치시킬 수 있도록 자체 호스팅 에이전트에서 사용하도록 설계되었습니다. Microsoft 호스팅 에이전트를 사용하는 경우 작업의 요구 사항과 일치하는 에이전트에 대한 이미지를 선택하므로 Microsoft 호스팅 에이전트에 기능을 추가할 수 있지만 Microsoft 호스팅 에이전트에서 기능을 사용할 필요는 없습니다.

YAML

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

또는 여러 요구 사항:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

클래식

파이프라인, 작업 또는 둘 다에서 요청을 지정할 수 있습니다. 파이프라인과 작업 모두에서 요구를 지정하는 경우 시스템에서 에이전트를 선택하려면 두 요구 집합의 합합이 필요합니다.

에이전트 기능에 대해 자세히 알아봅니다.

서버 작업

서버 작업의 작업은 서버(Azure Pipelines 또는 TFS)에 의해 오케스트레이션되고 실행됩니다. 서버 작업에는 에이전트 또는 대상 컴퓨터가 필요하지 않습니다. 지금은 서버 작업에서 몇 가지 작업만 지원됩니다. 서버 작업의 최대 시간은 30일입니다.

에이전트 없는 작업 지원 작업

현재 에이전트 없는 작업에 대해 다음 작업만 기본적으로 지원됩니다.

• 지연 작업
• Azure 함수 작업 호출
• REST API 작업 호출
• 수동 유효성 검사 작업
• Azure Service Bus에 게시 작업
• Azure Monitor 경고 쿼리 작업
• 작업 항목 쿼리 작업

작업은 확장 가능하므로 확장을 사용하여 에이전트 없는 작업을 더 추가할 수 있습니다. 에이전트 없는 작업의 기본 시간 제한은 60분입니다.

YAML

서버 작업을 지정하는 전체 구문은 다음과 같습니다.

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

간소화된 구문을 사용할 수도 있습니다.

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

클래식

'...'를 선택하여 편집기에서 서버 작업을 추가합니다. 파이프라인의 작업 탭에 있는 파이프라인 채널의 입니다. 편집기에서 작업을 선택하면 서버 작업의 속성이 표시됩니다.

종속성

단일 단계에서 여러 작업을 정의할 때 해당 작업 간에 종속성을 지정할 수 있습니다. 파이프라인에는 종속성이 없는 작업이 하나 이상 포함되어야 합니다. 기본적으로 값이 설정되지 않는 한 Azure DevOps YAML 파이프라인 작업은 병렬로 dependsOn 실행됩니다.

참고 항목

각 에이전트는 한 번에 하나의 작업만 실행할 수 있습니다. 여러 작업을 병렬로 실행하려면 여러 에이전트를 구성해야 합니다. 또한 충분한 병렬 작업도 필요합니다.

YAML

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

jobs:
- job: string
  dependsOn: string
  condition: string

순차적으로 빌드되는 예제 작업:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

병렬로 빌드되는 예제 작업(종속성 없음):

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

팬 아웃의 예:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

팬인의 예:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

클래식

새 작업을 추가하려면 '...'를 선택합니다. 파이프라인의 작업 탭에 있는 파이프라인 채널의 입니다. 편집기에서 작업을 선택하면 작업의 실행 조건과 순서가 표시됩니다.

빌드 파이프라인에서 여러 작업을 지정하면 기본적으로 병렬로 실행됩니다. 작업 간에 종속성을 구성하여 작업이 실행되어야 하는 순서를 지정할 수 있습니다. 작업 종속성은 릴리스 파이프라인에서 지원되지 않습니다. 릴리스 파이프라인의 여러 작업이 순서대로 실행됩니다.

예를 들어 아래 표시된 파이프라인은 두 개의 에이전트 작업과 서버 작업을 사용하여 전체 릴리스 실행을 별도의 실행 작업으로 나눕니다.

위 예제의 내용은 다음과 같습니다.

1. 릴리스의 첫 번째 작업의 작업은 에이전트에서 실행되고, 이 작업이 완료되면 에이전트가 해제됩니다.

2. 서버 작업에는 Azure Pipelines 또는 TFS에서 실행되는 수동 개입 태스크가 포함되어 있습니다. 작업은 에이전트 또는 대상 서버에서 실행되거나 필요하지 않습니다. 수동 개입 태스크는 메시지를 표시하고 사용자의 "다시 시작" 또는 "거부" 응답을 기다립니다. 이 예제에서 구성된 시간 제한에 도달하면 작업이 배포를 자동으로 거부합니다(자동화된 응답을 생성하지 않으려면 컨트롤 옵션 섹션의 시간 제한을 0으로 설정).

3. 릴리스가 다시 시작되면 세 번째 작업의 작업이 다른 에이전트에서 실행됩니다. 릴리스가 거부되면 이 작업이 실행되지 않고 릴리스가 실패한 것으로 표시됩니다.

단계적 실행의 결과 중 일부를 이해하는 것이 중요합니다.

• 각 작업은 서로 다른 에이전트를 사용할 수 있습니다. 후속 작업 중에 이전 작업의 상태를 사용할 수 있다고 가정하지 마세요.

• 오류 발생 시 계속 및 각 작업의 태스크에 대한 Always 실행 옵션은 후속 작업의 작업에 영향을 주지 않습니다. 예를 들어 첫 번째 작업의 끝에 있는 태스크에서 Always Run을 설정해도 후속 작업의 태스크가 실행되도록 보장하지는 않습니다.

조건

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

YAML

이전 작업 실행 상태에 따라 작업을 실행하는 예제:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

사용자 지정 조건 사용 예:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

이전 작업에서 설정된 출력 변수의 값에 따라 작업이 실행되도록 지정할 수 있습니다. 이 경우 직접 종속 작업에 설정된 변수만 사용할 수 있습니다.

jobs:
- job: A
  steps:
  - script: "echo '##vso[task.setvariable variable=skipsubsequent;isOutput=true]false'"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

클래식

에이전트 또는 서버 작업에서 이 작업 실행 옵션을 사용하여 특정 조건이 충족되는 경우에만 작업을 실행합니다. 미리 정의된 조건을 선택하거나 "사용자 지정"을 선택하고 true 또는 false로 계산되는 식을 입력합니다. 중첩된 식을 사용할 수 있으며 식은 릴리스 파이프라인에서 사용할 수 있는 변수에 액세스할 수 있습니다.

시간 제한

작업이 응답하지 않거나 너무 오래 대기할 때 리소스를 사용하지 않도록 하려면 작업 실행 기간에 제한을 설정하는 것이 좋습니다. 작업 시간 제한 설정을 사용하여 작업 실행에 시간 제한(분)을 지정합니다. 값을 0으로 설정하면 작업을 실행할 수 있습니다.

• 자체 호스팅 에이전트의 포에버
• 공용 프로젝트가 있는 Microsoft 호스팅 에이전트에서 360분(6시간) 동안 및 퍼블릭 리포지토리
• 프라이빗 프로젝트 또는 프라이빗 리포지토리가 있는 Microsoft 호스팅 에이전트에서 60분 동안(추가 용량이 지불되지 않는 한)

시간 제한 기간은 작업 실행을 시작할 때 시작됩니다. 작업이 대기 중이거나 에이전트를 기다리는 시간은 포함되지 않습니다.

YAML

작업 timeoutInMinutes 실행 시간에 대한 제한을 설정할 수 있습니다. 지정하지 않으면 기본값은 60분입니다. 지정된 경우 0 최대 제한이 사용됩니다(위에서 설명).

이전 cancelTimeoutInMinutes 작업이 실패한 경우 배포 작업이 계속 실행되도록 설정된 경우 작업 취소 시간에 대한 제한을 설정할 수 있습니다. 지정하지 않으면 기본값은 5분입니다. 값의 범위는 1~35790분이어야 합니다.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

클래식

작업을 선택한 다음 시간 제한 값을 지정합니다.

옵션 탭에서 파이프라인의 모든 작업에 대한 기본값을 지정할 수 있습니다. 작업 시간 제한에 대해 0이 아닌 값을 지정하면 파이프라인 옵션에 지정된 값을 재정의합니다. 0 값을 지정하면 파이프라인 옵션의 시간 제한 값이 사용됩니다. 파이프라인 값도 0으로 설정된 경우 시간 제한이 없습니다.

시간 제한의 우선 순위는 다음과 같습니다.

1. Microsoft 호스팅 에이전트에서 작업은 프로젝트 유형에 따라 실행할 수 있는 기간과 유료 병렬 작업을 사용하여 실행되는지 여부에 따라 제한됩니다. Microsoft에서 호스팅하는 작업 시간 제한 간격이 경과하면 작업이 종료됩니다. Microsoft 호스팅 에이전트에서 작업에 지정된 작업 수준 시간 제한에 관계없이 작업이 이 간격보다 오래 실행될 수 없습니다.
2. 작업 수준에서 구성된 시간 제한은 작업을 실행할 최대 기간을 지정합니다. 작업 수준 제한 시간 간격이 경과하면 작업이 종료됩니다. 작업이 Microsoft 호스팅 에이전트에서 실행되는 경우 기본 제공 Microsoft 호스팅 작업 수준 시간 제한보다 큰 간격으로 작업 수준 제한 시간을 설정해도 효과가 없으며 Microsoft 호스팅 작업 시간 제한이 사용됩니다.
3. 각 작업에 대한 시간 제한을 개별적으로 설정할 수도 있습니다. 작업 제어 옵션을 참조 하세요. 작업이 완료되기 전에 작업 수준 시간 제한 간격이 경과하면 작업이 더 긴 시간 제한 간격으로 구성된 경우에도 실행 중인 작업이 종료됩니다.

다중 작업 구성

작성하는 단일 작업에서 여러 에이전트에서 여러 작업을 병렬로 실행할 수 있습니다. 일부 사례:

• 다중 구성 빌드: 여러 구성을 병렬로 빌드할 수 있습니다. 예를 들어 플랫폼과 플랫폼 모두에서 x86 x64 구성 모두 debug release 에 대한 Visual C++ 앱을 빌드할 수 있습니다. 자세한 내용은 여러 플랫폼에 대한 여러 구성인 Visual Studio Build를 참조 하세요.

• 다중 구성 배포: 예를 들어 여러 지리적 지역에 병렬로 여러 배포를 실행할 수 있습니다.

• 다중 구성 테스트: 여러 구성 테스트를 병렬로 실행할 수 있습니다.

• 다중 구성 변수가 비어 있더라도 다중 구성은 항상 하나 이상의 작업을 생성합니다.

YAML

이 matrix 전략을 사용하면 다양한 변수 집합을 사용하여 작업을 여러 번 디스패치할 수 있습니다. 태그는 maxParallel 병렬 처리의 양을 제한합니다. 다음 작업은 지정된 대로 Location 및 Browser의 값을 사용하여 세 번 디스패치됩니다. 그러나 두 개의 작업만 동시에 실행됩니다.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

참고 항목

행렬 구성 이름(위와 같이 US_IE )은 기본 라틴 문자(A-Z, a-z), 숫자 및 밑줄(_)만 포함해야 합니다. 열 이름은 문자로 시작해야 합니다. 또한 100자 이하여야 합니다.

출력 변수를 사용하여 행렬을 생성할 수도 있습니다 . 스크립트를 사용하여 행렬을 생성해야 하는 경우 편리할 수 있습니다.

matrix 는 문자열화된 JSON 개체를 포함하는 런타임 식을 허용합니다. 확장된 JSON 개체는 행렬 구문과 일치해야 합니다. 아래 예제에서는 JSON 문자열을 하드 코딩했지만 스크립팅 언어 또는 명령줄 프로그램에서 생성할 수 있습니다.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

클래식

다중 구성 옵션을 사용하여 여러 작업을 실행하려면 승수라는 변수를 식별하고 해당 승수에 대한 값 목록을 지정합니다. 목록의 각 값에 대해 별도의 작업이 실행됩니다. 빌드 또는 배포에 승수를 사용하려면 다음을 수행해야 합니다.

• 파이프라인의 변수 탭 또는 변수 그룹에서 하나 이상의 변수를 정의합니다. 이 컨텍스트에서 승수 변수로 알려진 각 변수는 에이전트에 개별적으로 전달하려는 값의 쉼표로 구분된 목록으로 정의되어야 합니다.

• 승수 매개 변수의 값으로 승수 변수와 괄호 없이 $ 승수 변수의 이름을 입력합니다 . 비밀 변수를 승수 변수로 사용하는 것은 지원되지 않습니다.

• 둘 이상의 승수 변수에 대해 작업을 실행하려면 변수 이름을 쉼표로 구분된 목록으로 입력하여 $ 각각에 대한 괄호와 괄호를 생략합니다.

• 배포 중에 사용된 에이전트 수를 구독에 대해 구성한 것보다 적은 수로 제한하려면 해당 값을 최대 에이전트 수 매개 변수로 입력합니다 .

예를 들어 다음과 같이 Location 및 Browser라는 두 개의 변수를 정의할 수 있습니다.

• 위치 = US,Europe
• 브라우저 = IE,Chrome,Edge,Firefox

다음 구성은 한 번에 최대 4개의 에이전트를 사용하여 배포를 8번 실행합니다.

• 멀티 플라이어 = Location,Browser
• 최대 에이전트 수 = 4

다중 구성을 사용하면 각각 하나 이상의 변수(승수)에 대해 서로 다른 값을 가진 여러 작업을 실행할 수 있습니다. 여러 에이전트에서 동일한 작업을 실행하려는 경우 병렬 처리의 다중 에이전트 옵션을 사용할 수 있습니다. 위의 테스트 조각화 예제는 다중 에이전트 옵션을 통해 수행할 수 있습니다.

조각화

에이전트 작업을 사용하여 테스트 제품군을 병렬로 실행할 수 있습니다. 예를 들어 단일 에이전트에서 1,000개의 대규모 테스트 모음을 실행할 수 있습니다. 또는 두 개의 에이전트를 사용하고 각각에 대해 500개의 테스트를 병렬로 실행할 수 있습니다.

조각화 적용하려면 작업의 태스크가 속한 조각을 이해할 수 있을 만큼 똑똑해야 합니다.

Visual Studio 테스트 작업은 테스트 조각화가 지원되는 작업 중 하나입니다. 여러 에이전트를 설치한 경우 이러한 에이전트에서 Visual Studio 테스트 작업이 병렬로 실행되는 방법을 지정할 수 있습니다.

YAML

이 parallel 전략을 통해 작업을 여러 번 복제할 수 있습니다. 변수 및 System.JobPositionInPhase System.TotalJobsInPhase 각 작업에 추가됩니다. 그런 다음 스크립트 내에서 변수를 사용하여 작업 간에 작업을 나눌 수 있습니다. 에이전트 작업을 사용하여 병렬 및 여러 실행을 참조 하세요.

다음 작업은 값 System.JobPositionInPhase 으로 5번 디스패치되고 System.TotalJobsInPhase 적절하게 설정됩니다.

jobs:
- job: Test
  strategy:
    parallel: 5

클래식

조각화 적용 할 에이전트 작업에 다중 에이전트 옵션을 지정합니다. 작업은 지정한 에이전트 수와 변수 System.JobPositionInPhase 수만큼 디스패치되며 System.TotalJobsInPhase 각 작업에서 자동으로 설정됩니다.

작업 변수

YAML을 사용하는 경우 작업에 변수를 지정할 수 있습니다. 변수는 매크로 구문 $(variableName)를 사용하여 태스크 입력에 전달되거나 스테이지 변수를 사용하여 스크립트 내에서 액세스할 수 있습니다.

YAML

다음은 작업에서 변수를 정의하고 작업 내에서 변수를 사용하는 예제입니다.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

클래식

작업 변수는 웹 편집기에서 아직 지원되지 않습니다.

조건 사용에 대한 자세한 내용은 조건 지정을 참조하세요.

작업 영역

에이전트 풀 작업을 실행하면 에이전트에 작업 영역이 만들어집니다. 작업 영역은 원본을 다운로드하고, 단계를 실행하고, 출력을 생성하는 디렉터리입니다. 작업 영역 디렉터리를 변수를 사용하여 Pipeline.Workspace 작업에서 참조할 수 있습니다. 이 경우 다음과 같은 다양한 하위 디렉터리가 만들어집니다.

• Build.SourcesDirectory 는 태스크가 애플리케이션의 소스 코드를 다운로드하는 위치입니다.
• Build.ArtifactStagingDirectory 는 태스크가 게시되기 전에 파이프라인에 필요한 아티팩트 또는 업로드 아티팩트 다운로드 위치입니다.
• Build.BinariesDirectory 는 태스크가 출력을 작성하는 위치입니다.
• Common.TestResultsDirectory 는 태스크가 테스트 결과를 업로드하는 위치입니다.

YAML

$(Common.TestResultsDirectory) 모든 $(Build.ArtifactStagingDirectory) 빌드 전에 항상 삭제되고 다시 만들어집니다.

자체 호스팅 에이전트에서 파이프라인을 실행하는 경우 기본적으로 두 번의 연속 실행 사이에 정리되는 하위 디렉터리 이외의 $(Build.ArtifactStagingDirectory) $(Common.TestResultsDirectory) 하위 디렉터리가 없습니다. 따라서 해당 작업을 사용하기 위해 구현되는 경우 증분 빌드 및 배포를 수행할 수 있습니다. 작업의 설정을 사용하여 이 동작을 재정의 workspace 할 수 있습니다.

Important

작업 영역 정리 옵션은 자체 호스팅 에이전트에만 적용됩니다. 작업은 항상 Microsoft 호스팅 에이전트를 사용하는 새 에이전트에서 실행됩니다.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

옵션 중 clean 하나를 지정하면 다음과 같이 해석됩니다.

• outputs: 새 작업을 실행하기 전에 삭제 Build.BinariesDirectory 합니다.
• resources: 새 작업을 실행하기 전에 삭제 Build.SourcesDirectory 합니다.
• all: 새 작업을 실행하기 전에 전체 Pipeline.Workspace 디렉터리를 삭제합니다.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

참고 항목

에이전트 기능 및 파이프라인 요구 사항에 따라 각 작업은 자체 호스팅 풀의 다른 에이전트로 라우팅될 수 있습니다. 따라서 후속 파이프라인 실행(또는 동일한 파이프라인의 단계 또는 작업)에 대한 새 에이전트를 가져올 수 있으므로 정리하지 않는 것이 후속 실행, 작업 또는 단계가 이전 실행, 작업 또는 단계의 출력에 액세스할 수 있다는 보장은 아닙니다 . 파이프라인 작업을 실행하는 데 사용되는 에이전트를 지정하도록 에이전트 기능 및 파이프라인 요구를 구성할 수 있지만, 풀에 요구를 충족하는 단일 에이전트만 없는 한 후속 작업에서 이전 작업과 동일한 에이전트를 사용할 것이라는 보장은 없습니다. 자세한 내용은 요청 지정을 참조 하세요.

작업 영역 정리 외에도 파이프라인 설정 UI에서 정리 설정을 구성하여 정리를 구성할 수도 있습니다. 기본값이기도 한 클린 설정이 true이면 파이프라인의 모든 체크 아웃 단계에 대해 지정하는 clean: true 것과 같습니다. 지정clean: true하면 git 가져오기 전에 다음을 git reset --hard HEAD 실행 git clean -ffdx 합니다. 정리 설정을 구성하려면 다음을 수행합니다.

1. 파이프라인을 편집하고, ...를 선택하고, 트리거를 선택합니다.

   

2. YAML을 선택하고 원본을 가져와 원하는 정리 설정을 구성합니다. 기본값은 true입니다.

   

클래식

자체 호스팅 에이전트에서 파이프라인을 실행하는 경우 기본적으로 두 번의 연속 실행 사이에 하위 디렉터리가 정리되지 않습니다. 따라서 작업을 구현하는 경우 증분 빌드 및 배포를 실행할 수 있습니다. 그러나 작업에서 Get sources 옵션을 사용하여 이 동작을 재정의할 Clean build 수 있습니다. 옵션은 사용하는 리포지토리의 유형에 따라 달라집니다.

• GitHub
• Azure Repos Git
• TFVC

아티팩트 다운로드

이 예제 YAML 파일은 아티팩 WebSite 트 및 아티팩트 다운로드를 $(Pipeline.Workspace)게시합니다. 배포 작업은 빌드 작업이 성공한 경우에만 실행됩니다.

YAML

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

클래식

릴리스 파이프라인에서 작업 실행 중에 아티팩트 다운로드를 건너뛰도록 선택할 수 있습니다. 작업을 사용하여 아티팩트를 다운로드하기 위한 사용자 지정 논리를 구현하거나 특정 작업의 태스크가 아티팩트를 사용하지 않는 경우 이 옵션을 사용합니다.

또는 릴리스에서 작업 실행 중에 특정 아티팩트를 다운로드하도록 선택할 수 있습니다. 특정 작업의 태스크가 특정 아티팩트만 사용하는 경우 이 옵션을 사용합니다.

dependsOn 및 조건 사용에 대한 자세한 내용은 조건 지정을 참조하세요.

OAuth 토큰에 대한 액세스

작업에서 실행 중인 스크립트가 현재 Azure Pipelines 또는 TFS OAuth 보안 토큰에 액세스하도록 허용할 수 있습니다. 토큰을 사용하여 Azure Pipelines REST API에 인증할 수 있습니다.

YAML

OAuth 토큰은 YAML 파이프라인에서 항상 사용할 수 있습니다. 를 사용하여 env작업 또는 단계에 명시적으로 매핑되어야 합니다. 예를 들어 다음과 같습니다.

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

클래식

작업에 대한 컨트롤 옵션에서 스크립트가 OAuth 토큰에 액세스하도록 허용 옵션을 선택합니다. 토큰은 환경 변수 SYSTEM_ACCESSTOKEN로 사용할 수 있습니다.

다음 단계

• 배포 그룹 작업
• 조건