개발 프로세스

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

프로세스

필독 사항:

  • 기존 컴포넌트의 적응 및 새 컴포넌트 도입 안내
  • 코드 리뷰 지침(code_review.md) 코드를 검토하고 코드를 검토하는 지침
  • 데이터베이스 검토 지침(database_review.md) 데이터베이스 관련 변경 및 복잡한 SQL 쿼리를 검토하고 검토
  • 안전한 코딩 지침(secure_coding_guidelines.md)
  • GitLab 프로젝트용 파이프라인(pipelines/index.md)

보충 자료:

  • 필수 정지 피하기(avoiding_required_stops.md)
  • GitLab에 기여하기(contributing/index.md)
  • 개발자를 위한 보안 프로세스
  • 개발자를 위한 패치 릴리스 프로세스

개발 지침 검토

개발 지침을 변경할 경우, 경험 많은 GitLab 팀 멤버의 검토와 승인을 요청하십시오.

예를 들어, 특정 그룹에서 독점적으로 사용하는 새로운 내부 API를 문서화하는 경우, 해당 그룹 멤버 중 한 명으로부터 엔지니어링 검토를 요청하십시오.

철자 오류와 같은 작은 수정 사항은 유지관리자 역할을 하는 사용자에의해 Merge될 수 있습니다.

광범위한 변경 사항

일부 변경 사항은 여러 그룹에 영향을 미칩니다. 예를 들어:

이러한 경우, 다음 작업흐름을 사용하십시오:

  1. 팀원 중 한 명으로부터 동료 검토를 요청하십시오.

  2. 해당 영역을 담당하는 공학 관리자(EM) 또는 스태프 엔지니어의 검토와 승인을 요청하십시오.

    EM이나 해당 영역을 담당하는 스태프 엔지니어가 작성한 MR인 경우, 이 단계는 건너뛸 수 있습니다.

  3. 검토를 완료한 후, MR의 작성자 또는 승인자로부터 조언을 구하십시오.

    이것이 여러 영역에서의 중요한 변경 사항이라면, 개발 지침의 DRI(Directly Responsible Individual)인 개발 상 부사장으로부터 최종 검토와 승인을 요청하십시오.

유지관리자는 MR을 Merge할 수 있습니다.

기술 작성 검토

기술 작성 검토를 원할 경우, #docs 슬랙 채널에 메시지를 게시하십시오. 기술 작성자는 내용을 검토할 필요는 없고 MR 작성자가 아닌 모든 유지관리자가 Merge할 수 있습니다.

검토자의 가치

검토자 또는 검토 대상자로서 깃랩에서 추구하는 검토자 가치에 익숙해지기 바랍니다.

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

언어별 가이드

Go 가이드

셸 스크립팅 가이드

명확한 서면 의사 소통

이슈나 MR(Merge Request)에 작성한 모든 코멘트를 포함한 어떠한 의사 소통 방식에서도 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, 그리고 “OPTIONAL”과 같은 용어를 사용할 때는 IETF 표준을 따르십시오.

이렇게 함으로써 서로 다른 문화를 가진 팀원들이 사용된 용어에 대해 명확한 이해를 갖을 수 있도록 보장합니다.