GitLab 공식 CI/CD 구성 요소 개발 가이드

이 문서는 GitLab이 유지 관리하는 CI/CD 구성 요소를 개발하는 방법을 설명합니다. 공식 공개 구성 요소 또는 내부 사용을 위한 구성 요소입니다.

모든 공식 GitLab 구성 요소 프로젝트의 위치는 gitlab.com/components 그룹입니다.
이 그룹은 일반화된 구성 요소로 설계되어 모든 GitLab 사용자에게 제공되며 GitLab에 의해 유지 관리되는 모든 구성 요소를 포함합니다.
예를 들어: SAST, 비밀 감지 및 코드 품질 구성 요소입니다.
구성 요소 프로젝트는 초기에는 다른 그룹(예: gitlab-org)에 생성될 수 있지만,
첫 번째 버전이 카탈로그에 게시되기 전에 components 그룹으로 이동해야 합니다.

GitLab 내부에서만 사용되는 구성 요소는 gitlab-org/gitlab 프로젝트에 특정한 경우와 같이,
gitlab-org 그룹 아래에서 구현되어야 합니다.

CI/CD 카탈로그에 게시될 것으로 예상되는 구성 요소 프로젝트는
먼저 dogfooding을 통해 프로젝트 품질을 유지하고
첫-hand 경험을 확보해야 합니다.

소유권 정의

공식 GitLab 구성 요소는 커뮤니티에 신뢰받으며, 높은 품질과 적시 유지 관리가 필요합니다.
구성 요소는 최신 상태로 유지되어야 하며, 보안 취약점 및 버그가 모니터링되고 수정되어야 합니다.

각 구성 요소 프로젝트는 소유자와 유지 관리자의 집합이 필요하며, 이들은 도메인 전문가여야 합니다.
전문가는 Engineering부터 Support, Customer Success, Developer Relations 등
GitLab의 어떤 부서에서도 올 수 있습니다.

구성 요소가 GitLab 기능(예: 비밀 감지)과 관련된 경우,
기능 카테고리를 소유하거나 가장 밀접하게 관련된 팀이 프로젝트를 유지 관리해야 합니다.
이 경우, 기능 카테고리의 Engineering Manager가 프로젝트 소유자로 지정됩니다.

프로젝트에 대한 owner 역할을 가진 구성원은
열려 있는 문제와 병합 요청을 신속하게 처리하기 위해 책임을 져야 합니다.

구성 요소 프로젝트는 초기에는 별도의 팀이나 개인이 생성할 수 있지만,
첫 번째 버전이 카탈로그에 게시되기 전에 소유자 집합으로 전환되어야 합니다.

프로젝트 리포지토리의 README.md 파일은
필요할 경우 넓은 커뮤니티에서 연락할 수 있도록
프로젝트의 주요 소유자를 표시해야 합니다.

참고:
프로젝트 소유자의 집합을 보장할 수 없거나 구성 요소를 dogfooding할 수 없는 경우,
공식 GitLab 구성 요소 프로젝트를 만들지 않기를 강력히 권장하며,
대신 넓은 커뮤니티가 카탈로그에서 수요를 충족하도록 해야 합니다.

개발 프로세스

gitlab.com/components에서 프로젝트를 생성하거나
그룹 소유자 중 한 명에게 빈 프로젝트를 생성해 달라고 요청합니다.
구성 요소를 생성하기 위한 표준 가이드를 따릅니다.
구성 요소 프로젝트가 제공하는 기능을 명확히 설명하는 간결한 프로젝트 설명을 추가합니다.
구성 요소 작성 및
공식 구성 요소에 대한 일반 지침을 따릅니다.
MIT 라이센스가 포함된 LICENSE.md 파일을 추가합니다. (예제)
프로젝트에는 다음과 같은 .gitlab-ci.yml 파일이 있어야 합니다:
- 프로젝트의 모든 구성 요소가 올바르게 검증됩니다.
  (예제).
- 새롭게 릴리스된 태그를 카탈로그에 게시하기 위한 release 작업이 포함됩니다.
  (예제).
공식 구성 요소 프로젝트의 경우,
구성 요소 프로젝트에 공식 아바타 이미지를 업로드합니다.

공식 구성 요소에 대한 모범 사례

README.md에 아래 섹션이 최소한 포함되어 있는지 확인합니다 (예를 들어, 코드 품질 구성 요소를 참조하세요):
- 개요: 구성 요소 프로젝트가 제공하는 기능.
- 구성 요소: 각 구성 요소에 대한 하위 섹션으로, 각 하위 섹션에는:
  - 사용법: 입력이 있는 예시와 없는 예시 (선택 사항인 경우).
  - 입력: 입력 이름, 유형, 기본 값(있는 경우) 및 설명을 보여주는 표.
  - 변수 (해당하는 경우): 변수 이름, 가능한 값 및 설명.
- 기여: 참고 사항 및 유지 관리 담당자와 연락하는 방법. 일반적으로 기여 프로세스는 공식 가이드를 따라야 합니다.
복합 입력 이름에는 언더스코어 _를 사용하고, 필요 시 구분자로 하이픈 -을 사용합니다. 예: service_x-project_name.

공식 구성 요소에 대한 검토 및 기여 프로세스

프로젝트의 구성 요소에 관련된 CI/CD 템플릿이 GitLab 코드베이스에 있을 수 있습니다.

그 경우 구성 요소 프로젝트와 CI/CD 템플릿을 서로 연결해야 합니다:

관련 구성 요소 프로젝트의 위치에 대한 주석을 CI/CD 템플릿에 추가합니다.
기존 CI/CD 템플릿의 위치에 대한 섹션을 구성 요소 프로젝트의 README.md에 추가합니다.

이 구성 요소에 변경 사항이 적용될 때, CI/CD 템플릿에 변경 사항을 통합할 수 있는지 확인합니다.

버전 관리의 엄격성 때문에 이는 불가능할 수 있습니다.

구성 요소가 일관된 스타일로 작성되었고 모범 사례를 따르는지 확인하기 위해 유지 관리 담당자에게 리뷰를 요청하세요.

GitLab 공식 구성 요소의 기본 유지 관리 담당자

gitlab.com/components 그룹 아래의 각 구성 요소 프로젝트는 특정 DRI 및 유지 관리 책임자를 가져야 합니다.

그러나 @gitlab-org/maintainers/ci-components 유지 관리 담당자 그룹은 전반적으로 components 그룹을 관리하는 책임이 있습니다.

이 유지 관리 담당자 그룹의 책임:

최고의 개발 경험을 제공하기 위해 툴킷 구성 요소 및 프로젝트 템플릿과 같은 개발 및 도우미 리소스를 관리합니다.
명확한 DRI가 없는 구성 요소 프로젝트 또는 개발 중인 구성 요소 프로젝트를 관리하고 장기적으로 적합한 소유자를 찾기 위해 노력합니다.
개별 구성 요소 프로젝트의 유지 관리 담당자를 안내하고 멘토링하며, 코드 리뷰 및 문제 해결 중에 지원합니다.
모범 사례가 적용되고 시간이 지남에 따라 개선되도록 보장합니다.

유지 관리 담당자가 되기 위한 요구 사항:

CI/CD YAML 문법 및 기능에 대한 깊이 있는 이해.
CI 구성 요소가 작동하는 방식 이해 및 개발 경험 보여주기.
구성 요소 작성 방법에 대한 확고한 이해.

gitlab-components 일반 유지 관리 담당자 그룹에 가입하는 방법:

gitlab-components 유지 관리 담당자가 되는 과정을 검토합니다.