작업 유형 사용

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

참고

Microsoft TFS(Team Foundation Server) 2018 이하 버전에서 빌드 및 릴리스 ‘파이프라인’은 ‘정의’라고 하며 ‘실행’은 ‘빌드’, ‘서비스 연결’은 ‘서비스 엔드포인트’, ‘스테이지’는 ‘환경’, ‘작업’은 ‘단계’라고 합니다.

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

파이프라인에 작업을 추가할 때 파이프라인에 일련의 요구 사항을 추가할 수도 있습니다. 요구 사항은 작업을 실행하기 위해 에이전트 에 설치해야 하는 필수 구성 요소를 정의합니다. 빌드 또는 배포를 실행하면 이러한 요구를 충족하는 에이전트가 선택됩니다.

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

기본적으로 모든 작업은 호스트 에 있든 작업 컨테이너에 있든 동일한 컨텍스트에서 실행됩니다. 필요에 따라 단계 대상을 사용하여 개별 작업에 대한 컨텍스트를 제어할 수 있습니다.

기본 제공 작업을 사용하여 작업에 대한 속성을 지정하는 방법에 대한 Mer informasjon.

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

사용자 지정 작업

기본 빌드 및 배포 시나리오를 사용하도록 설정하는 몇 가지 기본 제공 작업을 제공합니다. 사용자 고유의 사용자 지정 작업을 만들기 위한 지침도 제공했습니다.

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

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

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

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

작업 버전

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

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

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

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

steps:
- task: PublishTestResults@2

YAML 파이프라인은 TFS에서 사용할 수 없습니다.

작업 제어 옵션

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

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

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task

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

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

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

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  retryCountOnTaskFailure: number # Max number of retries; default is zero
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

참고

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

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

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

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

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.7'
    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.8

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

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

작업이 실패한 경우 재시도 횟수

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

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

참고

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

YAML 파이프라인은 TFS에서 사용할 수 없습니다.

환경 변수

YAML 파이프라인은 Azure DevOps Server 2019 이상에서 지원됩니다.

각 작업에는 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 앱 테스트 및 유효성 검사

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

pool:
  vmImage: 'Ubuntu 16.04'

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '6.x' # The version we're installing
# Write the installed version to the command line
- script: which node

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

YAML 파이프라인은 TFS에서 사용할 수 없습니다.

도구 설치 관리자 작업

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

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

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

도움말 및 지원