파이프라인 디자인 - Training

11분

이 단원에서는 Tailspin 웹 팀과 함께 Space Game 웹 사이트를 위한 릴리스 파이프라인을 정의하는 과정을 따라가 보겠습니다.

릴리스 파이프라인을 계획할 때는 일반적으로 해당 파이프라인의 ‘단계’ 또는 주요 부분을 식별하는 것부터 시작합니다. 각 단계는 일반적으로 환경에 매핑됩니다. 예를 들어 이전 모듈에서 Andy와 Mara의 기본 파이프라인에는 Azure App Service 인스턴스에 매핑되는 ‘배포’ 단계가 있었습니다.

이 모듈에서는 한 단계에서 다음 단계로 변경 내용을 ‘승격’합니다. 각 단계 내에서는 해당 단계와 연결된 환경에 Space Game 웹 사이트를 ‘배포’합니다.

필요한 단계를 정의한 후에는 한 단계에서 다음 단계로 변경 내용을 승격하는 방법을 고려합니다. 각 단계에서는 빌드를 다음 단계로 이동하기 위해 충족해야 하는 성공 조건을 정의할 수 있습니다. Azure Pipelines는 파이프라인에서 변경 내용이 이동하는 방식과 시점을 제어하는 데 도움이 되는 여러 가지 방법을 제공합니다. 전체적으로 이와 같은 접근 방식은 릴리스 관리에 사용됩니다.

이 섹션에서는 다음을 수행합니다.

‘빌드’, ‘개발’, ‘테스트’, ‘스테이징’과 같은 일반적인 파이프라인 단계 간의 차이점에 대해 배웁니다.
수동 트리거, 예약된 트리거, 지속적인 배포 트리거를 사용하여 아티팩트가 파이프라인의 다음 단계로 이동하는 시점을 제어하는 방법을 이해합니다.
승인자가 릴리스를 수락하거나 거부할 때까지 릴리스 승인이 파이프라인을 일시 중지하는 방법을 살펴봅니다.

회의

전체 Tailspin 웹 팀이 한자리에 모였습니다. Azure Pipelines를 사용하여 릴리스 파이프라인 생성에서 팀은 현재 스프린트를 위한 작업을 계획했습니다. 각 작업은 Space Game 웹 사이트의 릴리스 파이프라인을 구축하는 것과 관련이 있습니다.

팀에서는 스프린트에 대해 다음과 같은 5가지 작업을 결정했습니다.

다단계 파이프라인을 만듭니다.
웹앱을 데이터베이스에 연결합니다.
품질 테스트를 자동화합니다.
성능 테스트를 자동화합니다.
릴리스 주기를 단축합니다.

회의에서 팀은 첫 번째 작업에 대해 대화를 나누고 ‘다단계 파이프라인을 만듭니다’. 팀이 파이프라인을 정의한 후에는 기본 개념 증명에서 더 많은 단계, 품질 확인 및 승인을 포함하는 릴리스 파이프라인으로 이동할 수 있습니다.

Amita와 Tim이 두 번째로 릴리스 파이프라인에 대해 설명하고 있는 Andy와 Mara를 보고 있고, 아티팩트가 빌드되어 App Service에 설치되었다는 내용을 들었습니다.

어떤 파이프라인 단계가 필요한가요?

릴리스 파이프라인을 구현해야 하는 경우 먼저 필요한 단계를 식별하는 것이 중요합니다. 요구 사항에 따라 선택하는 단계가 달라집니다. 단계를 결정하는 과정을 팀과 함께 따라가 보겠습니다.

Tim: 알겠어요, 자동 파이프라인의 개념을 이해했어요. Azure에 배포하기가 쉽다는 점이 마음에 듭니다. 그런데 데모 내용은 그렇다 치고, 우리는 어떻게 진행해야 할까요? 실제 릴리스에 사용할 수 있는 어떤 것이 필요하지 않을까요.

Amita: 맞아요! 다른 단계를 추가해야 합니다. 예를 들어, 현재 테스트 단계를 위한 공간이 없습니다.

Tim: 그리고 경영진에게 새로운 기능을 보여줄 수 있는 단계가 필요해요. 경영진의 승인이 없으면 프로덕션까지 어떤 것도 보낼 수 없어요.

Andy: 물론이죠! 지금까지 릴리스 파이프라인의 기능에 대해 알아봤는데, 그렇다면 어떻게 해야 릴리스 파이프라인이 필요한 작업을 수행하도록 만들 수 있을까요?

Mara: 그럼, 다음 단계를 계획하는 데 도움이 되는 요구 사항을 개략적으로 살펴볼게요. 우리의 요구 사항부터 살펴볼까요.

Mara는 화이트보드로 가 기존 파이프라인을 그렸습니다.

Diagram of the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Mara: ‘빌드’ 단계에서는 소스 코드를 빌드하고 패키지를 생성합니다. 이 경우 해당 패키지는 .zip 파일입니다. ‘배포’ 단계에서는 App Service 인스턴스에 Space Game 웹 사이트인 .zip 파일을 설치하죠. 그렇다면 우리 릴리스 파이프라인에서 누락된 단계는 무엇인가요?

개발 단계 추가

Andy: 틀릴 수도 있지만 제 생각에는 ‘개발’ 단계가 필요한 것 같아요. 개발 단계는 빌드된 후 아티팩트의 첫 번째 중지 지점이어야 하죠. 개발자는 로컬 개발 환경에서는 항상 전체 서비스를 실행할 수 없습니다. 예를 들어 전자상거래 시스템에는 웹 사이트, 제품 데이터베이스 및 결제 시스템이 필요할 수 있습니다. 앱에 필요한 모든 항목을 포함하는 단계가 필요하죠.

이 경우 Space Game 웹 사이트의 순위표 기능은 외부 소스에서 높은 점수를 읽는데, 지금은 파일에 저장된 가상의 점수를 읽습니다. ‘개발’ 단계를 설정하면 웹앱을 실제 데이터베이스와 통합할 수 있는 환경이 제공됩니다. 해당 데이터베이스에는 아직 가상의 점수가 저장되어 있겠지만 덕분에 우리는 최종 앱 개발까지 한 걸음 더 다가설 수 있죠.

Mara: 좋은데요. 아직 실제 데이터베이스와 통합하면 안 됩니다. 하지만 ‘개발’ 단계에서는 데이터베이스를 추가할 수 있는 환경에 배포할 수 있습니다.

Mara가 화이트보드의 그림을 수정합니다. “Deploy”를 “Dev”로 고쳐 ‘개발’ 단계를 표시합니다.

Diagram that shows the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Andy: 아주 흥미로운데요. 우리는 GitHub에 변경 내용을 푸시할 때마다 앱을 빌드하는데, 이 말은 각 빌드가 완료되면 ‘개발’ 단계로 승격된다는 뜻인가요?

Mara: 연속 빌드 시 빌드와 테스트 상태에 대한 중요한 피드백을 얻을 수 있어요. 하지만 코드를 일부 중앙 분기(master 또는 다른 릴리스 분기)로 병합하는 경우에만 개발 단계로 승격해야 합니다. 해당 요구 사항을 보여 주기 위해 그림을 고쳐 보겠습니다.

Diagram that shows whiteboard illustrating build and dev stages. A condition promotes to the Dev stage only when changes happen on a release branch.

Mara: 이와 같은 승격은 쉽죠. 릴리스 분기가 변경된 경우에만 ‘개발’ 단계로 승격하는 ‘조건’을 정의할 수 있습니다.

조건이란?

Azure Pipelines에서 조건을 사용하여 파이프라인의 상태에 따라 태스크 또는 작업을 실행합니다. 작업 시 이전 모듈의 조건을 적용했습니다.

지정할 수 있는 몇 가지 조건은 다음과 같습니다.

이전의 모든 종속 작업이 성공한 경우에만
이전 종속성이 실패한 경우에도 실행이 취소되지 않은 경우
이전 종속성이 실패하고 실행이 취소된 경우에도
이전 종속성이 실패한 경우에만
일부 사용자 지정 조건

기본 예제는 다음과 같습니다.

steps:
  - script: echo Hello!
    condition: always()

이전 작업이 실패한 경우에도 이 always() 조건 때문에 이 태스크는 무조건 "Hello!"를 인쇄합니다.

조건을 지정하지 않는 경우 다음 조건이 사용됩니다.

condition: succeeded()

기본 제공 함수인 succeeded()는 이전의 작업이 성공했는지 여부를 확인합니다. 이전 작업이 실패하면 동일한 조건을 사용하는 이 작업과 후속 작업을 건너뜁니다.

여기서는 다음을 지정하는 조건을 작성합니다.

이전의 작업이 성공했습니다.
현재 Git 분기의 이름이 릴리스인지 여부입니다.

이 조건을 빌드하려면 and() 기본 제공 함수를 사용합니다. 이 함수는 각 조건이 true인지 확인합니다. true가 아닌 조건이 있는 경우 전체 조건이 실패합니다.

현재 분기의 이름을 가져오려면 기본 제공 Build.SourceBranchName 변수를 사용합니다. 조건 내에 변수에는 몇 가지 방법으로 액세스할 수 있습니다. 여기서 variables[] 구문을 사용합니다.

변수의 값을 테스트하려면 eq() 기본 제공 함수를 사용할 수 있습니다. 이 함수는 해당 인수가 동일한지 확인합니다.

이 점에 유의하면서 현재 분기 이름이 “릴리스”인 경우에만 해당 조건을 적용하여 ‘개발’ 단계를 실행합니다.

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

and() 함수의 첫 번째 조건은 이전 작업이 성공했는지 여부를 확인합니다. 두 번째 조건은 현재 분기 이름이 릴리스와 같은지 확인합니다.

YAML에서는 파이프(|) 구문을 사용하여 여러 줄에 걸쳐 있는 문자열을 정의합니다. 한 줄에 조건을 정의할 수는 있지만, 조건을 이 방식으로 작성하면 더 쉽게 읽을 수 있습니다.

참고

이 모듈에서는 릴리스 분기를 예로 사용합니다. 조건을 결합하여 필요한 동작을 정의할 수 있습니다. 예를 들어 main 분기에 대한 끌어오기 요청으로 빌드가 트리거될 때만 단계를 실행하는 조건을 빌드할 수 있습니다.

다음 단원에서는 개발 단계를 설정할 때 더 완전한 예를 사용하여 작업합니다.

Azure Pipelines의 조건에 대한 자세한 설명은 식 설명서를 참조하세요.

Mara: 조건을 사용하면 어떤 변경 내용이 어떤 단계로 승격되는지를 제어할 수 있습니다. 변경 내용을 위한 빌드 아티팩트를 생성하여 빌드의 유효성을 검사하고 빌드가 정상인지 확인할 수 있습니다. 준비되면 변경 내용을 릴리스 분기에 병합하고 해당 빌드를 ‘개발’ 단계로 승격할 수 있습니다.

테스트 단계 추가

Mara: 지금까지 ‘빌드’와 ‘개발’ 단계를 생성했는데요, 그 다음 단계는 무엇일까요?

Amita: 다음에 ‘테스트’ 단계를 추가할 수 있나요? 최신 변경 내용을 테스트하기에 적절해 보이는데요.

Mara는 화이트보드의 그림에 ‘테스트’ 단계를 추가했습니다.

Diagram that shows the whiteboard illustrating build, dev and test stages. The Test stage deploys the build to Azure App Service.

Amita: 앱을 테스트하는 빈도가 염려되네요. Mara나 Andy가 변경할 때마다 알림 메일을 받겠지만, 온종일 변경 내용이 생길 텐데 어느 시점에 앱을 테스트할지 모르겠네요. 출근했을 때 하루에 한 번 빌드를 확인하면 좋을 것 같아요. 이렇게 할 수 있을까요?

Andy: 물론이죠. 어째서 휴무 시간에 테스트에 배포하지 않을까요? 매일 오전 3시에 빌드를 보내드리면 어떨까요?

Mara: 좋아요. 필요한 경우 언제든지 프로세스를 수동으로 트리거할 수 있어요. 예를 들어 중요한 버그 수정 사항을 즉시 확인해야 하는 경우 해당 프로세스를 트리거할 수 있어요.

Mara는 매일 오전 3시에 빌드가 개발 단계에서 테스트 단계로 이동하는 것을 보여 주기 위해 그림을 업데이트합니다.

Diagram that shows the whiteboard showing Build, Dev, and Test stages. The schedule promotes the change from Dev to Test at 3 A.M. each morning.

트리거란?

Amita: 한 단계에서 다른 단계로 어떻게 이동하는지 알고 나니 좋네요. 하지만 단계가 실행되는 시점을 제어하는 방법은 무엇인가요?

Mara: Azure Pipelines에서 트리거를 사용할 수 있습니다. ‘트리거’는 단계가 실행되는 시점을 정의하는데, Azure Pipelines에서는 몇 가지 유형의 트리거를 제공합니다. 제공되는 트리거는 다음과 같아요.

CI(연속 통합) 트리거
PR(끌어오기 요청) 트리거
예약된 트리거
빌드 완료 트리거

CI와 PR 트리거를 사용하면 전체 프로세스에 참여하는 분기를 제어할 수 있습니다. 예를 들어 분기에서 변경이 발생하면 프로젝트를 빌드해야 합니다. 예약된 트리거는 특정 시간에 배포를 시작합니다. 빌드 완료 트리거는 종속 구성 요소를 위한 빌드처럼 다른 빌드가 완료되면 빌드를 실행합니다. 우리한테는 예약된 트리거가 필요한 것 같네요.

예약된 트리거란?

예약된 트리거는 cron 구문을 사용하여 정의된 일정에 따라 빌드를 실행합니다.

Unix와 Linux 시스템에서 cron은 설정한 시간 간격 또는 특정 시간에 실행되도록 작업을 예약하는 일반적인 방법입니다. Azure Pipelines에서 예약된 트리거는 cron 구문을 사용하여 단계가 실행되는 시점을 정의합니다.

Cron 식에는 특정 시간 매개 변수와 일치하는 필드가 포함되는데, 다음과 같습니다.

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

예를 들어 이 cron 식은 “매일 오전 3시”를 설명합니다. 0 3 * * *

Cron 식에는 값 목록 또는 값의 범위를 지정하기 위한 특수 문자를 포함할 수 있습니다. 이 예제에서 별표(*)는 일, 월, 요일 필드에 어떤 값이 와도 일치합니다.

또 다른 방법으로, 이 cron 식은 다음과 같이 읽을 수 있습니다.

0분에
세 시간째에
한 달의 모든 날에
모든 월에
모든 요일에
작업 실행

월요일부터 금요일까지의 오전 3시를 지정하려면 다음 식을 사용합니다. 0 3 * * 1-5

참고

Cron 일정의 표준 시간대는 UTC(협정 세계시)이므로, 이 예에서 3A.M.은 UTC 기준 오전 3시를 나타냅니다. 실제로 팀과 함께 예상한 시간에 파이프라인이 실행되도록 UTC를 기준으로 cron 일정의 시간을 조정하는 것이 좋습니다.

Azure Pipelines에서 예약된 트리거를 설정하려면 YAML 파일에 schedules 섹션이 필요합니다. 예를 들면 다음과 같습니다.

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

이 schedules 섹션의 내용은 다음과 같습니다.

cron: cron 식을 지정합니다.
branches: release 분기에서만 배포하도록 지정합니다.
always: 배포를 무조건 실행할지(true) 아니면 마지막 실행 이후 release 분기가 변경된 경우에만(false) 실행할지 지정합니다. 마지막 실행 이후 release 분기가 변경된 경우에만 배포해야 하기 때문에 false를 지정합니다.

Azure Pipelines에서 예약된 트리거를 실행할 때 전체 파이프라인이 실행됩니다. 또한 파이프라인은 GitHub에 변경 내용을 푸시하는 경우처럼 다른 조건에서도 실행됩니다. 예약된 트리거에 대한 응답으로만 단계를 실행하기 위해 빌드 이유가 예약된 실행인지 여부를 확인하는 조건을 사용할 수 있습니다.

예를 들면 다음과 같습니다.

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

Test 단계는 이전 단계가 성공하고 기본 제공 Build.Reason 파이프라인 변수가 Schedule과 동일한 경우에만 실행됩니다.

이 모듈의 뒷부분에서 더 완전한 예를 볼 수 있습니다.

Amita: 좋은데요. 릴리스를 수동으로 선택해 설치할 필요도 없네요. 사용자를 위해 준비되었습니다.

Andy: 하지만 좀 더 나중에 자동화해야 한다면 그렇게 할 수 있어요. 아직 확실한 것은 아무것도 없어요. 우리가 개선하고 배우는 과정에서 파이프라인은 진화하니까요.

스테이징 단계 추가

Tim: 제 차례네요. 더 많은 스트레스 테스트를 실행하는 단계가 필요합니다. 또한 승인을 얻기 위해 경영진에게 시연할 수 있는 단계도 필요하고요. 지금은 이와 같은 두 가지 필요를 ‘스테이징’이라는 단계로 결합할 수 있습니다.

Andy: 맞는 말이에요, Tim. 스테이징, 즉 사전 프로덕션 환경이 필요합니다. 일반적으로 스테이징 환경은 사용자에게 기능 또는 버그 수정을 제공하기 전에 마지막으로 거치는 정거장과 같습니다.

Mara는 화이트보드의 그림에 스테이징을 추가합니다.

Diagram where the whiteboard is showing the Build, Dev, Test, and Staging stages. The Staging stage deploys the build to Azure App Service.

Amita: 예약된 트리거를 사용해서 변경 내용을 ‘개발’ 단계에서 ‘테스트’ 단계로 승격할 수 있잖아요. 그러나 변경 내용을 테스트에서 스테이징으로 승격하려면 어떻게 해야 할까요? 승격도 일정에 따라 진행되나요?

Mara: 가장 좋은 처리 방법은 릴리스 승인이에요. 릴리스 승인을 사용하면 변경 내용을 한 단계에서 다음 단계로 수동으로 승격할 수 있거든요.

Amita: 딱 저한테 필요한 건데요! 릴리스 승인을 사용하면 빌드를 경영진에게 보여 주기 전에 최신 변경 내용을 테스트할 수 있는 시간이 생기고 준비가 됐을 때 빌드를 승격할 수 있어요.

Mara는 Amita가 승인하는 경우에만 빌드가 테스트에서 스테이징으로 이동한다는 것을 보여 주기 위해 그림을 수정했습니다.

Diagram where the whiteboard shows the Build, Dev, Test, and Staging stages. Changes move from Test to Staging only after approval.

Tim: 또한 경영진에서 승인한 이후에도 릴리스 승인을 사용하여 스테이징에서 프로덕션으로 승격하는 것도 생각해 보는데, 시간이 얼마나 걸릴지 예측할 수 없네요. 경영진이 승인한 다음 제가 릴리스를 승인하고 수동으로 프로덕션으로 승격할 수 있잖아요. 그런데 릴리스 승인은 어떻게 작동하나요?

릴리스 승인이란?

릴리스 승인은 승인자가 릴리스를 수락하거나 거부할 때까지 파이프라인을 일시 중지하는 방법입니다. 릴리스 워크플로를 정의하기 위해 승인, 조건, 트리거를 결합할 수 있습니다.

Azure Pipelines를 사용하여 릴리스 파이프라인 생성에서 배포 환경을 나타내기 위해 파이프라인 구성에서 환경을 정의했습니다. 기존 파이프라인의 예는 다음과 같습니다.

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

사용자 환경에는 릴리스의 특정 기준이 포함될 수 있습니다. 이 기준은 환경에 배포할 수 있는 파이프라인과 릴리스를 한 단계에서 다음 단계로 승격하는 데 필요한 승인을 지정할 수 있습니다.

이 모듈의 뒷부분에서는 스테이징 환경을 정의하고 Space Game 웹앱을 테스트 단계에서 스테이징으로 승격하기 위한 승인자로 자신을 할당합니다.

많든 적든 필요한 만큼 자동화

Azure Pipelines는 자동화 준비가 되지 않은 단계를 수동으로 제어하는 동시에 일부 단계를 자동화할 수 있는 유연성을 제공합니다.

Tim: 한 단계에서 다음으로 변경 내용을 승격하는 기준을 정의하는 방법이 마음에 들어요. 하지만 파이프라인에서 몇 가지 수동 조건을 정의했습니다. 저는 DevOps가 모든 것을 자동화하는 것으로 생각했거든요.

Mara: 좋은 지적이에요. DevOps는 반복적이고 오류가 발생하기 쉬운 작업을 자동화하죠. 때로는 사람이 개입이 필요하지만요. 예를 들어 새 기능을 릴리스하기 전에 경영진의 승인을 받습니다. 자동화된 배포와 관련해 더 많은 경험을 얻게 되면 수동 단계의 더 많은 부분을 자동화하여 프로세스를 가속화할 수 있어요. 예를 들어, 테스트 단계에서 더 많은 품질 검사를 자동화할 수 있으므로 Amita가 각 빌드를 승인할 필요가 없습니다.

Tim: 그거 좋네요. 지금은 이렇게 진행하고 이후에 얼마나 진행 속도를 높일 수 있었는지 한 번 보자고요.

Amita: 우리가 지금 논의한 계획에서 다음 단계를 어떻게 요약할 수 있을까요?

계획

다음 단계로 이동하는 Tailspin 팀의 계획을 검토해 보겠습니다.

Mara: 우리가 빌드하려는 릴리스 파이프라인은 다음과 같아요.

Mara가 화이트보드를 가리킵니다.

Diagram of the final whiteboard showing the Build, Dev, Test, and Staging stages.

Mara: 요약하자면 우리가 진행할 단계는 다음과 같아요.

GitHub에 변경 내용을 푸시할 때마다 빌드 아티팩트를 생성합니다. 이 단계는 ‘빌드’ 단계에서 발생합니다.
빌드 아티팩트를 ‘개발’ 단계로 승격합니다. 이 단계는 빌드 단계가 성공하고 변경 내용이 릴리스 분기에 있는 경우 자동으로 발생합니다.
매일 아침 3시에 빌드 아티팩트를 테스트 단계로 승격합니다. 예약된 트리거를 사용하여 빌드 아티팩트를 자동으로 승격합니다.
Amita가 빌드를 테스트 후 승인하면 빌드 아티팩트를 스테이징으로 승격합니다. 릴리스 승인을 사용하여 빌드 아티팩트를 승격할 수 있습니다.

경영진이 빌드를 승인하면 빌드 아티팩트를 프로덕션 환경에 배포할 수 있습니다.

Amita: 이 작업을 수행하기가 어렵지 않을까요? 할 일이 많을 것 같은데요.

Mara: 나는 이것이 아주 안 좋다고 생각하지 않습니다. 모든 단계는 다른 모든 단계와는 별개입니다. 단계는 분리되어 있습니다. 각 단계에는 자체 작업 세트가 있습니다. 예를 들어 테스트 단계에서 발생하는 작업은 테스트 단계에서 유지됩니다.

파이프라인의 모든 배포 단계에는 자체 환경도 있습니다. 예를 들어 개발 또는 테스트에 앱을 배포하는 경우 환경은 App Service 인스턴스입니다.

마지막으로 릴리스를 한 번에 하나만 테스트하고 파이프라인 중간에 릴리스를 변경하지 않습니다. ‘개발’ 단계에서는 ‘스테이징’ 단계와 동일한 릴리스를 사용하고 모든 릴리스에는 고유한 버전 번호가 있습니다. 릴리스가 단계 중 하나에서 중단되면 해당 릴리스를 수정하고 새 버전 번호로 다시 빌드합니다. 그러면 새 릴리스가 파이프라인의 맨 처음부터 진행합니다.

품질에 대한 몇 가지 설명

방금 팀이 빌드부터 스테이징까지 앱을 수행하는 파이프라인을 설계하는 것을 보았습니다. 파이프라인은 목적은 단순히 작업자를 편하게 하는 데 있는 것이 아니라 고객에게 제공하는 소프트웨어의 품질을 보장하는 것입니다.

릴리스 프로세스의 품질을 측정하려면 어떻게 해야 하나요? 릴리스 프로세스의 품질은 직접 측정할 수 없지만 프로세스가 얼마나 잘 작동하는지는 측정할 수 있습니다. 프로세스를 지속적으로 변경하는 경우 이는 문제가 있음을 나타내는 것일 수 있습니다. 파이프라인의 특정 지점에서 일관되게 작동하지 않는 릴리스는 릴리스 프로세스에 문제가 있음을 나타낼 수도 있습니다.

릴리스가 특정 날짜 또는 시간에 항상 실패하나요? 특정 환경에 배포한 후 항상 실패하나요? 해당 패턴과 다른 패턴을 살펴보고 릴리스 프로세스의 일부 측면이 종속 또는 관련되어 있는지 확인합니다.

릴리스 프로세스 품질을 추적하는 좋은 방법은 릴리스 품질의 시각화를 만드는 것입니다. 예를 들어 모든 릴리스의 상태를 표시하는 대시보드 위젯을 추가합니다.

릴리스 자체의 품질을 측정하려는 경우 파이프라인 내에서 모든 종류의 검사를 수행할 수 있습니다. 예를 들어 파이프라인을 실행하는 동안 부하 테스트와 UI 테스트 등 다양한 종류의 테스트를 실행할 수 있습니다.

품질 게이트를 사용하는 것도 릴리스의 품질을 확인하는 좋은 방법입니다. 다양한 품질 게이트가 있습니다. 예를 들어 작업 항목 게이트는 요구 사항 프로세스의 품질을 확인할 수 있습니다. 더 많은 보안 및 규정 준수 검사를 추가할 수도 있습니다. 예를 들어 4-Eyes Principle(2인 인증 원칙)을 준수하거나 적절한 추적 가능성이 있나요?

이 학습 경로를 진행하면서 이러한 많은 기술이 실제로 적용되는 것을 볼 수 있습니다.

마지막으로, 품질 릴리스 프로세스를 설계할 때 사용자에게 제공해야 하는 설명서 또는 릴리스 정보를 생각해야 합니다. 설명서를 최신 상태로 유지하는 것은 어려울 수 있습니다. Azure DevOps 릴리스 정보 생성기와 같은 도구를 사용하는 것을 고려해 볼 수 있습니다. 이 생성기는 HTTP 트리거 함수를 포함하는 함수 앱입니다. Azure Blob Storage를 사용하여 Azure DevOps에서 새 릴리스가 생성될 때마다 Markdown 파일을 만듭니다.

지식 점검

파이프라인에는 완료하는 데 몇 분 정도 걸리는 테스트와 품질 검사가 다수 포함되어 있습니다. 동료가 검토한 코드에 대해서만 테스트를 실행하는 데 가장 적합한 트리거 유형은 무엇인가요?

빌드 완료 트리거

CI 트리거 또는 PR 트리거

예약된 트리거

승인자가 변경 내용을 승인할 때까지 파이프라인을 일시 중지하는 가장 좋은 방법은 무엇인가요?

릴리스 승인을 사용하는 것입니다.

파이프라인을 일시 중지할 수 있는 Azure Pipelines 작업을 제공하는 Marketplace 확장을 설치합니다.

승인자에게 변경 사항을 확인하도록 요청합니다. 그런 다음 실행할 파이프라인을 수동으로 트리거합니다.

빌드를 완료할 때마다 테스트 환경에 웹앱을 배포하려고 합니다. 해당 프로세스를 설정하는 가장 쉬운 방법은 무엇인가요?

예약된 트리거를 사용합니다.

빌드 알림 메일을 보고 있다가 다른 빌드가 완료되면 자신의 빌드를 수동으로 트리거합니다.

빌드 완료 트리거를 사용합니다.

작업을 확인하기 전에 모든 질문에 대답해야 합니다.

계속