개발 프로세스

GitLab에 기고하기 위한 개발 프로세스에 대한 정보는 다음 주제를 참조하십시오.

프로세스

필독사항:

  • 기존 컴포넌트를 조정하고 새로운 컴포넌트를 도입하는 가이드
  • 코드 리뷰 가이드라인을 통해 코드를 검토하고 코드를 검토 받으세요(code_review.md)
  • 데이터베이스 검토 가이드라인을 통해 데이터베이스 관련 변경 및 복잡한 SQL 쿼리를 검토하고 검토 받으세요(database_review.md)
  • 안전한 코딩 가이드라인(secure_coding_guidelines.md)
  • GitLab 프로젝트의 파이프라인(pipelines/index.md)
  • 필수 중지 사항 회피(avoiding_required_stops.md)

보조 사항:

  • GitLab에 기고하기(contributing/index.md)
  • 개발자를 위한 보안 프로세스(https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md)
  • 개발자를 위한 패치 릴리스 프로세스(https://gitlab.com/gitlab-org/release/docs/-/tree/master/general/patch)
  • Enterprise Edition 기능 구현 가이드라인(ee_features.md)
  • GitLab에 새로운 서비스 구성 요소 추가하기(adding_service_component.md)
  • 변경 로그 가이드라인(changelog.md)
  • 종속성(dependencies.md)
  • 위험 요소 봇(dangerbot.md)
  • GitLab.com의 ChatOps 액세스 요청(chatops_on_gitlabcom.md#requesting-access)(GitLab 팀 구성원용)

개발 가이드라인 검토

개발 가이드라인 변경사항에 대해서는 GitLab 팀의 경험이 있는 구성원으로부터 검토와 승인을 요청하십시오.

예를 들어, 특정 그룹에서 전용으로 사용하는 새로운 내부 API를 문서화하는 경우, 해당 그룹 구성원 중 한 명으로부터 엔지니어링 리뷰를 요청하십시오.

철자 오류와 같이 작은 수정사항의 경우, Maintainer 권한을 가진 모든 사용자가 병합할 수 있습니다.

광범위한 변경 사항

일부 변경 내용은 두 개 이상의 그룹에 영향을 미칩니다. 예를 들어:

  • 코드 리뷰 가이드라인 변경
  • 기여를 위한 커밋 메시지 가이드라인 변경
  • GitLab 개발의 기능 플래그 가이드라인 변경
  • 기능 플래그 문서 작성 가이드라인 변경

이러한 경우 다음 워크플로를 사용하십시오:

  1. 팀 구성원 중 한 명으로부터 피어 리뷰를 요청하십시오.

  2. 해당 영역에 대한 책임이 있는 엔지니어링 매니저(EM) 또는 스태프 엔지니어의 검토와 승인을 요청하십시오:

    EM이나 해당 영역의 책임 있는 스태프 엔지니어가 작성한 MR의 경우이 단계를 건너뛸 수 있습니다.

  3. 검토를 완료한 후, MR의 저자/승인자인 EM/스태프 엔지니어와 상의하십시오.

    여러 영역에 걸친 중요한 변경 사항인 경우, 개발 가이드라인의 DRI(책임 있는 담당자)인 개발 부사장(VP of Development)으로부터 최종 검토와 승인을 요청하십시오.

Maintainer는 MR을 병합할 수 있습니다.

기술 문서 검토

기술 작성자의 검토를 원하는 경우 #docs Slack 채널에 메시지를 게시하십시오. 기술 작성자는 내용을 검토할 필요는 없으며 MR 저자 이외의 모든 Maintainer가 병합할 수 있습니다.

검토자 가치

검토자 또는 검토 대상자로서 GitLab에서 지향하는 검토자 가치에 익숙해지도록 노력하십시오.

또한, 모든 문서 내용은 문서 스타일 가이드를 따르어야 합니다.

언어별 가이드

Go 가이드

셸 스크립팅 가이드

명확한 문서화된 의사 소통

이슈 또는 병합 요청의 댓글 또는 다른 의사 소통 방법을 통해 어떠한 코멘트를 작성할 때, “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,”RECOMMENDED”, “MAY”, 및 “OPTIONAL”과 같은 용어를 사용할 때에는 IETF 표준을 따르십시오.

이는 서로 다른 문화를 가진 팀 구성원이 사용되는 용어를 명확히 이해할 수 있도록 보장합니다.