파이프라인은 GitLab에서 CI/CD의 기본 구성 요소입니다. 이 페이지에서는 파이프라인과 관련된 몇 가지 중요한 개념을 설명합니다.

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

• 기본 파이프라인: 모든 구성이 한 곳에 있는 간단한 프로젝트에 적합합니다.

• needs 키워드를 사용한 파이프라인: 효율적인 실행이 필요한 크고 복잡한 프로젝트에 적합합니다.

• 부모-자식 파이프라인: 독립적으로 정의된 컴포넌트가 많은 모노리포 및 프로젝트에 적합합니다.

  개요는 부모-자식 파이프라인 기능 데모를 참조하세요.

• 멀티 프로젝트 파이프라인: 마이크로서비스 아키텍처와 같이 크로스 프로젝트 상호 의존성이 필요한 대형 제품에 적합합니다.

  예를 들어 세 개의 다른 GitLab 프로젝트에서 웹 애플리케이션을 배포할 수 있습니다. 멀티 프로젝트 파이프라인을 사용하면 각 프로젝트에서 파이프라인을 트리거할 수 있으며, 각 프로젝트에는 자체 빌드, 테스트, 배포 프로세스가 있습니다. 모든 크로스 프로젝트 상호 의존성을 포함하여 연결된 파이프라인을 한 곳에서 시각화할 수 있습니다.

  개요는 멀티 프로젝트 파이프라인 데모를 참조하세요.

기본 파이프라인#

기본 파이프라인은 GitLab에서 가장 간단한 파이프라인입니다. 빌드 Stage의 모든 것을 동시에 실행하고, 모두 완료되면 테스트 및 이후 Stage의 모든 것을 같은 방식으로 실행합니다. 가장 효율적이지는 않으며, 단계가 많으면 꽤 복잡해질 수 있지만 유지 관리하기가 더 쉽습니다:

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph LR
accTitle: Basic pipelines
accDescr: Shows a pipeline that runs sequentially through the build, test, and deploy stages.
subgraph deploy stage
deploy --> deploy_a
deploy --> deploy_b
end
subgraph test stage
test --> test_a
test --> test_b
end
subgraph build stage
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 "This job builds something."

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

test_a:
  stage: test
  script:
    - echo "This job tests something. It will only run when all jobs in the"
    - echo "build stage are complete."

test_b:
  stage: test
  script:
    - echo "This job tests something else. It will only run when all jobs in the"
    - echo "build stage are complete too. It will start at about the same time as test_a."

deploy_a:
  stage: deploy
  script:
    - echo "This job deploys something. It will only run when all jobs in the"
    - echo "test stage complete."
  environment: production

deploy_b:
  stage: deploy
  script:
    - echo "This job deploys something else. It will only run when all jobs in the"
    - echo "test stage complete. It will start at about the same time as deploy_a."
  environment: production

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

효율성이 중요하고 모든 것을 최대한 빠르게 실행하려면 needs 키워드를 사용하여 잡 간의 의존성을 정의할 수 있습니다. GitLab이 잡 간의 의존성을 알면 잡이 가능한 한 빠르게 실행될 수 있으며, 동일 Stage의 다른 잡보다 먼저 시작할 수도 있습니다.

다음 예시에서 build_a와 test_a가 build_b와 test_b보다 훨씬 빠르면 build_b가 아직 실행 중이어도 GitLab이 deploy_a를 시작합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph LR
accTitle: Pipeline using needs
accDescr: Shows how two jobs can start without waiting for earlier stages to complete
subgraph Pipeline using 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 "This job builds something quickly."

build_b:
  stage: build
  script:
    - echo "This job builds something else slowly."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "This test job will start as soon as build_a finishes."
    - echo "It will not wait for build_b, or other jobs in the build stage, to finish."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "This test job will start as soon as build_b finishes."
    - echo "It will not wait for other jobs in the build stage to finish."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "Since build_a and test_a run quickly, this deploy job can run much earlier."
    - echo "It does not need to wait for build_b or test_b."
  environment: production

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "Since build_b and test_b run slowly, this deploy job will run much later."
  environment: production

부모-자식 파이프라인#

파이프라인이 더 복잡해질수록 몇 가지 관련 문제가 발생하기 시작합니다:

• Stage 구조에서 한 Stage의 모든 단계가 완료되어야 다음 Stage의 첫 번째 잡이 시작될 수 있어 속도를 늦추는 대기가 발생합니다.
• 단일 글로벌 파이프라인의 구성이 관리하기 어려워집니다.
• include를 사용한 가져오기는 구성의 복잡성을 증가시키고 잡이 의도치 않게 중복되는 네임스페이스 충돌을 일으킬 수 있습니다.
• 파이프라인 UX에 작업할 잡과 Stage가 너무 많습니다.

또한 파이프라인의 동작이 더 동적이어야 할 때가 있습니다. 특히 YAML이 동적으로 생성된 경우 서브 파이프라인을 시작할지 여부를 선택할 수 있는 기능은 강력한 능력입니다.

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

• rules 키워드: 예를 들어 해당 영역의 변경이 있을 때만 자식 파이프라인이 트리거되도록 합니다.
• include 키워드: 공통 동작을 가져와 반복을 방지합니다.
• 자식 파이프라인 내부의 needs 키워드로 두 가지 장점을 모두 활용합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph LR
accTitle: Parent and child pipelines
accDescr: Shows that a parent pipeline can trigger independent child pipelines
subgraph Parent pipeline
trigger_a -.-> build_a
trigger_b -.-> build_b
subgraph child pipeline B
build_b --> test_b --> deploy_b
end
subgraph child pipeline 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/*

needs 키워드를 사용하는 /a/.gitlab-ci.yml에 위치한 자식 a 파이프라인 구성 예시:

stages:
  - build
  - test
  - deploy

default:
  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."
  environment: production

needs 키워드를 사용하는 /b/.gitlab-ci.yml에 위치한 자식 b 파이프라인 구성 예시:

stages:
  - build
  - test
  - deploy

default:
  image: alpine

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

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "This job tests something else."

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "This job deploys something else."
  environment: production

GitLab에서 잡을 자식 파이프라인 트리거 전이나 후에 실행하도록 설정할 수 있으며, 공통 설정 단계나 통합 배포를 허용합니다.