GitLab 공식 CI/CD 구성 요소 개발 안내서

이 문서는 GitLab이 유지보수하는 CI/CD 구성 요소를 개발하는 방법에 대해 설명합니다. 이는 공식 공개용이거나 내부 사용을 위한 구성 요소입니다.

모든 공식 GitLab 구성 요소 프로젝트의 위치는 gitlab.com/components 그룹입니다. 이 그룹에는 모든 GitLab 사용자에게 제공되고 GitLab에서 유지보수되는 일반적인 구성 요소가 포함되어 있습니다. 예를 들어, SAST, Secret Detection 및 Code Quality 구성 요소가 있습니다. 구성 요소 프로젝트는 초기에 다른 그룹(예: gitlab-org)에 생성될 수 있지만, 카탈로그에 처음으로 버전이 게시되기 전에 components 그룹으로 이동해야 합니다.

GitLab 내부 사용을 위한 구성 요소는 예를 들어 특정 gitlab-org/gitlab 프로젝트와 관련된 경우, gitlab-org 그룹에 구현되어야 합니다.

CI/CD 카탈로그에 게시될 예정인 구성 요소 프로젝트는 먼저 dogfooded되어 해당 프로젝트의 품질을 유지하고 직접 경험할 수 있도록 해야 합니다.

소유권 정의

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

각 구성 요소 프로젝트는 도메인 전문가인 소유자 및 유지 보수 담당자의 집합이 있어야 합니다. 전문가는 Engineering부터 Support, 고객성공팀, 개발자 연락 담당까지 어떤 부서에서든 될 수 있습니다.

구성 요소가 GitLab 기능과 관련된 경우(예: Secret Detection), 기능 범주를 소유하는 팀 또는 가장 관련된 팀이 프로젝트를 유지 보수해야 합니다. 이 경우, 해당 기능 범주의 Engineering Manager가 프로젝트 소유자로 할당됩니다.

프로젝트의 소유자 역할을 하는 멤버는 빠르게 대응할 수 있도록 오픈된 이슈 및 병합 요청을 분류하는 데 책임이 있습니다.

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

프로젝트 저장소의 README.md 파일에는 프로젝트의 주요 소유자들이 나열되어 있어 넓은 커뮤니티에서 필요할 경우에 연락할 수 있습니다.

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

개발 프로세스

gitlab.com/components 하위에 프로젝트를 생성하거나 그룹 소유자에게 빈 프로젝트를 생성해달라고 요청하십시오.
구성 요소 생성에 대한 표준 가이드를 따르십시오.
구성 요소 프로젝트가 제공하는 능력을 명확히 설명하는 간결한 프로젝트 설명을 추가하십시오.
공통 Best Practices와 함께 공식 구성 요소용 Best Practices를 따르는지 확인하십시오.
MIT 라이센스가 포함된 LICENSE.md 파일을 추가하십시오.
프로젝트에는 다음을 포함하는 .gitlab-ci.yml 파일이 있어야 합니다:
- 프로젝트의 모든 구성 요소를 정확하게 검증합니다.
- 새로운 릴리스 태그를 카탈로그에 게시하는 release 작업을 포함합니다.
공식 구성 요소 프로젝트의 경우, 공식 아바타 이미지를 구성 요소 프로젝트에 업로드하십시오.

공식 구성 요소용 Best Practices

README.md에 적어도 아래 섹션들이 포함되어 있는지 확인하십시오(예: Code quality component 참조):
- 개요: 구성 요소 프로젝트가 제공하는 능력.
- 구성 요소: 각 구성 요소에 대한 하위 섹션이 포함되어 있으며, 각각에 대해 다음이 포함되어 있습니다:
  - 사용법: 입력이 필요한 경우(옵션) 예제.
  - 입력: 입력 이름, 유형, 기본 값(있는 경우) 및 설명이 표시된 테이블.
  - 변수(해당하는 경우): 변수 이름, 가능한 값, 설명이 표시됩니다.
- 기여: 참고 사항 및 유지 보수 담당자와 연락하는 방법입니다. 일반적으로 기여 프로세스는 공식 가이드를 따라야 합니다.
필요한 경우 구성 항목에는 composite 입력 이름에는 _를 사용하고 필요한 경우 구분자로 -를 사용합니다. 예: service_x-project_name.

공식 구성 요소용 검토 및 기여 프로세스

프로젝트 내의 구성 요소가 GitLab 코드베이스에 관련된 CI/CD 템플릿을 가지고 있는 가능성이 있습니다. 그런 경우, 구성 요소 프로젝트와 CI/CD 템플릿을 상호 연결해야 합니다.

CI/CD 템플릿의 관련된 구성 요소 프로젝트 위치를 주석으로 추가합니다.
구성 요소 프로젝트의 README.md에 기존 CI/CD 템플릿의 위치를 나타내는 섹션을 추가합니다.

이러한 구성 요소에 변경 사항이 적용되면 해당 변경 사항을 CI/CD 템플릿에 통합할 수 있는지 확인합니다. CI/CD 템플릿의 버전 관리의 제한으로 인해 이것이 불가능할 수 있습니다.

유지 보수자들 중 한 명에게 리뷰 요청을 보내어 구성 요소가 일관된 스타일로 작성되고 Best Practices를 따르고 있는지 확인하십시오.

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

gitlab.com/components 그룹 내의 각 구성 요소 프로젝트는 특정한 DRIs(직접적으로 책임지는 개인) 및 유지 관리자를 가져야하지만, @gitlab-org/maintainers/ci-components 유지 관리자 그룹은 일반적으로 components 그룹을 관리하는 것을 책임집니다.

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

최고의 개발 경험을 제공하기 위해 툴킷 구성 요소 및 프로젝트 템플릿과 같은 개발 및 보조 리소스를 관리합니다.
명확한 DRI가 없거나 개발 중인 구성 요소 프로젝트를 관리하고 장기적으로 적절한 소유자를 찾는 데 작업합니다.
개별 구성 요소 프로젝트의 유지 관리자를 이끌고 지도하며, 코드 리뷰 및 문제 해결 중에 이를 지원합니다.
시간이 흘러도록 최상의 관례가 적용되고 개선되도록 합니다.

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

CI/CD YAML 구문 및 기능에 대한 심층적인 이해.
CI 구성 요소가 어떻게 작동하는지 이해하고, 그 개발 경험을 증명할 수 있는 능력.
구성 요소의 최상의 관행을 확고히 이해.

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

gitlab-components 유지 관리자가 되는 과정을 검토하세요.