파이프라인 사용자 지정

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

파이프라인을 사용자 지정하는 일반적인 방법에 대한 단계별 가이드입니다.

전제 조건

첫 번째 파이프라인 만들기의 지침에 따라 작업 파이프라인 을 만듭니다.

파일 이해 azure-pipelines.yml

파이프라인은 리포지토리에서 YAML 파일을 사용하여 정의됩니다. 일반적으로 이 파일의 이름은 azure-pipelines.yml 리포지토리의 루트에 있습니다.

Azure Pipelines의 파이프라인 페이지로 이동하고, 만든 파이프라인을 선택하고, 파이프라인의 상황에 맞는 메뉴에서 편집을 선택하여 파이프라인에 대한 YAML 편집기를 엽니다.

참고 항목

Azure DevOps 포털에서 파이프라인을 보고 관리하는 방법에 대한 지침은 파이프라인 보기 및 관리를 참조 하세요.

YAML 파일의 내용을 검사합니다.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@4
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

참고 항목

YAML 파일의 내용은 시작한 샘플 리포지토리 또는 Azure Pipelines에서 수행한 업그레이드에 따라 다를 수 있습니다.

이 파이프라인은 팀이 리포지토리의 주 분기에 변경 내용을 푸시하거나 끌어오기 요청을 만들 때마다 실행됩니다. Microsoft 호스팅 Linux 컴퓨터에서 실행됩니다. 파이프라인 프로세스에는 Maven 작업을 실행하는 단일 단계가 있습니다.

빌드할 플랫폼 변경

다양한 개발 언어에 대한 SDK 및 도구를 이미 포함하는 Microsoft 호스팅 에이전트 에서 프로젝트를 빌드할 수 있습니다. 또는 필요한 특정 도구와 함께 자체 호스팅 에이전트를 사용할 수 있습니다.

• 빌드에서 파이프라인 편집 작업을 선택하거나 파이프라인의 기본 페이지에서 편집을 선택하여 파이프라인의 편집기로 이동합니다.

• 현재 파이프라인은 Linux 에이전트에서 실행됩니다.

  pool:
    vmImage: "ubuntu-latest"
  

• Windows 또는 Mac과 같은 다른 플랫폼을 선택하려면 값을 변경합니다 vmImage .

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• 저장을 선택한 다음 변경 내용을 확인하여 파이프라인이 다른 플랫폼에서 실행되는지 확인합니다.

단계 추가

파이프라인에 단계로 더 많은 스크립트 또는 작업을 추가할 수 있습니다. 작업은 미리 패키지된 스크립트입니다. 앱을 빌드, 테스트, 게시 또는 배포하는 작업을 사용할 수 있습니다. Java의 경우 사용한 Maven 태스크는 테스트 및 게시 결과를 처리합니다. 그러나 태스크를 사용하여 코드 검사 결과도 게시할 수 있습니다.

• 파이프라인에 대한 YAML 편집기를 엽니다.

• YAML 파일의 끝에 다음 코드 조각을 추가합니다.

  - task: PublishCodeCoverageResults@1
    inputs:
      codeCoverageTool: "JaCoCo"
      summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml"
      reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco"
      failIfCoverageEmpty: true
  

• 저장을 선택한 다음 변경 내용을 확인합니다.

• 빌드를 선택하고 테스트 및 검사 탭으로 이동하여 테스트 및 코드 검사 결과를 볼 수 있습니다.

여러 플랫폼에서 빌드

여러 플랫폼에서 프로젝트를 빌드하고 테스트할 수 있습니다. 그것을 할 수있는 한 가지 방법은 함께 strategy 하는 것입니다.matrix 변수를 사용하여 데이터를 파이프라인의 다양한 부분에 편리하게 배치할 수 있습니다. 이 예제에서는 변수를 사용하여 사용하려는 이미지의 이름을 전달합니다.

• 파일에서 다음 콘텐츠를 대체합니다 azure-pipelines.yml .

  pool:
    vmImage: "ubuntu-latest"
  

  다음 콘텐츠 포함:

  strategy:
    matrix:
      linux:
        imageName: "ubuntu-latest"
      mac:
        imageName: "macOS-latest"
      windows:
        imageName: "windows-latest"
    maxParallel: 3
  
  pool:
    vmImage: $(imageName)
  

• 저장을 선택한 다음, 변경 내용을 확인하여 빌드가 세 개의 다른 플랫폼에서 최대 3개의 작업을 실행하는지 확인합니다.

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

여러 버전을 사용하여 빌드

다른 버전의 해당 언어를 사용하여 프로젝트를 빌드하려면 버전과 변수를 matrix 사용할 수 있습니다. 이 단계에서는 단일 플랫폼에서 두 가지 버전의 Java로 Java 프로젝트를 빌드하거나 다른 플랫폼에서 다른 버전의 Java를 실행할 수 있습니다.

참고 항목

컨텍스트에서 여러 번 사용할 strategy 수 없습니다.

• 단일 플랫폼 및 여러 버전에서 빌드하려면 Maven 작업 앞과 vmImage뒤에 다음 매트릭스를 파일에 추가합니다azure-pipelines.yml.

  strategy:
    matrix:
      jdk10:
        jdkVersion: "1.10"
      jdk11:
        jdkVersion: "1.11"
    maxParallel: 2
  

• 그런 다음, maven 작업에서 이 줄을 바꿉다.

  jdkVersionOption: "1.11"
  

  이 줄로 다음을 수행합니다.

  jdkVersionOption: $(jdkVersion)
  

• 변수를 $(imageName) 원하는 플랫폼으로 다시 변경해야 합니다.

• 여러 플랫폼 및 버전에서 빌드하려면 게시 작업 전에 파일의 전체 콘텐츠를 azure-pipelines.yml 다음 코드 조각으로 바꿉니다.

  trigger:
  - main
  
  strategy:
    matrix:
      jdk10_linux:
        imageName: "ubuntu-latest"
        jdkVersion: "1.10"
      jdk11_windows:
        imageName: "windows-latest"
        jdkVersion: "1.11"
    maxParallel: 2
  
  pool:
    vmImage: $(imageName)
  
  steps:
  - task: Maven@4
    inputs:
      mavenPomFile: "pom.xml"
      mavenOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: $(jdkVersion)
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/TEST-*.xml"
      goals: "package"
  

• 저장을 선택한 다음, 변경 내용을 확인하여 빌드가 서로 다른 두 플랫폼과 SDK에서 두 개의 작업을 실행하는지 확인합니다.

CI 트리거 사용자 지정

파이프라인 트리거로 인해 파이프라인이 실행됩니다. 분기로 업데이트를 푸시할 때마다 파이프라인이 실행되도록 하는 데 사용할 trigger: 수 있습니다. YAML 파이프라인은 기본적으로 기본 분기 CI 트리거(일반적으로main)로 구성됩니다. 특정 분기 또는 끌어오기 요청 유효성 검사에 대한 트리거를 설정할 수 있습니다. 끌어오기 요청 유효성 검사 트리거의 trigger: 경우 아래 두 예제와 pr: 같이 단계를 바꿉니다. 기본적으로 파이프라인은 각 끌어오기 요청 변경에 대해 실행됩니다.

• 트리거를 설정하려면 파일 시작 부분에 다음 코드 조각 중 하나를 추가합니다 azure-pipelines.yml .

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  분기의 전체 이름(예 main: ) 또는 접두사와 일치하는 와일드카드(예: releases/*)를 지정할 수 있습니다.

파이프라인 설정

파이프라인 세부 정보 페이지의 추가 작업 메뉴에서 파이프라인 설정을 보고 구성할 수 있습니다.

• 보안 관리 보안 - 관리
• 이름 바꾸기/이동 - 파이프라인 이름 및 폴더 위치를 편집합니다.
• 상태 배지 - 리포지토리에 상태 배지 추가
• 삭제 - 모든 빌드 및 연결된 아티팩트가 포함된 파이프라인을 삭제합니다.
• 예약된 실행 - 예약 실행 보기

설정을 선택하여 다음 파이프라인 설정을 구성합니다.

파이프라인 설정 창에서 다음 설정을 구성할 수 있습니다.

• 새 실행 요청 처리 - 파이프라인에서 새 실행이 시작되지 않도록 하는 경우가 있습니다.

  • 기본적으로 새 실행 요청의 처리는 Enabled입니다. 이 설정을 사용하면 수동 실행을 포함하여 모든 트리거 형식을 표준으로 처리할 수 있습니다.
  • 일시 중지된 파이프라인을 사용하면 실행 요청을 처리할 수 있지만 이러한 요청은 실제로 시작하지 않고 큐에 대기됩니다. 새 요청 처리를 사용하도록 설정하면 큐의 첫 번째 요청부터 실행 처리가 다시 시작됩니다.
  • 사용하지 않도록 설정된 파이프라인은 사용자가 새 실행을 시작하지 못하도록 합니다. 이 설정이 적용되는 동안에는 모든 트리거도 사용하지 않도록 설정됩니다. 사용하지 않도록 설정된 파이프라인을 사용하는 모든 빌드 정책에는 PR 개요 창의 빌드 정책 옆에 "빌드를 큐에 대기할 수 없음" 메시지가 표시되고 빌드 정책의 상태가 손상됩니다.

• YAML 파일 경로 - 파이프라인에 다른 YAML 파일을 사용하도록 지시해야 하는 경우 해당 파일의 경로를 지정할 수 있습니다. 이 설정은 YAML 파일을 이동/이름을 변경해야 하는 경우에도 유용할 수 있습니다.

• 이 실행에 포함된 작업 항목을 자동으로 연결 - 지정된 파이프라인 실행과 연결된 변경 내용에 연결된 작업 항목이 있을 수 있습니다. 해당 작업 항목을 실행에 연결하려면 이 옵션을 선택합니다. 이 실행에 포함된 작업 항목을 자동으로 연결하는 경우 특정 분기 또는 * 기본값인 모든 분기를 지정해야 합니다. 분기를 지정하는 경우 작업 항목은 해당 분기의 실행과만 연결됩니다. 지정 *하는 경우 작업 항목은 모든 실행에 대해 연결됩니다.

  

  • 실행이 실패할 때 알림을 받으려면 팀에 대한 알림을 관리하는 방법을 참조하세요.

보안 관리

파이프라인 방문 페이지의 추가 작업 및 파이프라인 세부 정보 페이지의 파이프라인 수준에서 프로젝트 수준에서 파이프라인 보안을 구성할 수 있습니다.

파이프라인 작업의 보안을 지원하려면 기본 제공 보안 그룹에 사용자를 추가하거나, 사용자 또는 그룹에 대한 개별 권한을 설정하거나, 미리 정의된 역할에 사용자를 추가할 수 있습니다. 사용자 또는 관리자 컨텍스트에서 웹 포털에서 Azure Pipelines에 대한 보안을 관리할 수 있습니다. 파이프라인 보안을 구성하는 방법에 대한 자세한 내용은 파이프라인 권한 및 보안 역할을 참조 하세요.

실패할 때 작업 항목 만들기

YAML 파이프라인에는 클래식 빌드 파이프라인과 같은 오류 설정에 대한 만들기 작업 항목이 없습니다. 클래식 빌드 파이프라인은 단일 단계이며 실패 할 때 작업 항목 만들기는 전체 파이프라인에 적용됩니다. YAML 파이프라인은 다단계일 수 있으며 파이프라인 수준 설정이 적절하지 않을 수 있습니다. YAML 파이프라인에서 실패 시 작업 항목 만들기를 구현하려면 작업 항목 - REST API 호출 만들기 또는 Azure DevOps CLI az boards 작업 항목 만들기 명령과 같은 메서드를 파이프라인의 원하는 지점에서 사용할 수 있습니다.

다음 예제에는 두 개의 작업이 있습니다. 첫 번째 작업은 파이프라인의 작업을 나타내지만 실패하면 두 번째 작업이 실행되고 파이프라인과 동일한 프로젝트에 버그가 만들어집니다.

# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
  displayName: Succeed or fail
  type: boolean
  default: false

trigger:
- main

pool:
  vmImage: ubuntu-latest

jobs:
- job: Work
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'

  # This malformed command causes the job to fail
  # Only run this command if the succeed variable is set to false
  - script: git clone malformed input
    condition: eq(${{ parameters.succeed }}, false)

# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
  dependsOn: Work
  condition: failed()
  steps: 
  - bash: |
      az boards work-item create \
        --title "Build $(build.buildNumber) failed" \
        --type bug \
        --org $(System.TeamFoundationCollectionUri) \
        --project $(System.TeamProject)
    env: 
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
    displayName: 'Create work item on failure'

참고 항목

Azure Boards를 사용하면 Agile 또는 Basic과 같은 여러 다른 프로세스를 사용하여 작업 항목 추적을 구성할 수 있습니다. 각 프로세스에는 작업 항목 유형이 다르며 각 프로세스에서 모든 작업 항목 유형을 사용할 수 있는 것은 아닙니다. 각 프로세스에서 지원하는 작업 항목 유형 목록은 WIT(작업 항목 유형)를 참조하세요.

이전 예제에서는 런타임 매개 변수를 사용하여 파이프라인의 성공 또는 실패 여부를 구성합니다. 파이프라인을 수동으로 실행할 때 매개 변수 값을 succeed 설정할 수 있습니다. 파이프라인의 첫 번째 작업에서 두 번째 script 단계는 매개 변수를 succeed 평가하고 false로 설정된 경우에만 실행됩니다 succeed .

파이프라인의 두 번째 작업은 첫 번째 작업에 대한 종속성을 가지며 첫 번째 작업이 실패하는 경우에만 실행됩니다. 두 번째 작업은 Azure DevOps CLI az boards work-item create 명령을 사용하여 버그를 만듭니다. 파이프라인에서 Azure DevOps CLI 명령을 실행하는 방법에 대한 자세한 내용은 YAML 파이프라인에서 명령 실행을 참조하세요.

이 예제에서는 두 개의 작업을 사용하지만 여러 단계에서 동일한 방법을 사용할 수 있습니다.

참고 항목

YAML 다단계 파이프라인을 지원하는 릴리스 시 버그 만들기 오류와 같은 마켓플레이스 확장을 사용할 수도 있습니다.

다음 단계

파이프라인 사용자 지정의 기본 사항을 알아보았습니다. 다음으로 사용하는 언어에 대한 파이프라인 사용자 지정에 대해 자세히 알아보는 것이 좋습니다.

• .NET Core
• 컨테이너
• Go
• Java
• Node.JS
• Python

또는 CI 파이프라인을 CI/CD 파이프라인으로 확장하려면 환경에 앱을 배포하는 단계가 포함된 배포 작업을 포함합니다.

이 가이드의 항목에 대한 자세한 내용은 작업, 작업, 작업 카탈로그, 변수, 트리거 또는 문제 해결을 참조하세요.

YAML 파이프라인에서 수행할 수 있는 다른 작업에 대한 자세한 내용은 YAML 스키마 참조를 참조하세요.