이 페이지는 프론트엔드 개발 과정을 안내하고 일반적인 머지 리퀘스트 주기가 어떤 모습인지 보여 줍니다. 프론트엔드 팀의 구성은 핸드북에서 확인할 수 있습니다.

첫 머지 리퀘스트에는 고려할 사항이 많아 부담스럽게 느껴질 수 있습니다. 프론트엔드 온보딩 과정은 GitLab 프론트엔드에 기여하는 방법을 배우는 6주 커리큘럼을 제공합니다.

개발 라이프사이클#

1단계: 이슈 준비#

작업을 시작하기 전에 배정받은 이슈를 끝까지 읽고, 필요한 부서가 모두 적절히 참여했는지 확인합니다. 필요하면 댓글도 모두 읽고, 내용이 명확하지 않으면 본인이 이해한 작업 내용을 정리해 이슈에 댓글로 남기고 Engineering Manager 나 Product Manager를 멘션해 확인을 요청합니다. 모든 내용이 명확해지면 이슈에 알맞은 워크플로 레이블을 적용하고 머지 리퀘스트 브랜치를 생성합니다. 이슈에서 바로 생성하면 이슈와 머지 리퀘스트가 기본으로 연결됩니다.

2단계: 구현 계획#

코드를 작성하기 전에 다음 사항을 점검하고 명확한 답을 확보한 뒤 개발을 시작합니다.

• 어떤 API 데이터가 필요한지, 그 데이터가 이미 GitLab API에 있는지 아니면 백엔드 담당자에게 요청해야 하는지 확인합니다.
  • GraphQL 이라면 쿼리 제안을 작성하고 백엔드 담당자에게 동의 여부를 확인받습니다.
• GitLab UI 컴포넌트를 사용할 수 있는지, 어떤 컴포넌트가 적합하며 필요한 기능을 모두 갖추고 있는지 확인합니다.
• GitLab 프로젝트에 이미 사용할 수 있는 컴포넌트나 유틸리티가 있는지 확인합니다.
• 이 변경을 기능 플래그 뒤에 두어야 하는지 확인합니다.
• 이 코드를 어느 디렉터리에 두어야 하는지 확인합니다.
• 이 기능의 일부를 재사용 가능한 형태로 만들어야 하는지, 그렇다면 코드베이스의 어디에 두고 어떻게 찾기 쉽게 만들지 확인합니다.
  • 참고: 이 부분은 아직 논의 중이지만, GitLab 전반에서 쓰이는 컴포넌트는 여전히 vue_shared 폴더에 두는 것이 권장됩니다.
• 어떤 종류의 테스트가 필요한지 확인합니다. 단위 테스트와 기능 테스트를 함께 고려하고, SET에게 안내를 요청할지 아니면 직접 테스트를 구현할지 판단합니다.
• 이 변경의 규모가 어느 정도인지 확인합니다. diff는 최대 500줄 내외로 유지합니다.

이 사항에 모두 답할 수 있다면 코드 작성 단계로 넘어가도 좋습니다.

3단계: 코드 작성#

작업이 진행되는 상황이나 계획된 이슈를 오랫동안 진행하지 못하는 상황은 팀에 반드시 공유합니다.

도움이 필요하면 브랜치를 푸시하고 머지 리퀘스트를 팀원에게 직접 공유하거나 Slack 채널 #frontend에 공유해 다음 단계에 대한 조언을 구합니다. 머지 리퀘스트를 초안으로 표시하면 아직 본격적인 리뷰 준비가 되지 않았다는 점을 분명히 전달할 수 있습니다. 언제나 부끄러움을 낮게 유지하고 필요할 때 도움을 요청합니다.

코드를 작성하면서 변경 사항을 충분히 테스트합니다. 코드를 테스트하고, 의도대로 동작하는지 확인하고, 기존 동작을 깨뜨리지 않았는지 확인하는 일은 작성자의 책임입니다. 리뷰어가 도울 수는 있지만 그것을 기대해서는 안 됩니다. 여러 브라우저, 모바일 뷰포트, 예상하지 못한 사용자 흐름을 반드시 확인합니다.

4단계: 리뷰#

코드를 리뷰에 넘길 때가 되면 상당한 부담을 느낄 수 있습니다. 코드 리뷰 가이드라인을 읽어 두면 무엇을 준비해야 할지 파악하는 데 도움이 됩니다. 그중 가장 값진 조언은 다음과 같습니다.

... 리뷰어와 불필요하게 주고받는 일을 줄이려면 ... 본인의 머지 리퀘스트를 스스로 검토하고 코드 리뷰 가이드라인을 따릅니다.

이 과정은 좋은 머지 리퀘스트 경험의 핵심입니다. 작은 실수를 미리 잡아낼 수 있고, 리뷰어가 의문을 가질 만한 부분에 설명을 남길 수 있기 때문입니다. 이렇게 하면 진행 속도가 크게 빨라집니다.

5단계: 검증#

코드가 머지된 뒤에는 프로덕션 환경에서 정상적으로 동작하고 오류를 일으키지 않는지 반드시 확인합니다.