Azure Pipelines 이해

완료됨

파이프라인을 사용하여 배포 프로세스의 단계를 자동화할 수 있습니다. 코드를 변경하고 Git 리포지토리에 변경 내용을 커밋할 때마다 파이프라인은 미리 정의된 프로세스를 실행합니다. 파이프라인은 Bicep 코드가 품질 표준을 충족하는지 확인할 수 있으며, 이후 Azure에 리소스를 배포하는 단계를 자동화합니다. 프로세스는 사용자가 만드는 파이프라인 정의에서 정의됩니다.

Azure Pipelines은 Azure DevOps 서비스의 기능입니다. 또한 Azure DevOps에는 코드를 저장하고 협력자와 공유하기 위해 사용하는 Git 리포지토리를 호스트하는 Azure Repos가 포함됩니다. Bicep 코드를 Git에 저장하면 Azure Pipelines는 코드에 액세스하여 배포 프로세스를 자동화할 수 있습니다. 이 단원에서는 Azure Pipelines에 대해 알아봅니다.

파이프라인이란?

파이프라인은 구성 파일에 정의된 코드를 테스트하고 배포하는 데 사용할 수 있는 반복적인 프로세스입니다. 파이프라인에는 실행하려는 모든 단계가 순서대로 포함됩니다.

Azure Pipelines에서 작업할 경우 YAML 파일을 사용하여 파이프라인을 설명합니다. YAML 파일은 구조적 텍스트 파일이며, 이는 Bicep이 구조적 텍스트 파일인 것과 비슷합니다. 모든 텍스트 편집기를 사용하여 YAML 파일을 만들고 편집할 수 있습니다. 이 모듈에서는 Visual Studio Code를 사용합니다. Visual Studio Code는 Azure DevOps YAML 파이프라인 파일을 더 쉽게 편집할 수 있는 확장을 제공합니다. 또한 Azure DevOps 웹 인터페이스는 파이프라인 YAML 파일을 보고 편집하는 데 사용할 수 있는 몇 가지 도구를 제공합니다.

참고

Azure Pipelines에는 이전 버전의 파이프라인 기능인 클래식 파이프라인이 포함되어 있습니다. YAML 기반 파이프라인이 클래식 파이프라인을 대체합니다. 이 모듈에서는 YAML 파이프라인에 대해서만 설명합니다. YAML 파이프라인을 사용하는 것이 좋습니다.

파이프라인 YAML 파일이 코드 파일이기 때문에 파일은 Git 리포지토리에 Bicep 코드와 함께 저장됩니다. Git 기능을 사용하여 파이프라인 정의에 대한 공동 작업을 수행할 수 있습니다. 커밋 및 분기를 사용하여 다양한 버전의 파이프라인 파일을 관리할 수 있습니다. 이후 모듈에서는 템플릿과 같은 파이프라인의 다른 고급 기능에 대해서도 알아봅니다. 템플릿을 통해 파이프라인 정의를 쉽게 재사용할 수 있습니다.

에이전트 및 풀

지금까지는 로컬 컴퓨터에서 Bicep 파일을 배포했습니다. Bicep 템플릿을 쓴 후에는 이를 Azure CLI나 Azure PowerShell을 사용하여 Azure에 배포합니다. 이러한 도구는 컴퓨터의 리소스를 사용하여 템플릿을 Azure에 제출합니다. 도구는 사용자의 개인 ID를 사용하여 Azure에 인증하고 리소스를 배포할 수 있는 권한이 있는지 확인합니다.

파이프라인은 또한 배포 단계를 실행할 수 있도록 컴퓨터에 액세스해야 합니다. Azure Pipelines은 에이전트라는 컴퓨터를 사용합니다. 에이전트는 파이프라인에 대한 배포 단계를 실행하도록 구성된 컴퓨터입니다. 각 에이전트는 이전 모듈에서 사용한 Bicep 및 Azure 도구를 이미 가지고 있으므로 사용자의 컴퓨터에서 수행하는 것과 동일한 작업을 수행할 수 있습니다. 사람이 명령을 실행하는 대신 Azure Pipelines 서비스가 YAML 파일로 정의한 단계를 실행하도록 에이전트에 지시합니다.

Azure Pipelines에서는 Ubuntu 또는 Windows와 같은 다양한 운영 체제를 위한 여러 유형의 에이전트와 도구 집합을 사용할 수 있습니다. Microsoft가 이러한 에이전트를 실행하므로 사용자는 에이전트용 컴퓨팅 인프라를 유지 관리하지 않아도 됩니다. 사용자를 대신하여 호스트되기 때문에 Microsoft 호스팅 에이전트 또는 호스트된 에이전트라고도 합니다. 파이프라인이 실행되면 호스트된 에이전트가 자동으로 만들어집니다. 파이프라인 실행이 완료되면 호스트된 에이전트가 자동으로 삭제됩니다. 호스트된 에이전트에 직접 액세스할 수 없으므로 파이프라인에 솔루션을 배포하는 데 필요한 모든 단계가 포함되어야 합니다.

에이전트 풀은 동일한 유형의 여러 에이전트를 포함합니다. 파이프라인을 만들 때 각 단계 집합을 실행하는 데 사용할 에이전트 풀을 Azure Pipelines에 알려줍니다. 파이프라인이 실행되면 풀에서 에이전트를 사용할 수 있을 때까지 기다린 다음 배포 단계를 실행하도록 에이전트에 지시합니다. 파이프라인을 실행하기 위해 풀의 모든 에이전트를 할당할 수 있습니다.

Diagram that shows a pipeline that runs on an agent within an agent pool.

참고 항목

자체 호스팅 에이전트라고 하는 사용자 지정 에이전트를 만드는 옵션이 있습니다. 파이프라인의 일부로 실행해야 하는 특정 소프트웨어가 있거나 에이전트 구성 방식을 정확하게 제어해야 하는 경우 자체 호스팅 에이전트를 만들 수 있습니다. 이 모듈에서는 자체 호스팅 에이전트에 대해 논의하지 않지만 요약에서 자세한 정보에 대한 링크를 제공합니다.

트리거

파이프라인을 실행할 시기를 Azure Pipelines에 지시하려면 트리거를 사용합니다. 여러 유형의 트리거 중에서 선택할 수 있습니다. 지금은 수동 트리거를 사용합니다. 파이프라인 실행을 시작할 시기를 Azure Pipelines에 수동으로 알려야 합니다. 이 모듈의 후반부에서 다른 트리거에 대해 알아봅니다.

Diagram that shows a trigger initiating a pipeline.

단계

단계는 파이프라인이 수행할 단일 작업을 나타냅니다. 단계는 Bash 또는 PowerShell에서 실행하는 개별 명령과 비슷합니다. 대부분의 배포에서는 여러 단계를 순서대로 실행합니다. 파이프라인 YAML 파일에서 각 단계의 시퀀스 및 모든 세부 정보를 정의합니다.

Azure Pipelines는 두 가지 유형의 단계를 제공합니다.

  • 스크립트. Bash, PowerShell 또는 Windows 명령 셸에서 단일 명령 또는 명령 시퀀스를 실행하려면 스크립트 단계를 사용합니다.
  • 작업. 작업을 사용하면 스크립트 명령문을 작성하지 않아도 다양한 기능에 편리하게 액세스할 수 있습니다. 예를 들어 기본 제공 작업은 Azure CLI 및 Azure PowerShell cmdlet을 실행하여 코드를 테스트하거나 파일을 FTP 서버에 업로드할 수 있습니다. 누구라도 작업을 작성하고 Visual Studio Marketplace에 작업을 게시하여 다른 사용자와 공유할 수 있습니다. 방대한 상용 및 오픈 소스 작업을 사용할 수 있습니다.

일부 사용자는 기본 제공 작업보다는 스크립트 명령문을 선호하는데, 이는 실행된 작업을 정확하게 제어할 수 있기 때문입니다. 스크립트를 작성하고 관리할 필요가 없도록 작업을 사용하는 것을 선호하는 사용자도 있습니다. 이 모듈에서는 두 방법을 혼합하여 사용합니다.

작업

Azure Pipelines에서 작업은 정렬된 단계 집합을 나타냅니다. 파이프라인에는 항상 하나 이상의 작업이 있으며 복잡한 배포를 만들 때는 작업이 두 개 이상 있는 것이 일반적입니다.

참고

각 작업이 다른 에이전트 풀에서 실행되도록 설정할 수 있습니다. 작업을 서로 다른 풀에서 실행하는 것은 작업 파이프라인의 여러 부분에서 서로 다른 운영 체제를 사용해야 하는 솔루션을 빌드하고 배포할 때 유용합니다.

예를 들어 iOS 앱과 앱 백엔드 서비스를 빌드한다고 가정합니다. iOS 앱을 빌드하기 위해 macOS 에이전트 풀에서 실행되는 작업 하나가 있고, 백엔드를 빌드하기 위해 Ubuntu 또는 Windows 에이전트 풀에서 실행되는 다른 작업이 있을 수 있습니다. 두 작업을 동시에 실행하도록 파이프라인에 지시하여 파이프라인의 실행 속도를 높일 수도 있습니다.

이 모듈에서는 파이프라인 정의 파일의 루트에 에이전트 풀을 선언하므로 파이프라인의 모든 작업은 동일한 에이전트 풀을 사용합니다.

Diagram that shows a pipeline with two steps, both within one job.

참고 항목

또한 Azure Pipelines의 스테이지를 사용하여 파이프라인을 논리적 단계로 나누고 파이프라인 실행의 다양한 지점에서 수동 검사를 추가할 수 있습니다. 이후 모듈에서 스테이지에 대해 더 자세히 알아봅니다.

기본 파이프라인 예제

이제 Azure Pipelines의 기본 개념을 알게 됐으므로 YAML의 간단한 파이프라인 정의를 살펴보겠습니다.

trigger: none

pool:
  vmImage: ubuntu-latest

jobs:
- job:
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'
  
  - script: |
      echo We'll add more steps soon.
      echo For example, we'll add our Bicep deployment step.
    displayName: 'Run a multi-line script'

파일의 각 부분을 자세히 살펴보겠습니다.

  • trigger는 파이프라인을 실행할 시기를 알려 줍니다. 이 경우 trigger: none는 Azure Pipelines에 파이프라인을 수동으로 트리거하도록 지시합니다.
  • pool은(는) 파이프라인 단계를 실행하는 경우 사용할 에이전트 풀을 파이프라인에 지시합니다. 이 예제에서 파이프라인은 Ubuntu 운영 체제를 실행하는 에이전트에서 실행되며, 이는 Microsoft 호스팅 에이전트 풀에서 제공됩니다.
  • jobs는 파이프라인의 모든 작업을 그룹화합니다.
  • job은(는) 파이프라인에 단일 작업이 있음을 알릴 수 있습니다.

    파이프라인에 작업이 하나만 있는 경우 jobsjob 키워드를 생략할 수 있습니다. 여기서는 파이프라인에서 개념들이 함께 작동하는 방식을 명확하게 보여주기 위해 job를 포함시켰습니다.

  • steps는 작업 내에서 실행할 동작의 시퀀스를 나열합니다. 예제 YAML에는 두 단계가 포함됩니다. 두 단계 모두 일부 텍스트를 에코하는 간단한 스크립트를 실행합니다. 각 단계에는 사람이 읽을 수 있는 단계 이름인 displayName이 있습니다. 파이프라인 로그를 보면 표시 이름을 볼 수 있습니다. 여러 줄 스크립트 단계를 만들려면 예제와 같이 파이프 문자(|)를 사용합니다. 단계가 실행된 후에 파이프라인 로그에 출력이 표시됩니다.

중요

YAML 파일에는 들여쓰기가 중요합니다. 예제 YAML을 한번 보세요. YAML에서 일부 줄은 두 개 또는 네 개의 공백으로 들여쓰기 됩니다. 사용하는 공백 수가 중요합니다. 들여쓰기를 제대로 하지 않으면 Azure Pipelines가 파일을 해석할 수 없습니다. Visual Studio Code는 YAML 파일 들여쓰기에서 오류를 찾고 수정하는 데 도움이 됩니다.