개발 프로세스
GitLab에 기여하기 위한 개발 프로세스에 관한 정보는 다음 주제를 참조하십시오.
프로세스
필독 사항:
- 기존 구성 요소를 수정하고 새로운 구성 요소를 도입하는 가이드
- 코드 리뷰 지침(code_review.md): 코드 검토 및 코드 검토
- 데이터베이스 리뷰 지침(database_review.md): 데이터베이스 관련 변경 및 복잡한 SQL 쿼리 검토 및 검토
- 안전한 코딩 지침(secure_coding_guidelines.md)
- GitLab 프로젝트를 위한 파이프라인(pipelines/index.md)
보충 자료:
- 필수 중지 사항 피하기(avoiding_required_stops.md)
- GitLab에 기여하기(contributing/index.md)
- 개발자를 위한 보안 프로세스
- 개발자를 위한 패치 릴리스 프로세스
- Enterprise Edition 기능 구현 가이드라인(ee_features.md)
- GitLab에 새로운 서비스 구성 요소 추가하기(adding_service_component.md)
- 변경 로그 작성 지침(changelog.md)
- 의존성(dependencies.md)
- Danger bot(dangerbot.md)
- GitLab.com의 ChatOps 액세스 요청(chatops_on_gitlabcom.md#requesting-access) (GitLab 팀 구성원용)
개발 지침 검토
개발 지침을 변경하려면, 경험이 풍부한 GitLab 팀 멤버로부터 검토 및 승인을 요청하십시오.
예를 들어, 특정 그룹에서 전용으로 사용되는 새로운 내부 API를 문서화하는 경우, 해당 그룹의 구성원 중 한 명으로부터 엔지니어링 리뷰를 요청하십시오.
철자와 같은 작은 수정 사항은 최소한 Maintainer 역할을 하는 사용자에 의해 병합될 수 있습니다.
보다 광범위한 변경 사항
일부 변경 사항은 한 그룹 이상에 영향을 미칩니다. 예를 들어:
- 코드 리뷰 지침(code_review.md) 변경
- 병합 요청(MR) 워크플로우에서 커밋 메시지 지침 변경
- GitLab 개발의 기능 플래그에 대한 지침(feature_flags/index.md) 변경
- 기능 플래그 문서 작성 지침(documentation/feature_flags.md) 변경
이러한 경우, 다음 워크플로우를 사용하십시오:
- 팀 구성원 중 한 명으로부터 동료 리뷰를 요청하십시오.
- 해당 영역을 책임지는 엔지니어링 관리자(EM)나 스태프 엔지니어로부터 검토 및 승인을 요청하십시오:
EM 또는 해당 영역을 책임지는 스태프 엔지니어가 작성한 MR의 경우, 이 단계는 생략할 수 있습니다.
여러 영역에 영향을 미치는 경우, 각 영향을 받는 영역마다 EM/Staff Engineer 수준의 승인이 필요할 수 있습니다.
-
검토를 완료한 후, MR의 저자/승인자인 EM/Staff Engineer와 상의하십시오.
이것이 여러 영역에 걸친 중요한 변경 사항인 경우, 개발 지침의 DRI(책임 소유자)인 개발 팀의 부사장으로부터 최종 검토 및 승인을 요청하십시오.
어떤 Maintainer도 MR을 병합할 수 있습니다.
기술 문서 리뷰
기술 작성자에 의한 리뷰를 원한다면, #docs Slack 채널에 메시지를 게시하십시오.
기술 작성자는 내용을 검토할 필요는 없으며, MR의 저자 이외의 모든 Maintainer가 병합할 수 있습니다.
리뷰어 가치관
리뷰어 또는 검토 대상자로서, GitLab이 추구하는 리뷰어 가치관에 익숙해지도록 하십시오.
또한, 모든 문서 컨텐츠는 문서 스타일 가이드에 따라야 합니다.
언어별 가이드
Go 가이드
셸 스크립팅 가이드
명료한 문서 작성
이슈, 병합 요청 또는 다른 의사 소통 수단에 코멘트를 작성할 때는 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,”RECOMMENDED”, “MAY”, “OPTIONAL”와 같은 용어를 사용할 때 IETF 표준을 준수하십시오.
이는 서로 다른 문화를 가진 팀 구성원들이 사용된 용어에 대해 명확하게 이해할 수 있도록 보장합니다.
도움말