[Azure Pipeline] CD 파이프라인의 Trigger 조건을 어떻게 설정해야 좋을까요?

☁️ 클라우드/DevOps Q&A
1

안녕하세요, Azure Pipeline 에서 CI/CD 파이프라인을 설계하다 보니 파이프라인을 시작하는 trigger 설정과 관련하여 질문하고자 합니다.

먼저, CI의 경우 pull request 또는 push 등 repository에서의 활동을 조건으로 파이프라인의 trigger를 설정합니다.

그런데 CD의 경우 어떤 방식으로 trigger를 설정해야 할지 잘 모르겠습니다.

어떤 분은 tag를 활용하시는 분도 있고, branch를 활용하시는 분도 있고, paths를 활용하시는 분도 있는 것 같습니다.

일단 아래와 같이 저는 설정해서 사용했더니 release/* branch를 main에 병합할 때마다 CI 파이프라인이 시작하는 문제가 있습니다.

trigger: 
  batch: true
  branches:
    include:
    - main
    exclude:
    - pipeline/*
    - release/*

pr: none

그리고 statging 과 produciton으로 구분하여 AKS에 배포하도록 2개의 CD 파이프라인을 만들어서 trigger를 설정하고자 하는데 혹시 추천하는 방법이 있으실까요?

Build GitHub repositories - Azure Pipelines | Microsoft Docs

2022.04.06 12:00 업데이트

repository는 Github 에서 호스팅되고 있습니다. 그리고 회사 코드이기 때문에 public repository가 아닌 private repository 입니다.

2022.04.07 10:00 업데이트

일단 제가 구상하고 있는 시나리오는 다음과 같습니다.

  1. 기능을 개발한 feature/** branch가 main branch에 병합되면, CI 파이프라인이 트리거되어 Container Image 를 빌드하여 Container Registry에 등록합니다.

  2. 그 후, 개발자가 로컬 개발 환경이 아닌 통합 개발 환경에서 테스트하기로 결정하여 staging/** branch 로 관련 내용을 수정하여 main branch에 병합하면, Staging CD 파이프라인이 트리거되어 개발자와 테스터만 접근 가능한 Kubernetes 에 배포합니다.

  3. 테스터가 통합 개발 환경에서 동작 수행에 문제가 없음을 확인된 후, release/** branch 또는 v1.*.* tag 로 Release CD 파이프라인이 동작하여 고객이 접근 가능한 Kubernetes 에 배포합니다.

그런데 위 시나리오에서 문제가 staging/** branch 가 main branch 통합되면 CI 파이프라인도 같이 트리거가 되어 수행됩니다. :sob:

trigger: 
  batch: true
  branches:
    include:
    - main
    exclude:
    - pipeline/*
    - release/*

pr: none

그래서 Conditions - Azure Pipelines | Microsoft Docs로 해결해보려고 하는데, 어떻게 해야 할지 갈피를 못 잡고 있습니다.

그리고 Release CD 파이프라인을 수동으로 돌릴 경우, git repository에 히스토리가 남지 않아 branch 또는 tag로 해결하는 전략이 적합할지 Best Practices 는 무엇일지 고견을 구하고자 합니다.

3개의 좋아요
2

저 같은 경우에는 수동으로 Deploy를 진행하는데 이 경우 workflow_dispatch를 활용 할 수 있습니다.

또한 repository_dispatch와 같은 event 형 트리거들이 존재하니 이를 통해 고려해보세요.

Events that trigger workflows - GitHub Docs

2개의 좋아요
3

먼저 질문에 관심 가져주셔서 감사합니다.

제안해주신 workflow_dispatch와 repository_dispatch 문서를 읽어보니, webhook을 사용하여 메뉴얼로 사용자가 CD 파이프라인을 돌리는 방식으로 이해됩니다.

image

image

그렇다면 CD 파이프라인은 자동 트리거 보다는 수동 트리거가 더 적합한 것 같다. 로 이해하면 될까요?

@SangHyeon.Kim 님께서 말씀해주신 대로, AKS (Azure Kubernetes Service)에 Production 배포는 수동 트리거, 즉 Azure Pipeline 에서 직접 시작하는 방법을 사용하는 방안이 좋을 것 같습니다.

다만, Staging의 경우 자동 트리거가 더 적합하지 않을까 생각하는데 어떻게 생각하실까요?

그리고 제안해주신 해결책은 Azure Pipeline이 아닌 Github Action으로 보입니다.
그렇다면 CI 파이프라인은 Azure Pipeline으로 관리하고, CD 파이프라인은 Github Action으로 관리하는 방안을 말씀해주시는 걸까요?

P.S

Azure Pipeline은 가격 정책이 파이프라인을 실행할 에이전트 수로 요금을 청구하는 반면, Github Action은 파이프라인 운영 시간으로 요금을 청구하는 걸로 알고 있습니다. 그래서 빌드 시간에 제약이 없는 Azure Pipeline으로 최대한 운영하고자 합니다.

image

image

2개의 좋아요
4

github actions는 public 저장소의 경우 CI CD 가 무료인 것으로 알고 있습니다.
private 저장소의 경우에만 매월 2000분인 것으로 알고 있습니다.

1개의 좋아요
5

말씀해주신 대로 Github 에서 public repository는 CI/CD 요금이 무료가 맞습니다.
그러나 개인 프로젝트가 아닌 회사 프로젝트다 보니, public repository 로 운영할 수가 없습니다. :sob:
질문에 관련 내용이 없어 오해를 드린 것 같아 죄송합니다. 다른 분들도 오해 없도록 질문 업데이트했습니다.

2개의 좋아요
6

아… ㅈㅅ
Azure Pipeline 이였네요 ;;;

@김예건

의견: 이건 전략마다 다릅니다. 저희가 수동을 택한건 저희 쪽 시나리오에서는 그게 맞기 때문입니다.
저희는 연속적인 통합을 수행하지만 배포까지 원하지 않았습니다. 매 스프린트 마지막에 승인 조건을 검수하고 배포합니다.

의견: 이것 또한 위 의견과 동일합니다.

그런데 배포를 Azure Pipeline에서 수행하시나요? Azure Devops 라면 Azure Release가 존재하고, 저 같은 경우 Azure Devops 사용할 때 배포는 Azure Release로 수행했습니다.

2개의 좋아요
7

말씀하신 Azure Release 가 Release pipelines 을 의미하신다면,

공식 문서에 classic release pipelines 라고 표현되어 있고 YAML 파일로 관리하는 방식이 아닌 것 같아 보였습니다. 저는 YAML 파일로 CI/CD 파이프라인을 관리하고 싶어, CD 파이프라인을 구성할 때 고려하지 않았습니다.

image

질문에 시나리오에 대한 설명이 없었군요. 질문에 추가했습니다.

일단 제가 구상하고 있는 시나리오는 다음과 같습니다.

  1. 기능을 개발한 feature/** branch가 main branch에 병합되면, CI 파이프라인이 트리거되어 Container Image 를 빌드하여 Container Registry에 등록합니다.

  2. 그 후, 개발자가 로컬 개발 환경이 아닌 통합 개발 환경에서 테스트하기로 결정하여 staging/** branch 로 관련 내용을 수정하여 main branch에 병합하면, Staging CD 파이프라인이 트리거되어 개발자와 테스터만 접근 가능한 Kubernetes 에 배포합니다.

  3. 테스터가 통합 개발 환경에서 동작 수행에 문제가 없음을 확인된 후, release/** branch 또는 v1.*.* tag 로 Release CD 파이프라인이 동작하여 고객이 접근 가능한 Kubernetes 에 배포합니다.

그런데 위 시나리오에서 문제가 staging/** branch 가 main branch 통합되면 CI 파이프라인도 같이 트리거가 되어 수행됩니다. :sob:

그래서 Conditions - Azure Pipelines | Microsoft Docs로 해결해보려고 하는데, 어떻게 해야 할지 갈피를 못 잡고 있습니다.

그리고 Release CD 파이프라인을 수동으로 돌릴 경우, git repository에 히스토리가 남지 않아 branch 또는 tag로 해결하는 전략이 적합할지 Best Practices 는 무엇일지 고견을 구하고자 합니다.

P.S

저는 사실 DevOps 개발자가 아닙니다. 이미 아니라고 할 선을 충분히 넘어 버린 것 같지만, 일단 기능 개발 업무도 진행해야 해서 일단 DevOps를 구축한 뒤에 DevOps 관리로 인한 업무를 최대한 줄여보고자 합니다. :sob:

4개의 좋아요
8

CI/CD 파이프라인 구성과 관련하여 나름 좋은 해결책을 찾았습니다.
핵심은 Trigger 조건을 어떻게 설정하느냐가 아닌 브랜치 전략을 어떻게 가져가느냐였습니다.

아래와 그림과 같이 Gitflow를 CI/CD 관점에서 보니, release branch 와 main branch에 commit이 push될 때마다 CD 파이프라인이 동작하도록 했습니다.

image

GitHub의 pull request 기능을 통해 CD 파이프라인이 trigger 되기 전에 리뷰를 할 수 있어, release branch가 main branch에 병합되기 전 테스터가 pull request 기능으로 production으로 배포해도 되는지를 검토하고 허가할 수 있는 권한을 줄 수 있게 되었습니다.

요약하면 release branch에 새로운 commit 이 생기면 staging으로 배포하는 CD 파이프라인을 trigger 하고, main branch에 새로운 commit이 생기면 production으로 배포하는 CD 파이프라인을 trigger합니다.

CI 파이프라인은 feature branch 와 develop branch에 pull request가 생기거나 업데이트될 때 trigger 되도록 했습니다. 이제 main branch에서 CI 파이프라인이 trigger 되지 않아 질문과 같은 문제가 발생하지 않게 되었습니다.

4개의 좋아요