CI/CD Pipelines
파이프라인은 지속적 통합, 제공 및 배포의 최상위 구성 요소입니다.
파이프라인은 다음으로 구성됩니다.
- 수행할 Job을 정의하는 jobs. 예를 들어, 코드를 컴파일하거나 테스트하는 작업.
- Job을 실행할 시기를 정의하는 Stages. 예를 들어, 코드를 컴파일하는 단계 후에 테스트를 실행하는 단계.
Job은 러너(Runner)에 의해 실행됩니다. 동시(concurrent) 러너가 충분하면, 동일한 단계의 여러 job이 병렬로 실행됩니다.
한 단계의 모든 job이 성공하면, 파이프라인은 다음 단계로 넘어갑니다.
한 단계의 어떤 job이 실패하면, 다음 단계는 (일반적으로) 실행되지 않고 파이프라인이 일찍 종료됩니다.
일반적으로 파이프라인은 자동으로 실행되며 생성된 후에는 개입이 필요하지 않습니다. 그러나 수동으로 파이프라인과 상호 작용할 수 있는 예도 있습니다.
일반적인 파이프라인은 다음 순서로 실행되는 네 개의 단계로 구성될 수 있습니다.
compile
이라는 job이 있는build
단계test1
및test2
라는 두 개의 job이 있는test
단계deploy-to-stage
라는 job이 있는staging
단계deploy-to-prod
라는 job이 있는production
단계
GitLab이 가져오는 미러 리포지터리가 있다면, 프로젝트의 Settings > Repository > Mirroring repositories > Trigger pipelines for mirror updates 에서 파이프라인 트리거를 활성화해야 합니다.
파이프라인 유형
파이프라인은 다양한 방식으로 구성될 수 있습니다.
- 기본 파이프라인은 각 스테이지의 모든 job을 동시에 실행하고, 다음 스테이지로 넘어갑니다.
- Directed Acyclic Graph(DAG) 파이프라인은 job 간의 관계에 기반하며, 기본 파이프라인보다 더 빨리 실행될 수 있습니다.
- Merge Request 파이프라인은 Merge Request에만 실행됩니다(모든 커밋이 아닌).
- Merge 결과 파이프라인은 소스 브랜치의 변경 사항이 타깃 브랜치로 이미 merge 된 것처럼 동작하는 Merge Request 파이프라인입니다.
- Merge Train은 merge 결과 파이프라인을 사용해 merge를 차례로 대기열에 넣습니다.
- 상하위 파이프라인은 복잡한 파이프라인을 하나의 상위 파이프라인으로 분류해 여러 하위 서브 파이프라인을 트리거할 수 있습니다. 이는 동일한 프로젝트에서, 동일한 SHA로 모두 실행됩니다. 파이프라인 아키텍처는 보통 모노레포(mono-repos)에 사용됩니다.
- 멀티 프로젝트 파이프라인은 다양한 프로젝트의 파이프라인을 함께 결합합니다.
파이프라인 구성하기
파이프라인과 그 구성 요소인 job, 스테이지는 각 프로젝트의 CI/CD 파이프라인 구성 파일에 정의됩니다.
- Job은 기본 구성 컴포넌트입니다.
- 스테이지는
stage
키워드를 사용해 정의됩니다.
CI 파이프라인 파일의 구성 옵션 목록을 보려면 GitLab CI/CD 파이프라인 구성 레퍼런스를 확인하세요.
GitLab UI를 통해 파이프라인의 특정 측면을 구성할 수도 있습니다. 예를 들면 다음과 같습니다.
- 각 프로젝트의 파이프라인 설정
- 파이프라인 스케줄
- 맞춤형 CI/CD 변수
러너 위한 ref 사양
러너가 파이프라인 job을 선택할 때, GitLab은 해당 job의 메타데이터를 제공합니다. 이는 프로젝트 리포지터리에서 체크아웃한 ref(예: 브랜치 또는 태그)와 커밋(SHA1)을 나타내는 Git refspec을 포함합니다.
이 표는 각 파이프라인 유형에 적용한 refspec을 정리했습니다.
파이프라인 유형 | Refspec |
---|---|
브랜치의 파이프라인 | +<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> |
ref refs/heads/<name>
과 refs/tags/<name>
은 프로젝트 리포지터리에 있습니다. GitLab은 파이프라인 job을 실행하는 동안 특수 ref refs/pipelines/<id>
를 생성합니다. 이 ref는 관련 브랜치 또는 태그가 지워진 뒤에도 생성될 수 있습니다. 따라서 이는 자동으로 환경을 중지하기, 브랜치 삭제 후 파이프라인을 실행할 수 있는 merge train과 같은 일부 기능에 유용할 수 있습니다.
파이프라인 보기
프로젝트의 Build > Pipelines 페이지에서 현재 및 이전 파이프라인 실행을 찾을 수 있습니다. 또한, Merge Request의 Pipelines 탭으로 이동하여 파이프라인에 액세스할 수도 있습니다.
파이프라인을 클릭하여 Pipeline Details 페이지를 열고 해당 파이프라인에 대해 실행된 job을 표 시합니다. 여기에서 실행 중인 파이프라인을 취소하거나 실패한 파이프라인에서 job을 다시 시도하거나 파이프라인을 삭제할 수 있습니다.
특정 브랜치의 마지막 커밋에 대한 최신 파이프라인의 링크는 /project/-/pipelines/[branch]/latest
에서 사용할 수 있습니다. 또한 /project/-/pipelines/latest
는 프로젝트의 기본 브랜치에 대한 마지막 커밋의 최신 파이프라인으로 리디렉션합니다.
GitLab 13.0부터 다음을 기준으로 파이프라인 목록을 필터링할 수 있습니다.
- 트리거 작성자
- 브랜치 이름
- 상태 (GitLab 13.1 이상)
- 태그 (GitLab 13.1 이상)
- 소스 (GitLab 14.3 이상)
GitLab 14.2부터 파이프라인 칼럼을 변경해 파이프라인 ID 또는 파이프라인 IID를 표시할 수 있습니다.
VS Code를 사용해 GitLab CI/CD 구성을 편집하면, GitLab Workflow VS Code extension으로 구성을 승인하고, 파이프라인 상태를 볼 수 있습니다.
수동으로 파이프라인 실행
파이프라인은 사전 정의되거나 수동으로 지정된 변수를 사용하여 수동으로 실행할 수 있습니다.
파이프라인의 정상적인 작동 범위 외부에서 파이프라인의 결과(예 : 코드 빌드)가 필요한 경우 이 작업을 수행할 수 있습니다.
파이프라인을 수동으로 실행하려면 :
- 왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
- Build > Pipelines 버튼을 클릭합니다.
- Run Pipeline 버튼을 클릭합니다.
- Run for branch name or tag 필드에서 파이프라인을 실행할 브랜치나 태그를 선택합니다.
- 파이프라인 실행에 필요한 CI/CD 변수를 입력합니다. 특정 변수를 설정해 해당 값이 양식에 미리 채워지도록 할 수 있습니다.
- Run Pipeline 버튼을 클릭합니다.
이제 파이프라인은 구성된 대로 job을 실행합니다.