GitLab 공식 CI/CD 컴포넌트 개발 안내서

이 문서는 GitLab에서 유지보수하는 CI/CD 컴포넌트 (공식 공개용 또는 내부 사용용)를 개발하는 방법에 대해 설명합니다.

모든 공식 GitLab 컴포넌트 프로젝트의 위치는 gitlab.com/components 그룹입니다. 이 그룹에는 모든 GitLab 사용자에 제공되며 GitLab에서 유지보수하는 일반적인 컴포넌트가 포함되어 있습니다. 예를 들어, SAST, 비밀 탐지 및 코드 품질 컴포넌트 등이 있습니다. 컴포넌트 프로젝트는 처음에는 다른 그룹(예: gitlab-org)에 작성될 수 있지만, 카탈로그에 최초로 게시되기 전에 components 그룹으로 이동해야 합니다.

GitLab 내부 사용용으로만 사용되는 컴포넌트는, 예를 들어, gitlab-org/gitlab 프로젝트에 특정한 경우에는 gitlab-org 그룹에 구현되어야 합니다.

CI/CD 카탈로그에 공개되기로 예상되는 컴포넌트 프로젝트는 우선 자체적으로 사용하여 프로젝트 품질을 유지하고 실제 경험을 보장하기 위해 dogfooded 되어야 합니다.

소유권 정의

공식 GitLab 컴포넌트들은 커뮤니티에 신뢰를 받으며 높은 품질과 적시에 유지보수가 필요합니다. 컴포넌트는 최신 상태로 유지되어야 하며, 보안 취약점이 모니터링되고 버그가 수정되어야 합니다.

각 컴포넌트 프로젝트는 도메인 전문가인 소유자와 유지보수자로 이루어져 있어야 합니다. 전문가는 엔지니어링부터 지원, 고객 성공, 개발자 관계에 이르기까지 GitLab의 모든 부서에서 나올 수 있습니다.

컴포넌트가 GitLab 기능에 관련되어 있다면 (예: 비밀 탐지), 해당 기능 범주를 소유하거나 가장 관련이 깊은 팀이 프로젝트를 유지보수해야 합니다. 이 경우 해당 기능 범주의 엔지니어링 매니저가 프로젝트 소유자로 지정됩니다.

프로젝트의 소유권 역할을 하는 구성원들은 문제 및 Merge Request을 신속하게 해결하기 위해 지정된 책임자(DRIs)입니다.

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

프로젝트 리포지터리의 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에 적어도 아래 섹션들이 포함되도록 보장하세요 (예: 코드 품질 컴포넌트 참조):
    • 개요: 컴포넌트 프로젝트가 제공하는 기능.
    • 컴포넌트: 각 컴포넌트를 위한 여러 하위 섹션으로 다음이 포함되어 있습니다:
      • 사용: 입력이 있는 경우 및 없는 경우의 예제(옵션인 경우).
      • 입력: 입력 이름, 유형, 기본 값(있는 경우) 및 설명을 보여주는 테이블.
      • 변수(적용되는 경우): 변수 이름, 가능한 값, 설명.
    • 기여: 유지보수자와 연락하는 방법에 대한 안내. 일반적으로 기여 프로세스는 공식 가이드를 따라야 합니다.
  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(Directly Responsible Individuals) 및 유지보수자가 있어야 하지만, 유지보수자 그룹 @gitlab-org/maintainers/ci-components는 일반적으로 components 그룹을 관리하는 역할을 수행합니다.

이 유지보수자 그룹의 책임:

  • 최상의 개발 경험을 제공하기 위해 툴킷 컴포넌트 및 프로젝트 템플릿과 같은 개발 및 보조 리소스를 관리합니다.
  • 명확한 DRI가 없거나 장기적으로 적절한 소유자를 찾는 프로세스에 있는 컴포넌트 프로젝트를 관리합니다.
  • 개별 컴포넌트 프로젝트의 유지보수자를 가이드하고 조언하며 코드 리뷰 및 문제 해결 중에 그들과 함께 일합니다.
  • 최선의 실천법이 적용되고 시간이 지남에 따라 개선되도록 보장합니다.

유지보수자가 되기 위한 요구 사항:

  • CI/CD YAML 구문 및 기능에 대한 심층적인 이해를 가져야 합니다.
  • CI 컴포넌트가 어떻게 작동하는지 이해하고 그를 개발해 본 경험이 있어야 합니다.
  • 컴포넌트에 대한 최선의 실첵법에 대해 solide한 이해를 가져야 합니다.

gitlab-components 일반 유지보수자 그룹에 참여하는 방법: