GitLab 공식 CI/CD 컴포넌트 개발 가이드

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

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

gitlab-org/gitlab 프로젝트와 관련된 GitLab 내부 사용 전용 컴포넌트는 gitlab-org 그룹 하에 구현되어야 합니다.

CI/CD 카탈로그에 게시될 예정인 컴포넌트 프로젝트는 우선 dogfooded되어야 합니다. 이는 프로젝트 품질을 유지하고 직접적인 경험을 통해 프로젝트에 대해 파악하기 위함입니다.

소유 정의

공식 GitLab 컴포넌트들은 커뮤니티에서 신뢰할 수 있으며 고도의 품질과 적시에 유지 보수가 필요합니다. 컴포넌트는 최신 상태를 유지하고 보안 취약점을 모니터링하고 버그를 수정해야 합니다.

각 컴포넌트 프로젝트는 도메인 전문가인 소유자와 유지 관리자 집합을 가져야 합니다. 전문가는 Engineering에서 Support, Customer Success, Developer Relations까지 모든 부서에서 올 수 있습니다.

만약 컴포넌트가 GitLab 기능과 관련이 있다면 (예: Secret Detection), 해당 기능 범주를 소유한 팀 또는 가장 가까운 관련은 프로젝트를 유지 관리해야 합니다. 이 경우, 해당하는 엔지니어링 매니저가 프로젝트 소유자로 할당됩니다.

프로젝트의 owner 역할을 가진 멤버는 열려 있는 문제 및 Merge Request을 신속하게 해결하기 위해 책임을 져야 합니다.

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

프로젝트 리포지터리의 README.md 파일은 프로젝트의 주요 소유자를 나타내어 필요 시 넓은 커뮤니티에서 연락을 취할 수 있도록 해야 합니다.

note
프로젝트 소유자 집합이 보장되지 않거나 컴포넌트가 dogfooded될 수 없다면, 공식 GitLab 컴포넌트 프로젝트를 생성하지 말고 넓은 커뮤니티가 요구를 충족시키도록 해야합니다.

개발 프로세스

  1. gitlab.com/components 하위에 프로젝트를 생성하거나 그룹 소유자 중 한 명에게 빈 프로젝트 생성을 요청합니다.
  2. 컴포넌트 생성을 위한 표준 가이드를 따릅니다.
  3. 컴포넌트 프로젝트가 제공하는 기능을 명확히 설명하는 간결한 프로젝트 설명을 추가합니다.
  4. 일반적인 모범 사례 및 공식 컴포넌트용 것들이 따라지도록 합니다.
  5. MIT 라이선스가 담긴 LICENSE.md 파일을 추가합니다.
  6. 프로젝트에는 다음 사항이 포함되어 있어야 합니다 .gitlab-ci.yml 파일:
    • 프로젝트의 모든 컴포넌트를 올바르게 검증합니다.
    • 새로 게시된 태그를 카탈로그에 발행하는 release 작업을 포함합니다.
  7. 공식 컴포넌트 프로젝트의 경우, 컴포넌트 프로젝트에 공식 아바타 이미지를 업로드합니다.

공식 컴포넌트를위한 최선의 실천

  1. 가능한 한 README.md에 아래의 섹션을 포함하는지 확인합니다 (예: Code quality component 참조):
    • 개요: 컴포넌트 프로젝트에서 제공하는 기능.
    • 컴포넌트: 각 컴포넌트에 대한 하위 섹션으로 각각:
      • 사용법: 입력이 있을 때의 예시들(옵션인 경우).
      • 입력: 입력 이름, 형식, 기본 값(있는 경우) 및 설명이 표시된 테이블.
      • 변수(해당하는 경우): 변수 이름, 가능한 값 및 설명.
    • 기여: 메모와 유지 관리자와 연락 하는 방법. 보통 기여 프로세스는 공식 가이드를 따라야 합니다.
  2. 필요한 경우 컴포넌트의 복합 입력 이름에는 밑줄(_), 필요한 경우 분리기로(-)를 사용합니다. 예: service_x-project_name.

공식 컴포넌트를위한 검토 및 기여 프로세스

프로젝트의 컴포넌트들이 GitLab 코드베이스에 관련된 CI/CD 템플릿를 가질 수도 있습니다. 그런 경우 다음과 같이 해당 컴포넌트 프로젝트와 CI/CD 템플릿을 상호 연결해야 합니다:

  • CI/CD 템플릿의 주소를 사용하여 컴포넌트 프로젝트에 주석을 추가합니다.
  • 컴포넌트 프로젝트의 README.md에 기존 CI/CD 템플릿의 위치가 포함된 섹션을 추가합니다.

이러한 컴포넌트에 변경이 적용되는 경우, 변경 내용을 CI/CD 템플릿에 통합할 수 있는지 확인합니다. CI/CD 템플릿의 버전 관리의 엄격함으로 인해 이를 할 수 없는 경우가 있을 수 있습니다.

유지 관리자 중 한 명을 핑하여 컴포넌트가 일관된 스타일로 작성되었고 최선의 실천을 따르고 있는지 확인하세요.

GitLab 공식 컴포넌트의 기본 유지 관리자

gitlab.com/components 그룹에 있는 각 컴포넌트 프로젝트는 특정 DRIs 및 유지 관리자를 가져야 하지만, 일반적인 유지 관리자 그룹 @gitlab-org/maintainers/ci-components는 일반적으로 components 그룹을 관리합니다.

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

  • 최고의 개발 경험을 제공하기 위해 도구 컴포넌트 및 프로젝트 템플릿과 같은 개발 및 도우미 리소스를 관리합니다.
  • 명확한 DRI가 없는 모든 컴포넌트 프로젝트 또는 장기적인 소유자를 찾는 프로젝트를 관리합니다.
  • 개별 컴포넌트 프로젝트의 유지 관리자들을 가이드하고 멘토링하여 코드 리뷰 및 문제 해결 중에 도와줍니다.
  • 최선의 실천이 적용되고 시간이 지남에 따라 개선되도록합니다.

유지 관리자가되는 요구 사항:

  • CI/CD YAML 구문과 기능에 대한 심층적인 이해.
  • 컴포넌트가 작동하는 방식과 그 개발에 대한 경험을 보여주는 CI 컴포넌트에 대한 이해.
  • 컴포넌트 최선의 실천에 대한 견고한 이해.

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

  • 공식 가이드에 대한 gitlab-components 유지 관리자로의 프로세스를 검토합니다.