개발 라이프사이클

시작하기

이 페이지에서는 프론트엔드 개발 프로세스를 안내하고 일반적인 병합 요청 주기가 어떤지 보여드립니다. 프론트엔드 팀의 조직에 대해 더 알고 싶다면 핸드북을 참조하세요.

첫 번째 병합 요청에 대해 고려해야 할 사항이 많을 수 있으며 압도당할 수 있습니다. 프론트엔드 온보딩 코스는 GitLab 프론트엔드에 기여하는 방법을 배우기 위한 6주 구조화된 커리큘럼을 제공합니다.

개발 라이프사이클

단계 1: 이슈 준비

어떠한 작업도 시작하기 전에 당신에게 할당된 이슈를 읽고 모든 필수 부서가 참여되었는지 확인해야 합니다. 필요한 경우 댓글을 읽고 이해되지 않는 부분이 있다면 이슈에 댓글을 남기고 당신이 작업 내용이라고 생각하는 것을 요약한 후 엔지니어링 또는 제품 매니저에게 확인하세요. 그런 다음 모든 것이 명확해지면 이슈에 올바른 워크플로 레이블을 지정하고 병합 요청 브랜치를 생성하세요. 이슈에서 직접 생성된 경우 이슈와 병합 요청은 기본적으로 연결됩니다.

단계 2: 구현 계획 수립

코드를 작성하기 전에 개발을 시작하기 전에 아래의 질문에 대한 명확한 대답을 갖고 시작하기 전에 자문해보세요.

어떤 API 데이터가 필요한가요? 이미 우리 API에 있는지 확인해야 하며, 아니라면 백엔드 담당자에게 문의해야 합니다.
- 만약 GraphQL이라면 쿼리 제안을 작성하고 BE 동료에게 합의 여부를 확인하세요.
GitLab UI 구성 요소를 사용할 수 있을까요? 어떤 구성 요소가 적당하며 필요한 기능을 모두 갖췄는지 확인할 수 있을까요?
GitLab 프로젝트에 기존 구성 요소나 유틸리티가 있는지 확인할 수 있을까요?
이 변경은 기능 플래그를 통해 라이브로 유지되어야 하는가요?
이 코드는 어느 디렉토리에 위치해야 하나요?
이 기능의 일부를 재사용할 수 있을까요? 그렇다면 코드베이스에서 어디에 위치해야 하며 어떻게 발견할 수 있을까요?
- 참고: 현재까지는 이것이 고려 중이지만 vue_shared 폴더가 여전히 GitLab 전체 구성 요소의 기본 디렉터리입니다.
어떤 종류의 테스트가 필요할까요? 단위 테스트 및 기능 테스트를 고려해야 할까요? SET에게 안내를 요청해야 할까요, 아니면 테스트를 구현하는 데 편안할까요?
이 변경은 얼마나 큰가요? 차이를 최대 500+- 보이지 않도록 유지해보세요.

위의 질문에 대한 답변이 있다면 안전하게 코드 작성으로 넘어갈 수 있습니다.

단계 3: 코드 작성

작업을 진행하거나 계획된 이슈에 오랜 기간 동안 작업할 수 없는 경우 반드시 팀과 소통하세요.

도움이 필요한 경우 반드시 브랜치를 푸시하고 병합 요청을 직접 팀원에게 공유하거나 #frontend 슬랙 채널에 공유하여 어떻게 진행해야 하는 지 조언을 얻으세요. 본인의 병합 요청을 드래프트로 표시하여 완전한 검토 준비가 되지 않았음을 분명히 전달할 수 있습니다. 언제나 낮은 수준의 창피함을 가지고 도움이 필요할 때 도움을 요청하세요.

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

단계 4: 검토

코드를 검토할 시간이 되면 상당히 긴장될 수 있습니다. 더 나은 기대를 갖기 위해 코드 검토 지침을 읽는 것이 권장됩니다. 필수적인 가장 유용한 조언 중 하나는 간단히:

… 리뷰어와의 불필요한 반복을 피하려면… 자신의 병합 요청에 대해 스스로 검토하고 코드 검토 지침을 따르세요.

이것은 작은 실수를 잡아내고 리뷰어가 확신하지 못할 부분에 의문을 남겨두는 것으로 인해 병합 요청하는 프로세스를 크게 가속화합니다.

단계 5: 검증

코드가 병합된 후 (축하합니다!), 프로덕션 환경에서 작동하고 어떠한 오류도 발생시키지 않는지 확인하세요.