InfoGrab DocsInfoGrab Docs

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

요약

GitLab 제품은 서로 통신하면서 독립된 시스템 프로세스로 동작하는 여러 서비스 컴포넌트로 이루어져 있습니다. 다음 개요는 컴포넌트를 통합하는 여러 단계를 설명하기 위해 성숙도 지표의 이름을 예시로 재사용한 것입니다.

GitLab 제품은 서로 통신하면서 독립된 시스템 프로세스로 동작하는 여러 서비스 컴포넌트로 이루어져 있습니다. 이 서비스들은 같은 인스턴스에서 실행할 수도 있고 여러 인스턴스에 나누어 배치할 수도 있습니다. 기존 컴포넌트 목록은 GitLab 아키텍처 개요에서 확인할 수 있습니다.

통합 단계#

다음 개요는 컴포넌트를 통합하는 여러 단계를 설명하기 위해 성숙도 지표의 이름을 예시로 재사용한 것입니다. 이 단계들은 컴포넌트의 실제 성숙도와 느슨하게만 연결되며, 구현 순서를 안내하는 용도입니다. 예를 들어 Lovable 단계가 되기 위해 컴포넌트가 기본 활성화 상태일 필요는 없습니다. 기본 활성화되었다는 사실만으로 컴포넌트가 Lovable 이 되지도 않습니다.

새 컴포넌트 제안#

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

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

GitLab 기능을 제안에서 릴리스까지 진행하는 일반 절차는 제품 개발 흐름에서 확인할 수 있습니다.

새 서비스를 GitLab에 통합#

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

  • 아키텍처 컴포넌트 목록에 해당 서비스가 반영돼 있어야 합니다.
  • 컴포넌트가 제공하는 기능이 GitLab 제품 방향에 수용돼 있어야 합니다.
  • 문서가 마련돼 있고 지원 팀이 새 컴포넌트를 인지하고 있어야 합니다.

GitLab과 완전히 분리해 운영할 수 있는 서비스라면, 첫 번째 반복에서는 외부에 설치된 컴포넌트로 연결해 사용할 수 있는 기능을 추가합니다. 대개 해당 서비스에 연결하거나 그 서비스로부터의 연결을 허용하는 설정을 GitLab에 추가하고, GitLab과 함께 그 서비스를 설치하고 구성하는 방법을 문서로 제공하는 작업이 포함됩니다.

Elasticsearch는 이런 방식으로 통합된 서비스의 예입니다. Gitaly 같은 내부 프로젝트를 포함한 다른 여러 서비스도 별도로 설치하는 선택지로 시작했습니다.

기존 GitLab 코드베이스에 의존하는 서비스라면, 첫 번째 반복은 gitlab.yml 설정이나 기능 플래그를 통한 선택적 활성화 방식이어야 합니다. 이런 유형의 서비스는 초기 통합 과정에서 서비스와 그 의존성을 GitLab에 번들로 포함 해야 하는 경우가 많습니다.

Note

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.4
원문 보기

요약

GitLab 제품은 서로 통신하면서 독립된 시스템 프로세스로 동작하는 여러 서비스 컴포넌트로 이루어져 있습니다. 다음 개요는 컴포넌트를 통합하는 여러 단계를 설명하기 위해 성숙도 지표의 이름을 예시로 재사용한 것입니다.

GitLab 제품은 서로 통신하면서 독립된 시스템 프로세스로 동작하는 여러 서비스 컴포넌트로 이루어져 있습니다. 이 서비스들은 같은 인스턴스에서 실행할 수도 있고 여러 인스턴스에 나누어 배치할 수도 있습니다. 기존 컴포넌트 목록은 GitLab 아키텍처 개요에서 확인할 수 있습니다.

통합 단계#

다음 개요는 컴포넌트를 통합하는 여러 단계를 설명하기 위해 성숙도 지표의 이름을 예시로 재사용한 것입니다. 이 단계들은 컴포넌트의 실제 성숙도와 느슨하게만 연결되며, 구현 순서를 안내하는 용도입니다. 예를 들어 Lovable 단계가 되기 위해 컴포넌트가 기본 활성화 상태일 필요는 없습니다. 기본 활성화되었다는 사실만으로 컴포넌트가 Lovable 이 되지도 않습니다.

새 컴포넌트 제안#

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

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

GitLab 기능을 제안에서 릴리스까지 진행하는 일반 절차는 제품 개발 흐름에서 확인할 수 있습니다.

새 서비스를 GitLab에 통합#

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

  • 아키텍처 컴포넌트 목록에 해당 서비스가 반영돼 있어야 합니다.
  • 컴포넌트가 제공하는 기능이 GitLab 제품 방향에 수용돼 있어야 합니다.
  • 문서가 마련돼 있고 지원 팀이 새 컴포넌트를 인지하고 있어야 합니다.

GitLab과 완전히 분리해 운영할 수 있는 서비스라면, 첫 번째 반복에서는 외부에 설치된 컴포넌트로 연결해 사용할 수 있는 기능을 추가합니다. 대개 해당 서비스에 연결하거나 그 서비스로부터의 연결을 허용하는 설정을 GitLab에 추가하고, GitLab과 함께 그 서비스를 설치하고 구성하는 방법을 문서로 제공하는 작업이 포함됩니다.

Elasticsearch는 이런 방식으로 통합된 서비스의 예입니다. Gitaly 같은 내부 프로젝트를 포함한 다른 여러 서비스도 별도로 설치하는 선택지로 시작했습니다.

기존 GitLab 코드베이스에 의존하는 서비스라면, 첫 번째 반복은 gitlab.yml 설정이나 기능 플래그를 통한 선택적 활성화 방식이어야 합니다. 이런 유형의 서비스는 초기 통합 과정에서 서비스와 그 의존성을 GitLab에 번들로 포함 해야 하는 경우가 많습니다.

Note

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

서비스를 GitLab에 번들로 포함#

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

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

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

개발 환경

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

표준 설치 방식

서비스를 최종 사용자나 GitLab.com에 번들로 제공하려면 표준 설치 방식에 포함해야 합니다.

서비스 의존성 처리#

의존성은 최신 상태로 유지하고 보안 업데이트를 추적해야 합니다. Rails 코드베이스에서는 JavaScript와 Ruby 의존성을 GitLab 의존성 스캐닝으로 검사해 취약점을 찾습니다.

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

릴리스 관리#

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

컴포넌트를 GitLab 월간 릴리스에 포함하는 자동화 수준은 여러 단계가 있습니다. 각 수준에서 컴포넌트를 릴리스에 포함하기 위한 요구 사항과 절차는 릴리스 문서에 정리돼 있습니다.

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

예를 들어 Gitaly와 GitLab Workhorse, GitLab Shell의 목표 버전은 여러 릴리스 파이프라인을 통해 동기화해야 합니다.