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

GitLab이 공식적으로 유지 관리하는 CI/CD 컴포넌트를 개발하는 방법과 모범 사례, 소유권 정의, 버전 관리, 검토 및 기여 프로세스를 설명합니다.

이 문서는 GitLab이 유지 관리하는 CI/CD 컴포넌트 를 개발하는 방법을 설명합니다. 여기에는 공식 공개 컴포넌트와 내부 사용 컴포넌트가 모두 포함됩니다. 모든 공식 GitLab 컴포넌트 프로젝트의 위치는 gitlab.com/components 그룹입니다. 이 그룹에는 범용적으로 설계되어 모든 GitLab 사용자에게 제공되며 GitLab이 유지 관리하는 모든 컴포넌트가 포함됩니다. 예를 들어 SAST, 시크릿 탐지, 코드 품질 컴포넌트 등이 있습니다. 컴포넌트 프로젝트는 처음에는 다른 그룹(예: gitlab-org )에서 생성될 수 있지만, 첫 번째 버전이 카탈로그에 게시되기 전에 components 그룹으로 이동해야 합니다. gitlab.com/components 그룹 하위의 모든 프로젝트는 공개(public)여야 합니다. GitLab 내부 전용 컴포넌트, 예를 들어 gitlab-org/gitlab 프로젝트에 특화된 컴포넌트는 gitlab-org 그룹 하위에 구현해야 합니다. CI/CD 카탈로그 에 게시될 예정인 컴포넌트 프로젝트는 프로젝트 품질을 유지하고 직접적인 사용 경험을 갖추기 위해 먼저 내부적으로 사용(dogfood)해야 합니다. 소유권 정의 # 공식 GitLab 컴포넌트는 커뮤니티의 신뢰를 받으므로 높은 수준의 품질과 시기적절한 유지 관리가 필요합니다. 컴포넌트는 최신 상태로 유지되고, 보안 취약점을 모니터링하며, 버그를 수정해야 합니다. 각 컴포넌트 프로젝트에는 도메인 전문가이기도 한 Owner 및 유지 관리자 집합이 있어야 합니다. 전문가는 GitLab의 어느 부서에서든 올 수 있으며, Engineering부터 Support, Customer Success, Developer Relations까지 다양합니다. 컴포넌트가 GitLab 기능(예: 시크릿 탐지)과 관련된 경우, 해당 기능 카테고리를 소유하거나 가장 밀접하게 관련된 팀이 프로젝트를 유지 관리해야 합니다. 이 경우 기능 카테고리의 Engineering Manager가 프로젝트 Owner로 지정됩니다. 프로젝트에서 owner 권한을 가진 멤버는 오픈된 이슈와 머지 리퀘스트를 트리아지하여 신속하게 처리되도록 보장하는 DRI입니다. 컴포넌트 프로젝트는 처음에 별도의 팀이나 개인이 생성할 수 있지만, 첫 번째 버전이 카탈로그에 게시되기 전에 Owner 집합으로 전환되어야 합니다. 프로젝트 리포지터리의 README.md 파일에는 필요 시 더 넓은 커뮤니티가 연락할 수 있도록 프로젝트의 주요 Owner가 명시되어야 합니다. 프로젝트 Owner 집합을 보장할 수 없거나 컴포넌트를 내부적으로 사용할 수 없는 경우, 공식 GitLab 컴포넌트 프로젝트를 생성하지 말고 더 넓은 커뮤니티가 카탈로그에서 수요를 충족시키도록 두는 것을 강력히 권장합니다. 개발 프로세스 # gitlab.com/components 하위에 프로젝트를 생성하거나 그룹 Owner 중 한 명에게 빈 프로젝트를 생성해 달라고 요청하세요. 컴포넌트 생성 표준 가이드 를 따르세요. 컴포넌트 프로젝트가 제공하는 기