GitLab에 새로운 서비스 컴포넌트 추가

GitLab 제품은 서로 통신하는 독립적인 시스템 프로세스로 구성된 여러 서비스 컴포넌트로 이루어져 있습니다. 이러한 서비스는 동일한 인스턴스에서 실행되거나 다른 인스턴스에 분산되어 실행될 수 있습니다. 기존 컴포넌트 디렉터리은 GitLab 아키텍처 개요에서 확인할 수 있습니다.

통합 단계

다음 개요는 컴포넌트 통합의 다양한 단계를 예시로 사용하기 위해 성숙도 메트릭 지표의 명칭을 재사용합니다. 이러한 단계는 컴포넌트의 실제 성숙도와 느슨하게 결합되어 있으며, 구현 순서의 가이드로 사용됩니다. 예를 들어, 컴포넌트가 기본적으로 활성화되지 않더라도 Lovable하게 만드는 데 필요한 요소가 될 수 있습니다.

새로운 컴포넌트 제안

GitLab과 새로운 컴포넌트를 통합하는 초기 단계는 이슈 트래커에서 기능 제안을 작성하는 것으로 시작합니다.

컴포넌트가 속한 제품 범주를 식별하고 해당 범주에 대한 담당 엔지니어링 매니저 및 제품 매니저를 지정합니다.

GitLab의 모든 기능을 제안부터 릴리스까지 가져가는 일반적인 단계에 대한 일반적인 단계는 제품 개발 흐름에서 찾을 수 있습니다.

GitLab과 새로운 서비스 통합

새로운 서비스 추가는 다른 기여들과 마찬가지로 Merge Request 워크플로우를 따르고, 동일한 완료 기준을 충족해야 합니다. 또한 다음을 준수해야 합니다.

  • 아키텍처 컴포넌트 디렉터리이 업데이트되어 해당 서비스가 포함되어 있어야 합니다.
  • 컴포넌트가 GitLab 제품 방향에 수용되었어야 합니다.
  • 문서가 제공되어 있고, 지원팀이 새로운 컴포넌트에 대해 알고 있어야 합니다.

GitLab과 완전히 분리하여 작동할 수 있는 서비스의 경우:

첫 번째 반복 작업은 서비스를 외부에 설치한 컴포넌트로 연결하고 사용할 수 있게 하는 것입니다. 이로 인해 GitLab에서 해당 서비스에 연결하거나 해당 서비스로부터 연결을 허용하는 설정을 제공하는 경우가 많습니다. 그리고 해당 서비스를 GitLab과 구성하는 방법에 대한 문서를 제공하는 것을 포함합니다.

Elasticsearch는 이 방식으로 통합된 서비스의 한 예입니다. Gitaly와 같은 내부 프로젝트를 포함하여 다른 많은 서비스는 처음에는 별도로 설치된 대체품으로 시작했습니다.

기존의 GitLab 코드베이스에 의존하는 서비스의 경우:

첫 번째 반복 작업은 gitlab.yml 구성 또는 피처 플래그를 통해 선택 사항으로 만드는 것입니다. 이러한 유형의 서비스의 경우, 초기 통합의 일환으로 GitLab과 해당 서비스 및 해당 서비스의 의존성을 GitLab과 함께 번들링하는 것이 종종 필요합니다.

note
ActionCable은 이러한 방식으로 추가된 서비스의 한 예입니다.

GitLab과 서비스 번들링

GitLab으로 제공되는 코드는 법률 팀에서 승인한 라이선스를 사용해야 합니다. 기존 승인된 라이선스 디렉터리을 참조하십시오.

컴파일해야 하는 새로운 의존성이 추가될 경우 유포 팀에 통보해야 합니다. 모든 지원되는 플랫폼에서 해당 의존성을 컴파일할 수 있어야 합니다.

GitLab과 번들로 제공할 새로운 서비스는 다음 환경에서 사용할 수 있어야 합니다.

개발 환경

새로운 서비스를 번들로 제공하는 첫 번째 단계는 협력 및 피드백에 참여하기 위해 개발 환경에서 사용할 수 있어야 합니다.

표준 설치 방법

서비스가 최종 사용자나 GitLab.com에게 번들로 제공되기 위해 표준 설치 방법에 포함되어야 합니다.

서비스 의존성 처리

의존성은 보안 업데이트를 추적하고 최신 상태로 유지해야 합니다. Rails 코드베이스의 경우, JavaScript 및 Ruby 의존성은 GitLab 의존성 스캐닝을 사용하여 취약점이 있는지 검사됩니다.

또한 Omnibus 패키지나 Cloud Native 이미지에서 사용되는 시스템 의존성은 의존성 업데이트 자동화에 추가되어야 합니다.

릴리스 관리

서비스 컴포넌트가 월간 GitLab 릴리스와 함께 업데이트되거나 릴리스되어야 하는 경우, 해당 서비스를 릴리스 도구 자동화에 추가해야 합니다. 이 프로젝트는 배달 그룹에서 유지합니다.

다양한 수준의 자동화를 사용하여 GitLab 월간 릴리스에 컴포넌트를 포함하는 요구 사항 및 프로세스에 대한 자세한 내용은 릴리스 문서에 상세히 기술되어 있습니다.

릴리스 도구에 의해 관리되는 프로젝트 디렉터리은 릴리스 도구 프로젝트 디렉터리에서 찾을 수 있습니다.

예를 들어, Gitaly, GitLab Workhorse, GitLab Shell의 원하는 버전은 각각 다른 릴리스 파이프라인을 통해 동기화되어야 합니다.