작업 유형 및 사용

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

태스크는 파이프라인에서 작업을 수행하고 입력 집합으로 추상화된 패키지된 스크립트 또는 프로시저입니다. 작업은 파이프라인에서 자동화를 정의하기 위한 구성 요소입니다.

작업을 실행하면 모든 작업이 순서대로 실행됩니다. 여러 에이전트에서 동일한 작업 집합을 병렬로 실행하거나 에이전트를 사용하지 않고 일부 작업을 실행하려면 작업을 참조하세요.

기본적으로 모든 작업은 호스트에 있든 작업 컨테이너에 있든 관계없이 동일한 컨텍스트에서 실행됩니다.

필요에 따라 단계 대상을 사용하여 개별 작업에 대한 컨텍스트를 제어할 수 있습니다.

기본 제공 작업을 사용하여 작업에 대한 속성을 지정하는 방법에 대해 자세히 알아봅니다.

태스크에서 지원하는 일반적인 특성에 대해 자세히 알아보려면 steps.task에 대한 YAML 참조를 참조하세요.

사용자 지정 작업

Azure DevOps에는 기본 빌드 및 배포 시나리오를 사용하도록 설정하는 기본 제공 작업이 포함되어 있습니다. 사용자 고유의 사용자 지정 작업을 만들 수도 있습니다.

또한 Visual Studio Marketplace 는 많은 확장을 제공합니다. 각 확장은 구독 또는 컬렉션에 설치될 때 하나 이상의 작업으로 작업 카탈로그를 확장합니다. 사용자 고유 의 사용자 지정 확장을 작성하여 Azure Pipelines 에 작업을 추가할 수도 있습니다.

YAML 파이프라인에서는 이름으로 작업을 참조합니다. 이름이 기본 제공 작업과 사용자 지정 작업 모두와 일치하는 경우 기본 제공 작업이 우선적으로 적용됩니다. 사용자 지정 작업에 대해 작업 GUID 또는 정규화된 이름을 사용하여 이러한 위험을 방지할 수 있습니다.

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

찾 myPublisherIdmyExtensionId은 후 마켓플레이스에서 작업 가져오기를 선택합니다. URL 문자열의 itemName 다음 값은 다음과 myExtensionId같습니다myPublisherId. 릴리스 파이프라인에 작업을 추가하고 작업을 편집할 때 YAML 보기를 선택하여 정규화된 이름을 찾을 수도 있습니다.

작업 버전

작업의 버전이 지정되며 파이프라인에 사용되는 작업의 주 버전을 지정해야 합니다. 이렇게 하면 새 버전의 작업이 릴리스될 때 문제를 방지하는 데 도움이 될 수 있습니다. 태스크는 일반적으로 이전 버전과 호환되지만 일부 시나리오에서는 작업이 자동으로 업데이트될 때 예측할 수 없는 오류가 발생할 수 있습니다.

새 부 버전(예: 1.2~1.3)이 릴리스되면 파이프라인은 자동으로 새 버전을 사용합니다. 그러나 새 주 버전이 릴리스되는 경우(예: 2.0) 파이프라인은 파이프라인을 편집하고 새 주 버전으로 수동으로 변경할 때까지 지정한 주 버전을 계속 사용합니다. 로그에는 새 주 버전을 사용할 수 있다는 경고가 포함됩니다.

부 버전 다음 작업의 @ 전체 버전 번호를 지정하여 사용할 부 버전을 설정할 수 있습니다(예: GoTool@0.3.1). 조직에 존재하는 작업 버전만 사용할 수 있습니다.

YAML

YAML에서는 작업 이름을 사용하여 @ 주 버전을 지정합니다. 예를 들어 작업의 버전 2에 고정하려면 다음을 PublishTestResults 수행합니다.

steps:
- task: PublishTestResults@2

클래식

파이프라인의 각 작업에는 원하는 버전을 선택할 수 있는 버전 선택기가 있습니다.

미리 보기 버전(예: 1.* 미리 보기)을 선택하면 버전이 아직 개발 중이며 문제가 있을 수 있습니다.

버전을 변경하고 빌드에 문제가 있는 경우 기록 탭에서 파이프라인 변경을 되돌리기 수 있습니다. 릴리스 파이프라인의 이전 버전으로 복원하는 기능은 현재 사용할 수 없습니다. 릴리스 파이프라인에 대한 변경 내용을 수동으로 되돌리기 다음 파이프라인을 저장해야 합니다.

파이프라인을 복제하고 새 주 작업 버전으로 복제된 파이프라인을 테스트하는 것이 좋습니다.

작업 제어 옵션

각 작업은 몇 가지 제어 옵션을 제공합니다.

YAML

컨트롤 옵션은 섹션에서 키 task 로 사용할 수 있습니다.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  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.

참고 항목

지정된 작업 또는 작업은 작업/단계가 계속되는지 여부를 일방적으로 결정할 수 없습니다. 수행할 수 있는 작업은 성공 또는 실패의 상태 제공하고, 다운스트림 작업/작업에는 각각 실행 여부를 결정할 수 있는 조건 계산이 있습니다. 사실상 "성공한 상태인 경우 실행"인 기본 조건입니다.

오류 발생 후 계속하면 미묘한 방식으로 변경됩니다. 모든 다운스트림 단계/작업을 효과적으로 "트릭"하여 결과를 "성공"으로 처리하여 해당 결정을 내립니다. 또는 "포함하는 구조의 조건에 대한 결정을 내릴 때 이 작업의 실패를 고려하지 마십시오"라고 말합니다.

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

참고 항목

파이프라인에는 작업 수준 시간 제한 외에도 지정된 작업 수준 시간 제한이 있을 수 있습니다. 단계가 완료되기 전에 작업 수준 시간 제한 간격이 경과하면 단계가 더 긴 시간 제한 간격으로 구성된 경우에도 실행 중인 작업이 종료됩니다. 자세한 내용은 시간 제한을 참조 하세요.

이 YAML PublishTestResults@2 에서는 succeededOrFailed() 조건으로 인해 이전 단계가 실패하더라도 실행됩니다.

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

조건

• 동일한 에이전트 풀을 사용하는 이전의 모든 직접 및 간접 종속성이 성공한 경우에만 가능합니다. 다른 에이전트 풀이 있는 경우 해당 단계 또는 작업이 동시에 실행됩니다. YAML에 설정된 조건이 없는 경우 기본값입니다.

• 이전 종속성이 실패한 경우에도 실행이 취소되지 않은 경우 이 조건에 대해 YAML에서 사용합니다 succeededOrFailed() .

• 이전 종속성이 실패하고 실행이 취소된 경우에도 이 조건에 대해 YAML에서 사용합니다 always() .

• 이전 종속성이 실패한 경우에만 이 조건에 대해 YAML에서 사용합니다 failed() .

• 식으로 구성된 사용자 지정 조건

단계 대상

태스크는 에이전트 호스트 또는 컨테이너인 실행 컨텍스트에서 실행됩니다. 개별 단계는 .를 지정하여 컨텍스트를 재정의 target할 수 있습니다. 사용 가능한 옵션은 에이전트 호스트를 대상으로 하는 단어 host 와 파이프라인에 정의된 모든 컨테이너입니다. 예시:

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

여기서 호스트에서 SampleTask 실행되고 AnotherTask 컨테이너에서 실행됩니다.

작업 실패 시 재시도 횟수

작업이 실패할 경우 재시도 횟수를 지정하는 데 사용합니다 retryCountOnTaskFailure . 기본값은 0입니다. 작업 속성에 대한 자세한 내용은 YAML 스키마의 steps.task를 참조하세요.

- task: <name of task>
  retryCountOnTaskFailure: <max number of retries>
   ...

참고 항목

• 에이전트 버전 2.194.0 이상이 필요합니다. 에이전트 없는 작업에는 지원되지 않습니다.
• 실패한 태스크는 몇 초 만에 다시 시도합니다. 각 재시도 사이의 대기 시간은 실패한 각 시도 후에 증가합니다.
• 작업의 멱등성에 대한 가정은 없습니다. 작업에 부작용이 있는 경우(예: 외부 리소스를 부분적으로 만든 경우) 두 번째로 실행할 때 실패할 수 있습니다.
• 작업에 사용할 수 있는 재시도 횟수에 대한 정보는 없습니다.
• 다시 시도하기 전에 실패했음을 나타내는 경고가 작업 로그에 추가됩니다.
• 작업을 다시 시도하려는 모든 시도는 동일한 작업 노드의 일부로 UI에 표시됩니다.

클래식

활성화

이 검사 상자를 선택 취소하여 작업을 사용하지 않도록 설정합니다. 이 기능은 테스트 또는 특정 배포를 위해 프로세스에서 일시적으로 작업을 수행하려는 경우에 유용합니다.

팁

작업을 마우스 오른쪽 단추로 클릭하여 이 설정을 전환할 수도 있습니다.

시간 제한

이 작업의 시간 제한(분)입니다. 기본값은 0(무한 시간 제한)입니다. 0이 아닌 값을 설정하면 부모 작업 작업의 설정이 재정의됩니다. 시간 제한 기간은 작업 실행을 시작할 때 시작됩니다. 태스크가 대기 중이거나 에이전트를 기다리는 시간은 포함되지 않습니다.

Azure Pipelines 옵션

오류 발생 후 계속(부분적으로 성공)

이 작업이 실패하더라도 동일한 작업의 후속 작업을 실행하려면 이 옵션을 선택합니다. 빌드 또는 배포는 부분적으로 성공하는 것보다 낫지 않습니다. 후속 작업 실행 여부는 이 작업 실행 설정에 따라 달라집니다.

작업 실패 시 재시도 횟수

이 작업이 실패할 경우 재시도 횟수를 지정합니다. 기본값은 0입니다.

참고 항목

• 실패한 태스크는 몇 초 만에 다시 시도합니다. 각 재시도 사이의 대기 시간은 실패한 각 시도 후에 증가합니다.
• 작업의 멱등성에 대한 가정은 없습니다. 작업에 부작용이 있는 경우(예: 외부 리소스를 부분적으로 만든 경우) 두 번째로 실행할 때 실패할 수 있습니다.
• 작업에 사용할 수 있는 재시도 횟수에 대한 정보는 없습니다.
• 다시 시도하기 전에 실패했음을 나타내는 경고가 작업 로그에 추가됩니다.
• 작업을 다시 시도하려는 모든 시도는 동일한 작업 노드의 일부로 UI에 표시됩니다.

이 작업 실행

이 작업을 실행하기 위한 조건을 선택합니다.

• 동일한 에이전트 풀을 사용하는 이전의 모든 직접 및 간접 종속성이 성공한 경우에만 가능합니다. 다른 에이전트 풀이 있는 경우 해당 단계 또는 작업이 동시에 실행됩니다. YAML에 설정된 조건이 없는 경우 기본값입니다.

• 이전 종속성이 실패한 경우에도 실행이 취소되지 않은 경우 이 조건에 대해 YAML에서 사용합니다 succeededOrFailed() .

• 이전 종속성이 실패하고 실행이 취소된 경우에도 이 조건에 대해 YAML에서 사용합니다 always() .

• 이전 종속성이 실패한 경우에만 이 조건에 대해 YAML에서 사용합니다 failed() .

• 식으로 구성된 사용자 지정 조건

참고 항목

빌드가 취소된 경우 작업을 실행하는 경우 이러한 태스크가 파이프라인 옵션을 실행할 수 있는 충분한 시간을 지정해야 합니다.

오류 발생 후 계속(부분적으로 성공)

이 작업이 실패하더라도 동일한 작업의 후속 작업을 실행하려면 이 옵션을 선택합니다. 빌드 또는 배포는 부분적으로 성공하는 것보다 낫지 않습니다.

항상 실행

빌드 또는 배포가 실패하더라도 작업을 실행하려면 이 검사 상자를 선택합니다.

환경 변수

YAML

각 작업에는 env 작업 프로세스에 매핑된 환경 변수를 나타내는 문자열 쌍 목록인 속성이 있습니다.

task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
  ENV_VARIABLE_NAME: value
  ENV_VARIABLE_NAME2: value
  ...

다음 예제에서는 명령줄 태스크의 바로 가기인 단계를 실행한 다음 해당 작업 구문을 실행 script 합니다. 이 예제에서는 Azure DevOps CLI를 사용하여 인증하는 데 사용되는 환경 변수에 값을 AZURE_DEVOPS_EXT_PAT 할당합니다.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'

클래식

작업 편집기의 환경 변수 섹션을 사용하여 환경 변수 를 사용할 수 있습니다.

빌드 도구 설치 관리자(Azure Pipelines)

도구 설치 관리자를 사용하면 빌드 파이프라인이 종속성을 설치하고 제어할 수 있습니다. 특히 다음을 수행할 수 있습니다.

• CI 빌드를 위해 즉시(Microsoft 호스팅 에이전트에서도) 도구 또는 런타임을 설치합니다.

• Node.js 같은 여러 종속성 버전에 대해 앱 또는 라이브러리의 유효성을 검사합니다.

예를 들어 빌드 파이프라인을 설정하여 여러 버전의 Node.js 대해 앱을 실행하고 유효성을 검사할 수 있습니다.

예: 여러 버전의 Node.js 앱 테스트 및 유효성 검사

YAML

다음 내용을 사용하여 프로젝트의 기본 디렉터리에 azure-pipelines.yml 파일을 만듭니다.

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

새 빌드 파이프라인 을 만들고 실행합니다. 빌드가 실행되는 방식을 관찰합니다. Node.js 도구 설치 관리자는 에이전트에 아직 없는 경우 Node.js 버전을 다운로드합니다. 명령줄 스크립트는 디스크에서 Node.js 버전의 위치를 기록합니다.

클래식

작업 탭

새 빌드 파이프라인 (빈 프로세스로 시작)을 만들어 이 작업을 시도합니다.

다음 에이전트 설정을 적용합니다.

1. 병렬 처리를 다중 구성으로 설정

2. 승수를 지정합니다.

NodeVersionSpec

3. 최대 에이전트 수를 2로 설정

다음 작업을 추가합니다.

도구: Node.js 설치 관리자

• 버전 사양:

  $(NodeVersionSpec)
  

유틸리티: 명령줄

• 스크립트(Windows 에이전트에서 실행 중인 경우)

  where node
  

• 스크립트(macOS 또는 Linux 에이전트에서 실행 중인 경우)

  which node
  

변수 탭

변수 탭에서 다음 변수를 정의합니다.

속성	값	큐 시간에 설정 가능
NodeVersionSpec	10.x, 12.x	선택한 상태

저장 및 큐에 넣기

저장 큐를 선택합니다. 두 빌드가 실행되는 방식을 관찰합니다. Node.js 도구 설치 관리자는 에이전트에 아직 없는 경우 각 Node.js 버전을 다운로드합니다. 명령줄 태스크는 디스크에서 Node.js 버전의 위치를 기록합니다.

도구 설치 관리자 작업

도구 설치 관리자 작업 목록은 도구 설치 관리자 작업을 참조 하세요.

기본 제공 및 Marketplace 작업 사용 안 함으로 설정

조직 설정 페이지에서 Marketplace 작업, 기본 제공 작업 또는 둘 다를 사용하지 않도록 설정할 수 있습니다. Marketplace 작업을 사용하지 않도록 설정하면 파이프라인의 보안을 강화하는 데 도움이 될 수 있습니다. 기본 제공 작업과 Marketplace 작업을 모두 사용하지 않도록 설정하면 설치 tfx 한 작업만 사용할 수 있습니다.

관련된 문서

• 작업
• 작업 그룹
• 기본 제공 작업 카탈로그

도움말 및 지원 

• 문제 해결 팁을 살펴보세요.
• Stack Overflow에 대한 조언을 얻을 수 있습니다.
• Azure DevOps 개발자 커뮤니티에서 질문을 게시하거나, 답변을 검색하거나, 기능을 제안합니다.
• Azure DevOps에 대한 지원을 받 습니다.