GitLab 기여를 위한 개발 프로세스 정보는 다음 주제를 참고합니다.

프로세스#

반드시 읽어야 할 문서:

• Cells 아키텍처와 Cells 호환 코드를 작성하는 방법을 이해하기 위한 Cells
• 기존 컴포넌트 조정 및 신규 컴포넌트 도입 가이드
• 코드를 리뷰하고 리뷰받기 위한 코드 리뷰 가이드라인
• 데이터베이스 관련 변경과 복잡한 SQL 쿼리를 리뷰하고 리뷰받기 위한 데이터베이스 리뷰 가이드라인
• 안전한 코딩 가이드라인
• GitLab 프로젝트의 파이프라인
• 필수 중간 정차 버전 피하기

함께 읽으면 좋은 문서:

• GitLab에 기여하기
• 개발자를 위한 보안 프로세스
• 개발자를 위한 패치 릴리스 프로세스
• Enterprise Edition 기능 구현 가이드라인
• GitLab에 새 서비스 컴포넌트 추가
• 변경 로그 가이드라인
• 의존성
• Danger 봇
• GitLab.com의 ChatOps 액세스 요청 (GitLab 팀 구성원용)

개발 가이드라인 리뷰#

개발 가이드라인을 변경할 때는 경험 있는 GitLab 팀 구성원에게 리뷰와 승인을 요청합니다.

예를 들어 특정 그룹만 사용하는 새 내부 API를 문서로 작성한다면, 그 그룹 구성원 중 한 명에게 엔지니어링 리뷰를 요청합니다.

오타 같은 사소한 수정은 Maintainer 이상 권한을 가진 사용자가 머지할 수 있습니다.

광범위한 변경#

한 그룹을 넘어서는 변경도 있습니다. 예를 들면 다음과 같습니다.

• 코드 리뷰 가이드라인 변경.
• 커밋 메시지 가이드라인 변경.
• GitLab 개발의 기능 플래그 가이드라인 변경.
• 기능 플래그 문서 가이드라인 변경.

이런 경우에는 다음 워크플로를 따릅니다.

1. 같은 팀 구성원에게 동료 리뷰를 요청합니다.

2. 해당 영역을 담당하는 Engineering Manager(EM) 또는 Staff Engineer에게 리뷰와 승인을 요청합니다.

   • Frontend
   • Backend
   • Database
   • User Experience (UX)
   • Security
   • Quality
     • Engineering Productivity
   • Infrastructure

   해당 영역을 담당하는 EM 이나 Staff Engineer가 작성한 MR 이라면 이 단계는 건너뛸 수 있습니다.

   영향을 받는 그룹이 여럿이라면 영향받는 영역마다 EM/Staff Engineer 수준의 승인이 필요할 수 있습니다.

3. 리뷰를 마친 뒤 MR의 작성자 또는 승인자인 EM/Staff Engineer와 상의합니다.

   여러 영역에 걸친 중요한 변경이라면 개발 가이드라인의 DRI 인 VP of Development에게 최종 리뷰와 승인을 요청합니다.

MR은 Maintainer 라면 누구나 머지할 수 있습니다.

테크니컬 라이터 리뷰#

테크니컬 라이터의 리뷰를 받고 싶다면 #docs Slack 채널에 메시지를 남깁니다. 다만 테크니컬 라이터가 콘텐츠를 반드시 리뷰해야 하는 것은 아니며, MR 작성자가 아닌 Maintainer 라면 누구나 머지할 수 있습니다.

머지 리퀘스트 승인 설정#

gitlab-org/gitlab 프로젝트는 GitLab 변경 관리 통제의 CHG-04 통제를 충족하기 위해 다음 승인 설정을 적용합니다.

• 머지 리퀘스트 작성자의 승인 방지.
• 커밋을 추가한 사용자의 승인 방지.
• 머지 리퀘스트에서 승인 규칙 편집 방지.
• 소스 브랜치에 커밋이 추가되면 모든 승인 제거.

CODEOWNERS 파일의 코드 소유자를 업데이트하려면 코드 소유자 승인 절차를 따릅니다.

CODEOWNERS#

gitlab-org/gitlab 프로젝트에서는 직무 분리 모범 사례를 따르기 위해 CODEOWNERS 승인 규칙과 MR 승인 설정을 함께 사용합니다. 이 절에서는 gitlab-org/gitlab 프로젝트의 CODEOWNERS 변경에 대해 승인 자격이 있는 승인자를 업데이트하는 절차를 설명합니다.

CODEOWNERS 파일 변경에는 @gitlab-org/development-leaders 그룹의 승인이 필요합니다. 이 그룹은 엔지니어링 내 개발 부서에서 관리 트랙의 Senior Manager 이상, 개인 기여자 트랙의 Distinguished Engineer 이상 팀 구성원으로 구성됩니다.

또한 보안 컴플라이언스 팀 구성원을 멘션해 상황을 공유하기를 권장합니다.

리뷰어 가치#

리뷰어로서든 리뷰를 받는 사람으로서든, GitLab 이 지향하는 리뷰어 가치를 숙지합니다.

또한 모든 문서 콘텐츠는 문서 스타일 가이드를 따라야 합니다.

언어별 가이드#

Go 가이드#

• Go 가이드라인

셸 스크립팅 가이드#

• 셸 스크립팅 표준 및 스타일 가이드라인

명확한 문서 커뮤니케이션#

이슈나 머지 리퀘스트를 비롯한 어떤 방식으로 소통하든, 댓글을 작성할 때 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 같은 용어는 IETF 표준을 따릅니다.

이렇게 하면 문화권이 서로 다른 팀 구성원도 사용되는 용어를 같은 의미로 이해할 수 있습니다.