파이프라인 스테이지 이해

  • 7분

Pipelines를 사용하면 배포 프로세스의 단계를 자동화할 수 있습니다. 실행하려는 작업의 여러 논리 그룹이 프로세스에 포함될 수 있습니다. 이 단원에서는 파이프라인 스테이지 및 파이프라인 스테이지를 사용하여 Bicep 배포에 품질 제어 프로세스를 추가하는 방법을 알아봅니다.

파이프라인 스테이지란?

스테이지를 사용하면 파이프라인을 여러 논리 블록으로 나눌 수 있습니다. 각 스테이지에는 하나 이상의 작업이 포함될 수 있습니다. 작업에는 명령줄 스크립트 실행과 같이 완료해야 하는, 순서가 지정된 단계 목록이 포함되어 있습니다.

Diagram that shows a pipeline with a stage containing one job. The job contains four steps.

파이프라인에서 스테이지를 사용하여 관심사의 격리를 표시할 수 있습니다. 예를 들어 Bicep 코드를 작업할 때 코드의 ‘유효성 검사’는 Bicep 파일 ‘배포’와는 별도의 관심사입니다. 자동화된 파이프라인을 사용하는 경우 코드를 빌드하고 테스트하는 것을 보통 CI(‘지속적인 통합’)라고 합니다. 자동화된 파이프라인에서 코드를 배포하는 것을 CD(‘지속적인 배포’)라고 합니다.

CI 스테이지에서는 코드 변경 내용의 유효성을 검사합니다. CI 스테이지에서는 품질 보증을 제공합니다. 라이브 프로덕션 환경에 영향을 주지 않고 CI 작업을 실행할 수 있습니다.

많은 프로그래밍 언어에서는 코드를 먼저 빌드해야 누군가가 코드를 실행할 수 있습니다. Bicep 파일은 배포되면 Bicep에서 JSON으로 변환 또는 ‘변환 컴파일’됩니다. 해당 도구는 이 프로세스를 자동으로 수행합니다. 대부분의 경우 파이프라인 내에서 JSON 템플릿에 Bicep 코드를 수동으로 빌드할 필요가 없습니다. 하지만 CI의 다른 부분(예: 코드 유효성 검사)이 계속 적용되므로 Bicep 코드에 대해 설명할 때 여전히 ‘지속적인 통합’이라는 용어를 사용합니다.

CI 스테이지가 성공적으로 실행되면 변경 내용이 성공적으로 배포될 것이라는 신뢰가 높아집니다. CD 스테이지에서는 각 환경에 코드를 배포합니다. 일반적으로 테스트 및 기타 비프로덕션 환경으로 시작한 후 프로덕션 환경으로 이동합니다. 이 모듈에서는 단일 환경에 배포합니다. 비프로덕션 및 프로덕션 환경과 같은 여러 환경에 배포하도록 배포 파이프라인을 확장하는 방법은 뒤에 나오는 모듈에서 알아보겠습니다.

스테이지는 순서대로 실행됩니다. 각 스테이지가 실행되는 방법과 시기를 제어할 수 있습니다. 예를 들어 CI 스테이지가 성공적으로 실행된 후에만 실행되도록 CD 스테이지를 구성할 수 있습니다. 또는 코드를 빌드한 후 테스트하는 것처럼 순서대로 실행해야 하는 여러 CI 스테이지가 있을 수 있습니다. 이전 배포 스테이지가 실패한 경우에만 실행되는 ‘롤백’ 스테이지를 포함할 수도 있습니다.

왼쪽으로 이동

스테이지를 사용하면 코드를 배포하기 전에 코드의 품질을 확인할 수 있습니다. 이러한 스테이지를 ‘시프트 레프트’라고도 합니다.

코드를 작성할 때에는 수행하는 작업의 타임라인을 고려합니다. 타임라인은 계획 및 디자인 단계에서 시작됩니다. 그런 다음, 빌드 및 테스트 단계로 이동합니다. 마지막으로 솔루션을 배포한 후에는 지원을 해야 합니다.

Chart with a timeline on the horizontal axis, cost on the vertical axis, and a line showing that the cost increases the later an error is identified.

프로세스 초기에 오류를 발견할수록, 즉, 오류 발견 시기가 타임라인의 왼쪽에 가까울수록 오류를 더 쉽고 빠르고 낮은 비용으로 해결할 수 있다는 것은 소프트웨어 개발에서 잘 알려진 규칙입니다. 프로세스에서 오류를 늦게 발견할수록 오류를 수정하기가 더 어렵습니다.

따라서 문제 발견 시기를 이전 다이어그램의 왼쪽으로 이동하는 것이 목표입니다. 이 모듈에서는 파이프라인을 진행하면서 파이프라인에 점점 더 많은 유효성 검사 및 테스트를 추가하는 방법을 알아볼 것입니다.

배포가 시작되기 전에 유효성 검사도 추가할 수 있습니다. Azure DevOps 같은 도구를 사용할 때 끌어오기 요청은 일반적으로 팀원 중 누군가가 기본 분기의 코드에 대해 수행하려는 변경 내용을 나타냅니다. 끌어오기 요청 검토 프로세스 중에 CI 단계를 자동으로 실행하는 다른 파이프라인을 만드는 것이 좋습니다. 이 기법을 사용하면 팀원의 제안대로 변경하더라도 코드가 여전히 작동하는지 확인할 수 있습니다. 유효성 검사가 성공하면 변경 내용을 기본 분기에 병합해도 문제가 발생하지 않는다고 어느 정도 자신할 수 있습니다. 검사가 실패하면 끌어오기 요청을 병합하기에는 아직 수행할 작업이 남아 있다는 것을 알 수 있습니다.

중요

자동화된 유효성 검사 및 테스트는 사용자가 작성하는 테스트만큼만 유효합니다. 배포가 정상적으로 이루어진다고 확신하기 위해 테스트해야 하는 사항과 수행해야 하는 단계를 고려하는 것이 중요합니다.

파이프라인 스테이지 정의

모든 파이프라인에는 하나 이상의 스테이지가 있습니다. 파이프라인에 스테이지가 하나뿐인 경우에는 명시적으로 정의할 필요가 없습니다. Azure Pipelines에서 자동으로 정의합니다. 파이프라인에 여러 스테이지가 있는 경우에는 각 스테이지를 정의해야 합니다. 스테이지는 사용자가 지정하는 순서대로 실행됩니다.

미국의 인프라에 한 번, 유럽의 인프라에 한 번, 총 두 번 배포해야 하는 Bicep 파일을 빌드했다고 가정하겠습니다. 배포하기 전에 Bicep 코드의 유효성을 검사합니다. 다음은 이 프로세스를 정의하는 다중 스테이지 파이프라인의 일러스트레이션입니다.

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, running in sequence.

이 예제에는 3개의 스테이지가 있습니다. 유효성 검사 스테이지는 CI 스테이지와 비슷합니다. 다음으로, DeployUS 및 DeployEurope 스테이지가 실행됩니다. 각 Deploy는 환경 중 하나에 코드를 배포합니다.

파이프라인 YAML 파일에서 스테이지를 정의하는 방법은 다음과 같습니다.

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

스테이지의 순서 제어

기본적으로 스테이지는 사용자가 정의한 순서대로 실행됩니다. 스테이지는 이전 스테이지가 성공한 경우에만 실행됩니다. 스테이지 간의 종속성을 추가하여 순서를 변경할 수 있습니다.

이전 예제를 계속 이어서, 다음과 같이 두 가지 배포를 동시에 실행하려 한다고 가정하겠습니다.

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, with the two deployment stages running in parallel.

dependsOn 키워드를 사용하여 스테이지 간의 종속성을 지정할 수 있습니다.

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

dependsOn 키워드를 사용하는 경우 Azure Pipelines는 종속 스테이지가 성공적으로 완료되기를 기다렸다가 그 다음 스테이지를 시작합니다. Azure Pipelines는 여러 스테이지의 모든 종속성이 충족된 것으로 감지되면 해당 스테이지를 병렬로 실행할 수 있습니다.

참고

실제로 여러 작업을 동시에 실행할 수 있는 에이전트가 충분한 경우에만 스테이지와 작업이 병렬로 실행됩니다. Microsoft 호스팅 에이전트를 사용하는 경우 이렇게 하려면 추가 ‘병렬 작업’을 구매해야 할 수도 있습니다.

상황에 따라 이전 스테이지가 실패할 때 스테이지를 실행하려는 경우도 있습니다. 예를 들어 다음은 다른 파이프라인입니다. 배포가 실패하면 그 즉시 롤백이라는 스테이지가 실행됩니다.

Diagram that shows a pipeline with a Deploy stage, and a condition so that a failure in the Deploy stage results in the Rollback stage running.

condition 키워드를 사용하여 스테이지를 실행하려면 충족해야 하는 조건을 지정할 수 있습니다.

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

위의 예제에서 모든 것이 정상적으로 진행되면 Azure Pipelines는 유효성 검사 스테이지를 실행한 다음, 배포 스테이지를 실행합니다. Azure Pipelines는 롤백 스테이지를 건너뜁니다. 그러나 배포 스테이지가 실패하면 Azure Pipelines는 롤백 스테이지를 실행합니다. 롤백에 대한 내용은 이 모듈의 뒷부분에서 자세히 알아보겠습니다.

모든 작업은 새 에이전트에서 실행됩니다. 즉, 모든 작업은 정상 환경에서 시작되므로 일반적으로 모든 작업에서 첫 번째 단계로 소스 코드를 체크 아웃해야 합니다.

Bicep 배포 스테이지

일반적인 Bicep 배포 파이프라인에는 여러 스테이지가 포함됩니다. 파이프라인의 스테이지가 진행될수록 이후 스테이지가 성공할 것이라는 확신이 점점 커집니다. 다음은 Bicep 배포 파이프라인의 일반적인 스테이지입니다.

Diagram that shows a Bicep deployment pipeline with five stages: Lint, Validate, Preview, Deploy, and Smoke Test.

  1. 린팅: Bicep Linter를 사용하여 Bicep 파일이 올바르게 작성되었으며 명백한 오류가 없는지 확인합니다.
  2. 유효성 검사: Azure Resource Manager 실행 전 유효성 검사 프로세스를 사용하여 배포 시 발생할 수 있는 문제를 확인합니다.
  3. 미리 보기: what-if 명령을 사용하여 Azure 환경에 적용할 변경 내용 목록의 유효성을 검사합니다. 사람이 수동으로 가상 결과를 검토하고 파이프라인 진행을 승인하도록 요청합니다.
  4. 배포: 배포를 Resource Manager에 제출하고 완료되기를 기다립니다.
  5. 스모크 테스트: 배포한 중요 리소스 중 일부에 대해 기본적인 배포 후 검사를 실행합니다. 이러한 검토를 ‘인프라 스모크 테스트’라고 합니다.

조직의 스테이지 순서가 다르거나 다른 구성 요소를 배포하는 파이프라인에 Bicep 배포를 통합해야 할 수도 있습니다. 스테이지가 작동하는 방식을 이해한 후에는 요구 사항에 맞게 파이프라인을 디자인할 수 있습니다.

이 모듈에서는 여기에 나오는 스테이지에 대해 자세히 알아보고 각 스테이지를 포함하는 파이프라인을 점진적으로 빌드할 것입니다. 또한 다음에 대해 알아봅니다.

  • 이전 스테이지에서 예기치 않은 상황이 발생하는 경우 파이프라인이 배포 프로세스를 중지하는 방법
  • 이전 단계에서 변경된 내용을 수동으로 확인할 때까지 일시 중지하도록 파이프라인을 구성하는 방법