파이프라인 구조

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

파이프라인은 GitLab에서의 CI/CD의 핵심적인 구성 요소입니다. 이 페이지에서는 그와 관련된 중요한 개념들을 문서화하였습니다.

여러 가지 방법으로 파이프라인을 구성할 수 있으며, 각각에는 고유의 장점이 있습니다. 필요한 경우 이러한 방법들을 혼합하여 사용할 수 있습니다:

  • 기본: 모든 구성이 한 곳에 있는 간단한 프로젝트에 적합합니다.
  • needs 키워드를 사용한 파이프라인: 효율적인 실행이 필요한 대규모, 복잡한 프로젝트에 적합합니다.

  • 부모-자식 파이프라인: 모노 저장소 및 독립적으로 정의된 구성 요소가 많은 프로젝트에 적합합니다.

    개요는 부모-자식 파이프라인 기능 데모에서 확인할 수 있습니다.

  • 다중 프로젝트 파이프라인: 프로젝트 간 상호 의존성이 필요한 대규모 제품에 적합합니다. 마이크로서비스 아키텍처를 필요로 하는 제품에 적합합니다.

    예를 들어, Web 애플리케이션을 세 개의 GitLab 프로젝트에서 배포할 수 있습니다. 다중 프로젝트 파이프라인을 사용하면 각 프로젝트에서 파이프라인을 트리거할 수 있으며, 각각이 자체 빌드, 테스트 및 배포 프로세스를 갖게 됩니다. 연결된 파이프라인을 한 곳에서 시각적으로 확인할 수 있으며 모든 프로젝트 간의 상호 의존성을 확인할 수 있습니다.

    개요는 다중 프로젝트 파이프라인 데모에서 확인할 수 있습니다.

기본 파이프라인

기본 파이프라인은 GitLab에서 가장 간단한 파이프라인입니다. 빌드 단계에서 모든 것을 동시에 실행하고, 그 모두가 완료되면 테스트 및 이후 단계를 동일하게 실행합니다. 가장 효율적이지는 않으며, 많은 단계가 있는 경우 복잡해질 수 있지만 유지보수가 쉽습니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph LR accTitle: 기본 파이프라인 accDescr: 빌드, 테스트 및 배포 단계를 차례로 실행하는 파이프라인을 보여줍니다. subgraph 배포 단계 deploy --> deploy_a deploy --> deploy_b end subgraph 테스트 단계 test --> test_a test --> test_b end subgraph 빌드 단계 build --> build_a build --> build_b end build_a -.-> test build_b -.-> test test_a -.-> deploy test_b -.-> deploy

다이어그램과 일치하는 예시 기본 / .gitlab-ci.yml 파이프라인 구성: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "이 장작은 무언가를 빌드합니다."

build_b:
  stage: build
  script:
    - echo "이 장작은 다른 무언가를 빌드합니다."

test_a:
  stage: test
  script:
    - echo "이 장작은 무언가를 테스트합니다. 모든 빌드 단계의 작업이 완료되면 실행됩니다."

test_b:
  stage: test
  script:
    - echo "이 장작은 다른 무언가를 테스트합니다. 이 역시 모든 빌드 단계의 작업이 완료되면 실행됩니다. test_a와 거의 동시에 시작합니다."

deploy_a:
  stage: deploy
  script:
    - echo "이 장작은 무언가를 배포합니다. 모든 테스트 단계의 작업이 완료되면 실행됩니다."
  environment: production

deploy_b:
  stage: deploy
  script:
    - echo "이 장작은 다른 무언가를 배포합니다. 모든 테스트 단계의 작업이 완료되면 실행됩니다. deploy_a와 거의 동시에 시작합니다."
  environment: production

needs 키워드를 사용한 파이프라인

효율성이 중요하고 가능한 빨리 모든 것이 실행되도록 하려면, 작업 간 의존성을 정의하기 위해 needs 키워드를 사용할 수 있습니다. GitLab이 작업 간 의존성을 파악하면, 작업은 가능한 빨리 실행되며, 동일한 단계 내의 다른 작업보다 이른 시점에 시작할 수 있습니다.

아래 예시에서 build_a 및 test_a가 build_b 및 test_b보다 훨씬 빠르다면, GitLab은 build_b가 실행 중일지라도 deploy_a를 시작합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph LR accTitle: `needs` 키워드를 사용한 파이프라인 accDescr: 두 작업이 이전 단계의 완료를 기다리지 않고 시작하는 방법을 보여줍니다. subgraph `needs`를 사용한 파이프라인 build_a --> test_a --> deploy_a build_b --> test_b --> deploy_b end

다이어그램과 일치하는 / .gitlab-ci.yml 구성 예제: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "빠르게 무언가를 빌드하는 작업입니다."

build_b:
  stage: build
  script:
    - echo "천천히 다른 무언가를 빌드하는 작업입니다."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "이 테스트 작업은 build_a가 완료되는 즉시 시작됩니다."
    - echo "build_b나 다른 빌드 단계의 다른 작업을 기다릴 필요가 없습니다."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "이 테스트 작업은 build_b가 완료되는 즉시 시작됩니다."
    - echo "빌드 단계의 다른 작업을 기다릴 필요가 없습니다."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "build_a 및 test_a가 빠르게 실행되기 때문에, 배포 작업은 훨씬 더 빨리 실행될 수 있습니다."
    - echo "build_b 또는 test_b를 기다릴 필요가 없습니다."
  environment: production

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "build_b 및 test_b가 천천히 실행되기 때문에, 배포 작업은 훨씬 늦게 실행됩니다."
  environment: production

상위-하위 파이프라인

파이프라인이 더 복잡해지면 몇 가지 관련 문제가 발생합니다.

  • 첫 번째 단계의 모든 작업이 완료되어야 다음 단계의 첫 번째 작업이 시작되는 구조는 대기시간을 야기하여 속도를 늦춥니다.
  • 단일 전역 파이프라인의 구성 관리가 어려워집니다.
  • include로 가져오는 구성은 복잡성을 증가시키고, 의도하지 않게 작업이 중복되는 경우가 있습니다.
  • 파이프라인 UX에는 처리할 작업과 단계가 너무 많습니다.

또한 때로는 파이프라인의 동작이 더 동적이어야 할 때가 있습니다. 서브 파이프라인을 시작(또는 시작하지 않음)하는 선택은 특히 YAML이 동적으로 생성될 때 강력한 능력입니다.

확장된 상위 파이프라인 그래프

위의 기본 파이프라인 및 needs 파이프라인 예제에서는 독립적으로 빌드할 수 있는 두 개의 패키지가 있습니다. 이러한 경우 상위-하위 파이프라인을 사용하는 것이 이상적입니다. 이를 통해 구성을 여러 파일로 분리하여 구성을 보다 간단하게 유지할 수 있습니다. 상위-하위 파이프라인을 다음과 결합할 수 있습니다:

  • rules 키워드: 예를 들어 해당 영역에 변경 사항이 있을 때에만 하위 파이프라인을 트리거하도록 합니다.
  • include 키워드: 공통 동작을 가져와 반복을 피합니다.
  • 상위 파이프라인 내부의 needs 키워드를 사용하여 두 가지 혜택을 모두 누릴 수 있습니다.
%%{init: { "fontFamily": "GitLab Sans" }}%% graph LR accTitle: 상위 및 하위 파이프라인 accDescr: 상위 파이프라인이 독립적인 하위 파이프라인을 트리거할 수 있는 것을 보여줍니다. subgraph 상위 파이프라인 trigger_a -.-> build_a trigger_b -.-> build_b subgraph 하위 파이프라인 B build_b --> test_b --> deploy_b end subgraph 하위 파이프라인 A build_a --> test_a --> deploy_a end end

상위 파이프라인 다이어그램에 매칭되는 예시 /.gitlab-ci.yml 구성: 

stages:
  - triggers

trigger_a:
  stage: triggers
  trigger:
    include: a/.gitlab-ci.yml
  rules:
    - changes:
        - a/*

trigger_b:
  stage: triggers
  trigger:
    include: b/.gitlab-ci.yml
  rules:
    - changes:
        - b/*

/a/.gitlab-ci.yml에 있는 하위 a 파이프라인 구성 예시로, needs 키워드를 활용합니다: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "작업을 빌드합니다."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "작업을 테스트합니다."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "작업을 배포합니다."
  environment: production

/b/.gitlab-ci.yml에 있는 하위 b 파이프라인 구성 예시로, needs 키워드를 활용합니다: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_b:
  stage: build
  script:
    - echo "다른 작업을 빌드합니다."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "다른 작업을 테스트합니다."

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "다른 작업을 배포합니다."
  environment: production

GitLab에서는 작업을 하위 파이프라인을 트리거하기 전이나 후에 실행하도록 설정할 수 있으며, 공통 설정 단계나 통합 배포를 수행할 수 있습니다.