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 내부 사용에만 해당되는 구성 요소는 gitlab-org 그룹 하에 구현되어야 합니다.

CI/CD 카탈로그에 게시될 예정인 구성 요소 프로젝트는 프로젝트 품질을 최상으로 유지하고 직접적인 경험을 가지기 위해 제먹토를 사용하여 구축되어야 합니다.

소유 정의

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

각 구성 요소 프로젝트는 도메인 전문가인 일부 소유자 및 유지 관리자를 가져야 합니다.
전문가는 GitLab의 어떤 부서에서든 올 수 있으며, 엔지니어링부터 지원, 고객 성공, 개발자 관련 부서까지 가능합니다.

구성 요소가 GitLab 기능과 관련이 있다면(예: Secret Detection 등), 해당 기능 범주를 소유하거나 가장 밀접한 관련 부서가 프로젝트를 유지해야 합니다.
이 경우, 해당 기능 범주의 엔지니어링 관리자가 프로젝트 소유자로 할당됩니다.

프로젝트의 소유자 역할을 하는 멤버는 보다 광범위한 커뮤니티가 필요할 때 열린 이슈 및 병합 요청의 분류를 책임져 즉시 처리되도록 해야 합니다.

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

프로젝트 저장소의 README.md 파일에 프로젝트의 주요 소유자를 나타내어 필요 시 더 넓은 커뮤니티가 연락할 수 있도록 해야 합니다.

참고: 프로젝트 소유자 집합을 보장할 수 없거나 구성 요소를 제작하지 못하게 되는 경우, 공식 GitLab 구성 요소 프로젝트를 만들지 말고 대신 더 넓은 커뮤니티가 카탈로그의 수요를 충족하도록 해야 합니다.

개발 프로세스

  1. gitlab.com/components 하위에 프로젝트를 생성하거나 그룹 소유자 중 한 명에게 빈 프로젝트 생성을 요청합니다.
  2. 구성 요소 작성을 위한 표준 가이드를 따릅니다.
  3. 구성 요소 프로젝트가 제공하는 기능을 명확하게 설명하는 간결한 프로젝트 설명을 추가합니다.
  4. 구성 요소 작성을 위한 일반적인 지침 및 공식 구성 요소용 가이드를 준수해야 합니다.
  5. MIT 라이센스의 LICENSE.md 파일을 추가합니다 (예시).
  6. 프로젝트에는 다음이 포함된 .gitlab-ci.yml 파일이 있어야 합니다:
    • 프로젝트 내 모든 구성 요소를 올바르게 유효성 검사합니다 (예시).
    • 새로 게시된 태그를 카탈로그에 발행하는 릴리스 작업이 포함되어 있어야 합니다 (예시).
  7. 공식 구성 요소 프로젝트인 경우, 구성 요소 프로젝트에 공식 아바타 이미지를 업로드합니다.

공식 구성 요소용 최상의 실천 방법

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

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

프로젝트의 구성 요소에는 GitLab 코드베이스에 관련된 CI/CD 템플릿이 있을 수 있습니다.
이 경우, 프로젝트 구성 요소와 CI/CD 템플릿을 상호 연관시켜야 합니다:

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

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

기본 유지 관리자 중 다음의 유지 관리자 중 한 명을 핑하여 구성 요소가 일관된 스타일로 작성되었는지 확인하고 최상의 실천 방법을 준수해야 합니다.

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

gitlab.com/components 그룹에 속한 각 구성 요소 프로젝트에는 구체적인 DRI 및 유지 관리자가 있어야 하지만, 유지 관리자 그룹은 components 그룹을 일반적으로 관리하는 @gitlab-org/maintainers/ci-components 그룹에 속해 있으며 해당 그룹은 다음과 같은 책임을 지게 됩니다.

  • 최상의 개발 경험을 제공하기 위해 툴킷 구성 요소 및 프로젝트 템플릿과 같은 모든 개발 및 도우미 리소스를 관리합니다.
  • 명확한 DRI가 없는 프로젝트를 관리하거나 장기적으로 올바른 소유자를 찾을 수 있도록 함께 작동합니다.
  • 개별 구성 요소 프로젝트의 유지 관리자를 지도하고 지법 검토 및 문제 해결 중에 포함하여 최상의 실천 방법이 적용되고 시간이 지남에 따라 향상되도록 합니다.

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

  • CI/CD YAML 구문 및 기능에 대한 심층적인 이해.
  • CI 구성 요소가 작동하는 방법을 이해하고 이를 개발하는 데 경험을 보여주어야 합니다.
  • 구성 요소 작성 방법에 대해 solide 이해가 있어야 합니다.

일반 유지 관리자 그룹인 gitlab-components 그룹에 참여하는 방법: