개발 프로세스
GitLab에 기여하기 위한 개발 프로세스에 대한 정보는 다음 주제를 참조하세요.
프로세스
필독 항목:
- 기존 구성요소의 적응 및 새로운 구성요소의 도입에 대한 가이드
- 코드 리뷰 지침 코드를 검토하고 코드를 검토하는 방법에 대한 Code Review Guidelines
- 데이터베이스 관련 변경 사항 및 복잡한 SQL 쿼리를 검토하고 검토하는 데이터베이스 리뷰 지침
- 보안 코딩 가이드
- GitLab 프로젝트용 파이프라인
보충 독서:
- 필수 중지 사항 회피하기
- GitLab에 기여하기
- 개발자를 위한 보안 프로세스
- 개발자를 위한 패치 릴리스 프로세스
- Enterprise Edition 기능 구현 가이드라인
- GitLab에 새로운 서비스 컴포넌트를 추가하는 방법에 대한 가이드라인
- 변경 로그 작성 지침
- 의존성
- 위험 봇
- GitLab.com의 ChatOps 액세스 요청 (GitLab 팀 구성원용)
개발 가이드라인 검토
개발 가이드라인에 대한 변경 사항의 경우, 경험 많은 GitLab 팀원으로부터 검토 및 승인을 요청하세요.
예를 들어, 특정 그룹에서 전용으로 사용되는 새로운 내부 API를 문서화하는 경우, 그 그룹의 구성원 중 한 명으로부터 엔지니어링 검토를 요청하세요.
철자 오류와 같은 작은 수정 사항은 최소한 Maintainer 역할을 하는 사용자가 Merge할 수 있습니다.
보다 광범위한 변경 사항
일부 변경 사항은 하나 이상의 그룹에 영향을 미칩니다. 예를 들어:
- 코드 리뷰 지침에 대한 변경
- 커밋 메시지 지침의 변경
- GitLab 개발에서의 피처 플래그에 대한 가이드라인의 변경
- 피처 플래그 문서 지침의 변경
이러한 경우, 다음 워크플로를 사용하세요:
- 팀원 중 한 명으로부터 동료 검토를 요청하세요.
-
해당 영역을 담당하는 엔지니어링 매니저(EM) 또는 스태프 엔지니어의 검토와 승인을 요청하세요:
EM이나 담당 영역의 스태프 엔지니어가 작성한 MR의 경우, 이 단계는 생략할 수 있습니다.
여러 영향을 받는 그룹이 있는 경우, 각 영향을 받는 영역의 EM/스태프 엔지니어 수준에서 승인이 필요할 수 있습니다.
-
검토를 완료한 후, MR의 작성자/승인자인 EM/스태프 엔지니어와 상의하세요.
본질적인 변경 사항인 경우 해당 영역을 담당하는 개발 상 부사장인 VP of Development로부터 최종 검토와 승인을 요청하세요.
Maintainer는 MR을 Merge할 수 있습니다.
기술 문서 검토
기술 작성자에 의한 검토를 원하는 경우, #docs Slack 채널에 메시지를 게시하세요.
기술 작성자는 내용을 검토할 필요는 없으며, MR 작성자 이외의 Maintainer는 Merge할 수 있습니다.
리뷰어 가치
- 도입됨 in GitLab 14.1.
리뷰어 또는 리뷰 대상자로서 귀하는 반드시 GitLab에서 지향하는 리뷰어 가치에 익숙해질 것을 권장합니다.
또한, 모든 문서 내용은 문서 작성 스타일 가이드를 따라야 합니다.
언어별 가이드
Go 가이드
셸 스크립팅 가이드
명확한 서면 의사 소통
이슈나 Merge Request의 댓글 또는 기타 의사 소통 방식에 글을 작성할 때는 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”과 같은 용어를 사용할 때 IETF 표준을 준수하세요.
이는 서로 다른 문화를 가진 팀원들도 사용된 용어에 대해 명확히 이해할 수 있도록 보장합니다.
도움말