[Gitlab CI/CD]부모-자식 파이프라인 구조

회사에서 gitlab을 사용하여 CI/CD 파이프라인을 구축하는 역할을 담당하게 되었다. 여러 프로젝트를 맡게 되었는데, 그 중 한 프로젝트는 여러개의 .gitlab-ci.yml 파일을 구성해야하는 상황이었다.

프로젝트 구조

이런 식으로 한 프로젝트 내에 여러 개의 모듈이 존재했고, 업무상 계속해서 모듈이 추가될 수 있는 상황이었다. 최초에는 프로젝트 내부에 있는 하나의 .gitlab-ci.yml 파일을 배포 때마다 수정해서 배포를 진행했다. 그러다 .gitlab-ci.yml 파일 내에 스크립트로 분기처리를 했고, 그보다 좋은 파이프라인 아키텍쳐를 알게 되어 개선했다.

부모-자식 파이프라인의 아키텍처를 도식화한 그림이다. 핵심은 메인 프로젝트의 .gitlab-ci.yml 파일에 trigger를 걸고, 실제로 수정된 서브 모듈의 .gitlab-ci.yml 파일을 통해서 CI/CD가 진행되는 것이다.

메인 프로젝트 .gitlab-ci.yml 파일 작성 방법

stages:
  - triggers

trigger_module_a:
  stage: triggers
  trigger:
    include: module_a/.gitlab-ci.yml
  rules:
    - changes:
        - module_a/**/*

trigger_module_b:
  stage: triggers
  trigger:
    include: module_b/.gitlab-ci.yml
  rules:
    - changes:
        - module_b/**/*

위의 .gitlab-ci.yml 파일을 살펴보면 2개의 trigger가 존재한다. trigger가 발동하는 조건은 rules에서 정의된다.

rules:
  - changes:
      - module_a/**/*

module_a 하위에 있는 소스가 수정되어 commit & push 된다면 trigger_module_a의 조건이 충족되어 trigger가 발동된다. trigger로 실행될 서브 모듈의 .gitlab-ci.yml 파일 위치는 아래와 같이 표기한다.

trigger:
  include: module_a/.gitlab-ci.yml

module_a 하위에 존재하는 .gitlab-ci.yml 파일의 스크립트가 실행된다.

서브 모듈의 .gitlab-ci.yml 파일 작성 방법

stages:
  - build
  - test
  - deploy

image: alpine

build_a:
  stage: build
  script:
    - echo "This job builds something."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "This job tests something."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "This job deploys something."

서브 모듈의 .gitlab-ci.yml 파일은 특별할 것이 없다. 일반적으로 구성하는 build, test, deploy에서 실행될 스크립트를 작성하면 된다.

실제 구성 예시

서브 모듈 밑에 .gitlab-ci.yml 파일을 각각 생성해두었다. Module A의 소스가 수정되었을 때와, Module B의 소스가 수정되었을 때 파이프라인이 진행되는 과정을 살펴보면 아래와 같다.

Module A의 경우에는 Build - Publish - Deploy까지 3단계로 구성하여 argoCD를 연동해 배포까지 자동화하였고, Module B의 경우 실제 배포는 수작업으로 진행하기 위해 Deploy 영역은 제외하였다.

이처럼 모듈 별로 다른 배포 파이프라인을 구축하려고 할 때 부모-자식 파이프라인 아키텍처를 활용하면 된다. trigger를 사용할 때 rules을 어떻게 정의하느냐에 따라서 원하는 거의 모든 상황을 구분해낼 수 있을 것 같다.

---

참고자료
Gitlab Docs : CI/CD Pipeline architectures