이 페이지는 프론트엔드 개발 프로세스를 안내하고, 일반적인 머지 리퀘스트 사이클이 어떻게 진행되는지 보여줍니다. 프론트엔드 팀의 조직에 대한 자세한 내용은 핸드북을 참고하세요.

첫 번째 머지 리퀘스트에서 고려해야 할 사항이 많아 부담스럽게 느껴질 수 있습니다. 프론트엔드 온보딩 코스는 GitLab 프론트엔드에 기여하는 방법을 배우기 위한 6주 구조화 커리큘럼을 제공합니다.

개발 라이프사이클#

Step 1: 이슈 준비#

작업을 시작하기 전에, 담당하게 된 이슈를 꼼꼼히 읽고 필요한 부서가 모두 적절히 참여했는지 확인하세요. 필요에 따라 댓글을 읽고, 내용이 불명확하다면 이슈에 댓글을 달아 작업 내용이 무엇인지 요약한 뒤 담당 엔지니어링 또는 Product Manager에게 핑을 보내 확인하세요. 모든 내용이 명확해지면, 이슈에 올바른 워크플로 라벨을 적용하고 머지 리퀘스트 브랜치를 생성하세요. 이슈에서 직접 생성한 경우, 이슈와 머지 리퀘스트는 기본적으로 연결됩니다.

Step 2: 구현 계획 수립#

코드를 작성하기 전에, 다음 질문들을 스스로에게 던지고 개발을 시작하기 전에 명확한 답변을 갖추세요:

• 어떤 API 데이터가 필요한가요? 이미 API에서 사용 가능한가요, 아니면 백엔드 담당자에게 요청해야 하나요?

GraphQL이라면 쿼리 제안서를 작성하고 백엔드 담당자에게 동의 여부를 확인하세요.

• GitLab UI 컴포넌트를 사용할 수 있나요? 어떤 컴포넌트가 적합하며, 필요한 기능을 모두 갖추고 있나요?

• GitLab 프로젝트에 활용할 수 있는 기존 컴포넌트나 유틸리티가 있나요?

• 이 변경 사항은 피처 플래그 뒤에 위치해야 하나요?

• 이 코드는 어느 디렉터리에 위치해야 하나요?

• 이 기능의 일부를 재사용 가능하게 만들어야 하나요? 그렇다면 코드베이스 어디에 위치해야 하며, 어떻게 찾기 쉽게 만들 수 있나요?

참고: 현재까지도 논의 중이지만, vue_shared 폴더는 GitLab 전체 컴포넌트를 위한 권장 디렉터리입니다.

• 어떤 종류의 테스트가 필요한가요? 단위 테스트와 기능 테스트를 모두 고려하세요. SET에게 가이드를 요청해야 하나요, 아니면 직접 테스트를 구현할 수 있나요?

• 이 변경 사항은 얼마나 커질까요? diff를 최대 500줄 내외로 유지하려고 노력하세요.

이 모든 질문에 답변이 준비됐다면, 코드 작성으로 넘어갈 수 있습니다.

Step 3: 코드 작성#

진행하면서 또는 예정된 이슈를 오랫동안 처리할 수 없을 때는 팀원과 소통하세요.

도움이 필요하다면 브랜치를 푸시하고 머지 리퀘스트를 팀원에게 직접 공유하거나 Slack 채널 #frontend에 공유하여 진행 방법에 대한 조언을 구하세요. 머지 리퀘스트를 드래프트로 표시하면 아직 전체 리뷰 준비가 되지 않았음을 명확히 전달할 수 있습니다. 항상 낮은 수준의 부끄러움을 갖고 필요할 때 도움을 요청하는 것을 기억하세요.

코드를 작성하면서 변경 사항을 철저히 테스트하세요. 코드를 테스트하고, 예상대로 작동하는지 확인하며, 기존 동작을 망가뜨리지 않았는지 확인하는 것은 작성자의 책임입니다. 리뷰어가 이 부분을 도와줄 수도 있지만, 기대하지 마세요. 다양한 브라우저, 모바일 뷰포트, 예상치 못한 사용자 흐름을 반드시 확인하세요.

Step 4: 리뷰#

코드 리뷰를 위해 제출할 때가 되면 꽤 부담스러울 수 있습니다. 코드 리뷰 가이드라인을 읽어 무엇을 기대해야 하는지 파악하는 것을 권장합니다. 가장 가치 있는 조언 중 필수적인 것은 다음과 같습니다:

… 리뷰어와의 불필요한 왕복을 피하기 위해, … 직접 머지 리퀘스트를 셀프 리뷰하고, 코드 리뷰 가이드라인을 따르세요.

이것은 훌륭한 머지 리퀘스트 경험을 위한 핵심입니다. 작은 실수를 잡아내고, 리뷰어가 불확실하거나 질문할 수 있는 부분에 댓글을 남길 수 있기 때문입니다. 이는 프로세스를 대폭 빠르게 합니다.

Step 5: 검증#

코드가 머지된 후 (축하합니다!), 프로덕션 환경에서 정상적으로 동작하는지, 오류가 발생하지 않는지 반드시 확인하세요.