InfoGrab DocsInfoGrab Docs

GitLab에 새 서비스 컴포넌트 추가하기

요약

GitLab 제품은 서로 통신하는 독립적인 시스템 프로세스로 실행되는 여러 서비스 컴포넌트로 구성되어 있습니다. 다음 개요는 컴포넌트 통합의 다양한 단계 예시로 성숙도 지표 명칭을 재사용합니다. GitLab QA에서 엔드-투-엔드 테스트

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

통합 단계#

다음 개요는 컴포넌트 통합의 다양한 단계 예시로 성숙도 지표 명칭을 재사용합니다. 이 단계들은 컴포넌트의 실제 성숙도와 느슨하게 연결되어 있으며, 구현 순서를 안내하기 위한 가이드로 활용됩니다. 예를 들어, 컴포넌트가 기본으로 활성화될 필요 없이도 Lovable 단계에 도달할 수 있습니다. 기본으로 활성화된다고 해서 그 자체만으로 컴포넌트가 Lovable 단계가 되는 것은 아닙니다.

  • Proposed

새 컴포넌트 제안하기

  • Minimal

GitLab에 새 서비스 통합하기

GitLab 설치에 번들로 포함하기

레퍼런스 아키텍처에 대해 검증되고 스케일 아웃 권고안이 작성된 상태

  • Lovable

대다수의 사용자에 대해 기본으로 활성화된 상태

새 컴포넌트 제안하기#

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

컴포넌트가 속하는 제품 카테고리를 파악하고, 해당 카테고리를 담당하는 엔지니어링 매니저와 프로덕트 매니저를 지정합니다.

GitLab 기능을 제안부터 릴리즈까지 진행하는 일반적인 단계는 제품 개발 플로에서 확인할 수 있습니다.

GitLab에 새 서비스 통합하기#

새 서비스를 추가하는 것은 다른 기여와 동일한 머지 리퀘스트 워크플로를 따르며, 동일한 완료 기준을 충족해야 합니다. 또한 다음 항목을 포함해야 합니다:

GitLab과 완전히 독립적으로 동작할 수 있는 서비스의 경우:

첫 번째 반복에서는 서비스를 외부에서 설치된 컴포넌트로 연결하고 사용하는 기능을 추가해야 합니다. 이는 보통 GitLab에서 서비스에 연결하거나 서비스로부터의 연결을 허용하는 설정을 제공하는 것을 포함합니다. 그런 다음 서비스를 GitLab과 함께 설치 및 구성하는 방법에 대한 문서를 제공합니다.

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

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

첫 번째 반복은 gitlab.yml 설정 또는 기능 플래그를 통해 선택적으로 활성화(opt-in)되어야 합니다. 이러한 유형의 서비스는 초기 통합의 일환으로 서비스와 해당 의존성을 GitLab과 함께 번들로 포함해야 하는 경우가 많습니다.

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

GitLab에 서비스 번들로 포함하기#

GitLab과 함께 배포되는 코드는 법무팀이 승인한 라이선스를 사용해야 합니다. 기존에 승인된 라이선스 목록을 참고하세요.

컴파일이 필요한 새 의존성을 추가하는 경우, Distribution 팀에 알립니다. 지원되는 모든 플랫폼에서 해당 의존성을 컴파일할 수 있어야 합니다.

GitLab에 번들로 포함될 새 서비스는 다음 환경에서 사용할 수 있어야 합니다.

개발 환경

새 서비스를 번들로 포함하는 첫 단계는 협업과 피드백을 위해 개발 환경에서 제공하는 것입니다.

표준 설치 방법

서비스를 최종 사용자 또는 GitLab.com에 번들로 포함하려면 표준 설치 방법에 포함되어야 합니다:

서비스 의존성 처리하기#

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

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

릴리즈 관리#

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

GitLab 월간 릴리즈에 컴포넌트를 포함하기 위한 다양한 수준의 자동화가 제공됩니다. 각 수준에서 컴포넌트를 릴리즈에 포함하기 위한 요구사항과 프로세스는 릴리즈 문서에 자세히 설명되어 있습니다.

릴리즈 도구로 릴리즈가 관리되는 프로젝트 목록은 릴리즈 도구 프로젝트 디렉터리에서 확인할 수 있습니다.

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

GitLab에 새 서비스 컴포넌트 추가하기

GitLab v19.1
원문 보기
요약

GitLab 제품은 서로 통신하는 독립적인 시스템 프로세스로 실행되는 여러 서비스 컴포넌트로 구성되어 있습니다. 다음 개요는 컴포넌트 통합의 다양한 단계 예시로 성숙도 지표 명칭을 재사용합니다. GitLab QA에서 엔드-투-엔드 테스트

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

통합 단계#

다음 개요는 컴포넌트 통합의 다양한 단계 예시로 성숙도 지표 명칭을 재사용합니다. 이 단계들은 컴포넌트의 실제 성숙도와 느슨하게 연결되어 있으며, 구현 순서를 안내하기 위한 가이드로 활용됩니다. 예를 들어, 컴포넌트가 기본으로 활성화될 필요 없이도 Lovable 단계에 도달할 수 있습니다. 기본으로 활성화된다고 해서 그 자체만으로 컴포넌트가 Lovable 단계가 되는 것은 아닙니다.

  • Proposed

새 컴포넌트 제안하기

  • Minimal

GitLab에 새 서비스 통합하기

GitLab 설치에 번들로 포함하기

레퍼런스 아키텍처에 대해 검증되고 스케일 아웃 권고안이 작성된 상태

  • Lovable

대다수의 사용자에 대해 기본으로 활성화된 상태

새 컴포넌트 제안하기#

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

컴포넌트가 속하는 제품 카테고리를 파악하고, 해당 카테고리를 담당하는 엔지니어링 매니저와 프로덕트 매니저를 지정합니다.

GitLab 기능을 제안부터 릴리즈까지 진행하는 일반적인 단계는 제품 개발 플로에서 확인할 수 있습니다.

GitLab에 새 서비스 통합하기#

새 서비스를 추가하는 것은 다른 기여와 동일한 머지 리퀘스트 워크플로를 따르며, 동일한 완료 기준을 충족해야 합니다. 또한 다음 항목을 포함해야 합니다:

GitLab과 완전히 독립적으로 동작할 수 있는 서비스의 경우:

첫 번째 반복에서는 서비스를 외부에서 설치된 컴포넌트로 연결하고 사용하는 기능을 추가해야 합니다. 이는 보통 GitLab에서 서비스에 연결하거나 서비스로부터의 연결을 허용하는 설정을 제공하는 것을 포함합니다. 그런 다음 서비스를 GitLab과 함께 설치 및 구성하는 방법에 대한 문서를 제공합니다.

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

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

첫 번째 반복은 gitlab.yml 설정 또는 기능 플래그를 통해 선택적으로 활성화(opt-in)되어야 합니다. 이러한 유형의 서비스는 초기 통합의 일환으로 서비스와 해당 의존성을 GitLab과 함께 번들로 포함해야 하는 경우가 많습니다.

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

GitLab에 서비스 번들로 포함하기#

GitLab과 함께 배포되는 코드는 법무팀이 승인한 라이선스를 사용해야 합니다. 기존에 승인된 라이선스 목록을 참고하세요.

컴파일이 필요한 새 의존성을 추가하는 경우, Distribution 팀에 알립니다. 지원되는 모든 플랫폼에서 해당 의존성을 컴파일할 수 있어야 합니다.

GitLab에 번들로 포함될 새 서비스는 다음 환경에서 사용할 수 있어야 합니다.

개발 환경

새 서비스를 번들로 포함하는 첫 단계는 협업과 피드백을 위해 개발 환경에서 제공하는 것입니다.

표준 설치 방법

서비스를 최종 사용자 또는 GitLab.com에 번들로 포함하려면 표준 설치 방법에 포함되어야 합니다:

서비스 의존성 처리하기#

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

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

릴리즈 관리#

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

GitLab 월간 릴리즈에 컴포넌트를 포함하기 위한 다양한 수준의 자동화가 제공됩니다. 각 수준에서 컴포넌트를 릴리즈에 포함하기 위한 요구사항과 프로세스는 릴리즈 문서에 자세히 설명되어 있습니다.

릴리즈 도구로 릴리즈가 관리되는 프로젝트 목록은 릴리즈 도구 프로젝트 디렉터리에서 확인할 수 있습니다.

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