CI/CD 파이프라인

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

“지속적인 소프트웨어 개발 확장” 웹캐스트를 시청하여 GitLab CI/CD 파이프라인의 포괄적인 데모를 확인하세요.

파이프라인은 지속적 통합, 전달 및 배포의 최상위 컴포넌트입니다.

파이프라인은 다음으로 구성됩니다:

무엇을 할 지를 정의하는 작업(Job). 예를 들어, 코드를 컴파일하거나 테스트하는 작업들.
언제 작업을 실행할 지를 정의하는 단계(Stage). 예를 들어, 코드를 컴파일한 후에 테스트를 실행하는 단계.

여러 작업이 동시에 실행될 수 있도록 여러 작업이 동일한 단계에 있습니다.

한 단계의 모든 작업이 성공하면, 파이프라인은 다음 단계로 이동합니다.

한 단계의 어떤 작업이라도 실패하면, 다음 단계는 (보통) 실행되지 않고 파이프라인이 일찍 종료됩니다.

일반적으로 파이프라인은 자동으로 실행되며, 작성된 후에는 개입이 필요하지 않습니다. 그러나 때로는 파이프라인을 매뉴얼으로 상호 작용할 수 있는 시기도 있습니다.

전형적인 파이프라인은 다음 순서로 실행될 수 있습니다:

빌드 단계, 컴파일이라는 작업을 포함합니다.
테스트 단계, test1 및 test2라는 두 작업을 포함합니다.
스태이징 단계, 스테이지에 배포라는 작업을 포함합니다.
프로덕션 단계, 프로드에 배포라는 작업을 포함합니다.

만약 GitLab이 풀(pull)하는 거울 리포지터리가 있다면, 프로젝트의 설정 > 리포지터리 > 미러링 리포지터리 > 미러 업데이트를 위한 파이프라인 트리거 설정에서 파이프라인 트리거를 활성화해야 할 수 있습니다.

파이프라인의 유형

파이프라인은 다양한 방식으로 구성될 수 있습니다:

기본 파이프라인은 각 단계에서 모든 것을 동시에 실행한 후 다음 단계를 실행합니다.
유향성 비순환 그래프(DAG) 파이프라인은 작업 간의 관계에 기초하여 기본 파이프라인보다 빨리 실행될 수 있습니다.
Merge Request 파이프라인은 커밋마다 아닌, Merge Request만을 위해 실행됩니다.
Merge된 결과 파이프라인은 소스 브랜치의 변경 사항이 대상 브랜치에 이미 Merge된 것처럼 작동합니다.
Merge Train은 Merge된 결과 파이프라인을 사용하여 Merge을 차례로 대기열에 넣습니다.
상위-하위 파이프라인은 복잡한 파이프라인을 여러 하위 서브 파이프라인을 유발할 수 있는 하나의 상위 파이프라인으로 분해합니다. 이 파이프라인 구조는 주로 모노 리포지터리에 사용됩니다.
다중 프로젝트 파이프라인은 서로 다른 프로젝트의 파이프라인을 결합합니다.

파이프라인 구성

각 프로젝트의 CI/CD 파이프라인 구성 파일에 파이프라인 및 해당 구성 작업 및 단계가 정의됩니다.

작업은 기본 구성 컴포넌트입니다.
단계는 stages 키워드를 사용하여 정의됩니다.

CI 파이프라인 파일의 구성 옵션 디렉터리은 CI/CD YAML 구문 참조를 참조하십시오.

또한 GitLab UI를 통해 파이프라인의 특정 측면을 구성할 수 있습니다. 예를 들어:

실행자를 위한 Ref Spec

실행자가 파이프라인 작업을 선택하면 GitLab은 해당 작업의 메타데이터를 제공합니다. 이에는 프로젝트 리포지터리에서 체크아웃하는 데 사용되는 Git refspecs가 포함됩니다.

다음 표는 각 파이프라인 유형에 대해 주입된 refspecs를 나열합니다:

파이프라인 유형	Refspecs
브랜치용 파이프라인	`+<sha>:refs/pipelines/<id>` 및 `+refs/heads/<name>:refs/remotes/origin/<name>`
태그용 파이프라인	`+<sha>:refs/pipelines/<id>` 및 `+refs/tags/<name>:refs/tags/<name>`
Merge Request 파이프라인	`+refs/pipelines/<id>:refs/pipelines/<id>`

refs/heads/<name> 및 refs/tags/<name>는 프로젝트 리포지터리에 존재합니다. GitLab은 실행 중인 파이프라인 작업 중에 특수 ref refs/pipelines/<id>를 생성합니다. 이 ref는 연관된 브랜치 또는 태그가 삭제된 후에도 생성될 수 있습니다. 따라서 환경 자동으로 중지하거나 Merge Train과 같은 기능에 유용합니다.

파이프라인 보기

프로젝트의 빌드 > 파이프라인 페이지에서 현재 및 이전의 파이프라인 실행을 찾을 수 있습니다. 또한 파이프라인 탭으로 이동하여 Merge Request의 파이프라인에 액세스할 수 있습니다.

파이프라인을 선택하여 파이프라인 세부 정보 페이지를 열고 해당 파이프라인에서 실행된 작업을 표시할 수 있습니다. 여기서 실행 중인 파이프라인을 취소하거나, 실패한 파이프라인의 작업을 다시 시도하거나, 파이프라인 삭제도 할 수 있습니다.

특정 브랜치의 마지막 커밋을 위한 최신 파이프라인을 확인할 수 있는 링크는 /project/-/pipelines/[branch]/latest에 있습니다. 또한, /project/-/pipelines/latest는 프로젝트의 기본 브랜치에서 마지막 커밋을 위한 최신 파이프라인으로 리디렉션됩니다.

GitLab 13.0부터, 파이프라인 디렉터리을 다음을 기준으로 필터링할 수 있습니다:

트리거 저자
브랜치 이름
상태 (GitLab 13.1 및 이후)
태그 (GitLab 13.1 및 이후)
소스 (GitLab 14.3 및 이후)

GitLab 14.2부터, 파이프라인 열을 파이프라인 ID 또는 파이프라인 IID로 변경할 수 있습니다.

만일 GitLab CI/CD 구성을 편집하기 위해 VS Code를 사용하고 계시다면, GitLab Workflow VS Code 확장 프로그램을 사용하여 구성 유효성 검사 및 파이프라인 상태 보기를 할 수 있습니다.

매뉴얼으로 파이프라인 실행하기

파이프라인은 미리 정의된 또는 매뉴얼으로 지정된 변수와 함께 매뉴얼으로 실행할 수 있습니다.

파이프라인 결과(예: 코드 빌드)가 파이프라인의 표준 운영 외부에서 필요한 경우에 수행할 수 있습니다.

파이프라인을 매뉴얼으로 실행하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Build > Pipelines을 선택합니다.
파이프라인 실행을 선택합니다.
브랜치 이름 또는 태그에서 실행 필드에서 파이프라인을 실행할 브랜치 또는 태그를 선택합니다.
파이프라인 실행에 필요한 CI/CD 변수를 입력합니다. 특정 변수를 설정하여 양식에 사전 채워진 값을 설정할 수 있습니다.
파이프라인 실행을 선택합니다.

이제 파이프라인은 구성된대로 작업을 실행합니다.

매뉴얼 파이프라인에서 변수 사전 입력하기

GitLab 13.7에서 도입.

description 및 value 키워드를 사용하여 매뉴얼으로 파이프라인을 실행할 때 미리 채워진 파이프라인-수준(글로벌) 변수를 정의할 수 있습니다. 설명을 사용하여 해당 변수가 어떤 용도로 사용되는지 및 허용 가능한 값은 무엇인지 설명할 수 있습니다.

작업 수준 변수는 미리 채울 수 없습니다.

수동으로 트리거된 파이프라인에서는 .gitlab-ci.yml 파일에 정의된 description가 있는 모든 파이프라인-수준 변수가 파이프라인 실행 페이지에 표시됩니다. 설명은 해당 변수 아래에 표시됩니다.

이 프로세스를 사용하여 재정의된 변수는 확장, 그리고 가리지 않습니다. 구성 파일에서 변수에 대한 value를 정의하지 않으면 변수 이름은 여전히 나열되지만 값 필드는 비어 있습니다.

예를 들어:

variables:
  DEPLOY_CREDENTIALS:
    description: "The deployment credentials."
  DEPLOY_ENVIRONMENT:
    description: "Select the deployment target. Valid options are: 'canary', 'staging', 'production', or a stable branch of your choice."
    value: "canary"

이 예에서:

DEPLOY_CREDENTIALS은 파이프라인 실행 페이지에 값이 설정되지 않은 채로 나열됩니다. 사용자는 파이프라인을 매뉴얼으로 실행할 때마다 값을 정의해야 합니다.
DEPLOY_ENVIRONMENT은 파이프라인 실행 페이지에서 기본값으로 canary가 사전 입력되며, 메시지에서 다른 옵션에 대해 설명합니다.

알려진 문제로 컴플라이언스 파이프라인을 사용하는 프로젝트는 매뉴얼으로 파이프라인을 실행할 때 사전 입력된 변수가 나타나지 않을 수 있습니다. 이 문제를 해결하려면 컴플라이언스 파이프라인 구성을 변경하세요.

선택 가능한 사전 입력 변수 값 디렉터리 구성하기

GitLab 15.5에서 플래그 run_pipeline_graphql와 함께 도입. 기본값으로 비활성화됨.
options 키워드가 GitLab 15.7에서 도입되었습니다.
GitLab 15.7에서 일반적으로 사용 가능합니다. 피처 플래그 run_pipeline_graphql가 제거되었습니다.
버그로 인해 변수 디렉터리이 가끔 올바르게 채워지지 않는 경우가 있었으며, GitLab 15.9에서 해결되었습니다.

매뉴얼으로 파이프라인을 실행할 때 사용자가 선택할 수 있는 CI/CD 변수 값의 배열을 정의할 수 있습니다. 이러한 값은 파이프라인 실행 페이지의 드롭다운 디렉터리에 있습니다. options에 값 디렉터리을 추가하고 기본값을 value로 설정합니다. value의 문자열은 options 디렉터리에도 포함되어야 합니다.

예를 들어:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    options:
      - "production"
      - "staging"
      - "canary"
    description: "The deployment target. Set to 'staging' by default."

URL 쿼리 문자열을 사용하여 파이프라인 실행하기

GitLab 12.5에서 도입.

쿼리 문자열을 사용하여 파이프라인 실행 페이지를 미리 채울 수 있습니다. 예를 들어, 쿼리 문자열 .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar는 다음과 같이 파이프라인 실행 페이지를 미리 채웁니다.

실행 대상 필드: my_branch.
변수 섹션:
- 변수:
  - 키: foo
  - 값: bar
- 파일:
  - 키: file_foo
  - 값: file_bar

pipelines/new URL의 형식은 다음과 같습니다.

.../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value>

다음 매개변수가 지원됩니다.

ref: 실행 대상 필드에 채울 브랜치 지정.
var: 변수 변수를 지정.
file_var: 파일 변수를 지정.

각 var 또는 file_var마다 키와 값이 필요합니다.

파이프라인에 매뉴얼 상호 작용 추가하기

매뉴얼 작업을 사용하여 파이프라인에서 앞으로 진행하기 전에 매뉴얼 상호 작용을 요구할 수 있습니다.

파이프라인 그래프에서 직접 수행할 작업을 선택할 수 있습니다. 예를 들어, 파이프라인은 자동으로 시작될 수 있지만 특정 작업을 실행하기 전에 프로덕션으로 배포를 요청할 수 있습니다. 아래 예에서 production 단계는 매뉴얼 작업이 있는 작업을 포함합니다:

스테이지의 모든 매뉴얼 작업 시작

한 스테이지에 매뉴얼 작업만 포함되어 있다면 해당 스테이지 위의 Play all manual ()을 선택하여 모든 작업을 동시에 시작할 수 있습니다. 스테이지에 매뉴얼 작업이 아닌 작업이 포함되어 있다면, 이 옵션이 표시되지 않습니다.

파이프라인 건너뛰기

파이프라인을 트리거하지 않고 커밋을 푸시하려면 커밋 메시지에 [ci skip] 또는 [skip ci]를 추가하십시오. 대소문자를 구분하지 않습니다.

또는 Git 2.10 이상을 사용하는 경우 ci.skip Git 푸시 옵션을 사용하십시오. ci.skip 푸시 옵션은 Merge Request 파이프라인을 건너뛰지 않습니다.

파이프라인 삭제

GitLab 12.7에 도입됨.

프로젝트의 소유자 역할을 하는 사용자는 Build > 파이프라인에서 파이프라인을 선택하여 파이프라인 세부 정보 페이지로 이동한 다음 삭제를 선택하여 파이프라인을 삭제할 수 있습니다.

파이프라인을 삭제하면 자동으로 하위 파이프라인이 삭제되지 않습니다. 자세한 내용은 관련 이슈를 참조하십시오.

파이프라인을 삭제하면 모든 파이프라인 캐시가 만료되며 빌드, 로그, 아티팩트 및 트리거와 같은 모든 관련 개체가 삭제됩니다. 이 작업은 되돌릴 수 없습니다.

보호된 브랜치에서의 파이프라인 보안

파이프라인이 보호된 브랜치에서 실행되는 경우 엄격한 보안 모델이 적용됩니다.

사용자가 해당 특정 브랜치에 Merge 또는 푸시할 수 있는 경우 보호된 브랜치에서 다음 작업이 허용됩니다.

매뉴얼 파이프라인 실행 (웹 UI 또는 파이프라인 API 사용).
예약된 파이프라인 실행.
트리거를 사용하여 파이프라인 실행.
온디맨드 DAST 스캔 실행.
기존 파이프라인에서 매뉴얼 작업 트리거.
기존 작업 다시 시도 또는 취소 (웹 UI 또는 파이프라인 API 사용).

보호된 변수는 보호된 브랜치의 파이프라인에서 실행되는 작업에서 액세스할 수 있습니다. 민감한 정보인 배포 자격 증명 및 토큰과 같은 정보에 액세스할 권한이 있는 경우에만 사용자에게 보호된 브랜치에 대한 Merge 권한을 할당하십시오.

보호된 러너(runner)는 보호된 브랜치에서만 작업을 실행할 수 있으며 신뢰할 수 없는 코드가 보호된 러너(runner)에서 실행되는 것을 방지하고 배포 키 및 기타 자격 증명이 의도치 않게 액세스되는 것을 방지합니다. 보호된 러너(runner)에서 실행되도록 의도된 작업이 일반 러너(runner)를 사용하지 않도록하려면 해당 태그를 지정해야합니다.

파이프라인의 보안을 확보하는 추가적인 보안 권고 사항은 배포 안전 페이지를 참조하십시오.

상위 프로젝트가 다시 빌드될 때 파이프라인 트리거

Tier: Premium, Ultimate Offering: GitLab.com, 세터 메니지드, GitLab Dedicated

GitLab 12.8에 도입됨.

다른 프로젝트의 새로운 태그에 대한 파이프라인이 완료되면 해당 프로젝트에서 파이프라인을 트리거할 수 있습니다.

전제 조건:

상위 프로젝트는 공개해야 합니다.
사용자는 상위 프로젝트에서 개발자 역할을 가져야 합니다.

상위 프로젝트가 다시 빌드될 때 파이프라인을 트리거하려면 다음을 수행하세요.

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > CI/CD를 선택합니다.
파이프라인 구독을 확장합니다.
프로젝트 추가를 선택합니다.
<네임스페이스>/<프로젝트> 형식으로 구독할 프로젝트를 입력합니다. 예를 들어 프로젝트가 https://gitlab.com/gitlab-org/gitlab인 경우 gitlab-org/gitlab을 사용합니다.
구독을 선택합니다.

구독된 프로젝트의 새로운 태그에 대해 성공적으로 완료된 모든 파이프라인은 현재 프로젝트의 기본 브랜치에서 파이프라인을 트리거합니다. 상위 및 하위 프로젝트에 대한 최대 파이프라인 구독 수는 기본적으로 2개입니다. 세터 메니지드 인스턴스에서는 관리자가 이 제한을 변경할 수 있습니다.

파이프라인 지속 시간 계산 방법

특정 파이프라인의 총 실행 시간에는 다음이 제외됩니다.

작업이 다시 시도되거나 매뉴얼으로 다시 실행된 경우 초기 실행의 지속 시간.
대기 (대기열) 시간.

즉, 작업이 다시 시도되거나 매뉴얼으로 다시 실행되면 최신 실행의 지속 시간만이 총 실행 시간에 포함됩니다.

각 작업은 기간으로 표시되며 이는 다음으로 구성됩니다.

기간#처음 (작업 시작 시간).
기간#마지막 (작업 종료 시간).

간단한 예로:

A (0, 2)
A’ (2, 4)
- A를 다시 실행함
B (1, 3)
C (6, 7)

위의 예시에서:

A는 0에서 시작하여 2에서 종료합니다.
A’는 2에서 시작하여 4에서 종료합니다.
B는 1에서 시작하여 3에서 종료합니다.
C는 6에서 시작하여 7에서 종료합니다.

시각적으로는 다음과 같이 볼 수 있습니다.

0  1  2  3  4  5  6  7
AAAAAAA
   BBBBBBB
      A'A'A'A
                  CCCC

A가 다시 실행되었기 때문에 A만 무시하고 A’만 계산합니다. B, A’, C의 연합은 (1, 4) 및 (6, 7)입니다. 따라서 총 실행 시간은 다음과 같습니다.

(4 - 1) + (7 - 6) => 4

파이프라인 시각화

파이프라인은 많은 순차 및 병렬 작업으로 구성된 복잡한 구조일 수 있습니다.

파이프라인 흐름을 이해하기 쉽게 하기 위해 GitLab에는 파이프라인 및 상태를 볼 수 있는 파이프라인 그래프가 있습니다.

파이프라인 그래프는 큰 그래프 또는 미니어처 표현으로 표시할 수 있습니다. 페이지에 액세스하는 방법에 따라 다릅니다.

GitLab은 파이프라인 그래프에서 스테이지 이름을 대문자로 작성합니다.

전체 파이프라인 그래프 보기

GitLab 13.11에서 소개된 시각화 개선 사항.

파이프라인 상세 페이지는 파이프라인의 모든 작업에 대한 전체 파이프라인 그래프를 표시합니다.

다음과 같이 작업을 그룹화할 수 있습니다:

동일한 단계에 있는 작업을 동일한 열에 배열하는 단계별 그룹화:
작업 의존성, 이는 작업을 needs 의존성에 따라 배열합니다.

다중 프로젝트 파이프라인 그래프를 사용하면 교차 프로젝트 의존성을 포함하여 전체 파이프라인을 시각화할 수 있습니다.

한 단계에 100개 이상의 작업이 포함된 경우, 파이프라인 그래프에는 처음 100개의 작업만 나열됩니다. 나머지 작업은 계속해서 실행됩니다. 작업을 보려면:

파이프라인을 선택하면, 작업이 파이프라인 상세 페이지 오른쪽에 나열됩니다.
왼쪽 사이드바에서 Build > Jobs를 선택합니다.

파이프라인 그래프에서 작업 의존성 보기

GitLab 13.12에서 소개됨.
GitLab 14.0에서 기본적으로 활성화됨.
GitLab 14.2에서 피처 플래그가 제거됨.

파이프라인 그래프에서 작업을 needs 의존성에 따라 배열하려면 Group jobs by 섹션에서 Job dependencies를 선택합니다. 이 옵션은 needs 작업 의존성이 있는 3개 이상의 작업을 포함하는 파이프라인에 대해 사용할 수 있습니다.

가장 왼쪽 열에 있는 작업이 먼저 실행되고, 그에 종속된 작업들은 다음 열에 그룹화됩니다.

예를 들어 test-job1은 첫 번째 열의 작업에만 종속되므로 왼쪽에서 두 번째 열에 표시됩니다. deploy-job1은 첫 번째 및 두 번째 열의 작업에 종속되어 있으며 세 번째 열에 표시됩니다:

작업 간의 needs 관계를 보여주는 선을 추가하려면 Show dependencies 토글을 선택합니다. 이러한 선은 needs visualization과 유사합니다:

작업의 전체 needs 의존성 트리를 보려면 해당 작업 위로 마우스를 올립니다:

파이프라인 미니 그래프

파이프라인 미니 그래프는 적은 공간을 차지하며 모든 작업이 통과했는지 또는 실패한 것이 있는지를 빠르게 확인할 수 있습니다. 파이프라인 미니 그래프는 다음 위치에서 찾을 수 있습니다:

파이프라인 인덱스 페이지.
단일 커밋 페이지.
Merge Request 페이지.
파이프라인 편집기(GitLab 14.5부터)

파이프라인 미니 그래프를 사용하면 단일 커밋에 대한 모든 관련 작업과 파이프라인 각 단계의 순차적인 결과를 볼 수 있습니다. 이를 통해 빠르게 실패한 작업을 확인하고 수정할 수 있습니다.

파이프라인 미니 그래프는 단계별로만 작업을 표시합니다.

파이프라인 미니 그래프의 단계는 확장할 수 있습니다. 각 단계 위로 마우스를 올려 이름 및 상태를 보고 단계를 선택하여 해당 작업 디렉터리을 확장할 수 있습니다.

미니 그래프	확장된 미니 그래프

파이프라인 성공 및 기간 차트

파이프라인 분석은 CI/CD 분석 페이지에서 사용할 수 있습니다.

파이프라인 뱃지

파이프라인 상태 및 테스트 커버리지 보고서 뱃지는 각 프로젝트에 대해 사용할 수 있으며 구성할 수 있습니다. 프로젝트에 파이프라인 뱃지를 추가하는 방법에 대한 정보는 파이프라인 뱃지를 참조하십시오.

파이프라인 API

GitLab은 다음과 같은 API 엔드포인트를 제공합니다:

기본 기능 수행. 자세한 내용은 파이프라인 API를 참조하십시오.
파이프라인 스케줄 유지. 자세한 내용은 파이프라인 스케줄 API를 참조하십시오.
파이프라인 실행 트리거. 자세한 내용은:
- API를 통한 파이프라인 트리거를 참조하십시오.
- 파이프라인 트리거 API를 참조하십시오.

CI/CD 파이프라인

파이프라인의 유형

파이프라인 구성

실행자를 위한 Ref Spec

파이프라인 보기

매뉴얼으로 파이프라인 실행하기

매뉴얼 파이프라인에서 변수 사전 입력하기

선택 가능한 사전 입력 변수 값 디렉터리 구성하기

URL 쿼리 문자열을 사용하여 파이프라인 실행하기

파이프라인에 매뉴얼 상호 작용 추가하기

스테이지의 모든 매뉴얼 작업 시작

파이프라인 건너뛰기

파이프라인 삭제

보호된 브랜치에서의 파이프라인 보안

상위 프로젝트가 다시 빌드될 때 파이프라인 트리거

파이프라인 지속 시간 계산 방법

파이프라인 시각화

전체 파이프라인 그래프 보기

파이프라인 그래프에서 작업 의존성 보기

파이프라인 미니 그래프

파이프라인 성공 및 기간 차트

파이프라인 뱃지

파이프라인 API

도움말

기능 사용 가능성과 제품 평가판

도움받기