개발 수명주기

시작하기

이 페이지에서는 Frontend 개발 프로세스를 안내하고 일반적인 병합 요청 주기가 어떻게 보이는지 보여줄 것입니다. 핸드북에서 Frontend 팀의 조직에 대해 자세히 알아볼 수 있습니다.

첫 번째 병합 요청에 대해 고려해야 할 사항이 많고 압도될 수 있습니다. Frontend 입문 과정은 GitLab Frontend에 기여하는 방법을 배우기 위한 6주 구조화된 커리큘럼을 제공합니다.

개발 수명주기

단계 1: 이슈 준비

어떤 작업을 시작하기 전에 할당된 이슈를 읽고 모든 필수 부서가 올바르게 참여되었는지 확인하십시오. 필요한 경우 댓글을 읽고, 이해하기 힘든 경우 작업 내용에 대한 요약을 이슈에 댓글로 작성하고 담당하는 공학자 또는 제품 관리자에게 확인을 요청합니다. 그런 다음 모든 것이 명확해지면 이슈에 올바른 워크플로 레이블을 적용하고 병합 요청 브랜치를 생성하세요. 이슈에서 직접 작성하면 이슈와 병합 요청은 기본적으로 연결됩니다.

단계 2: 구현 계획

코드를 작성하기 전에 다음 질문에 대해 스스로 물어보고 개발을 시작하기 전에 명확한 답변을 가지고 있어야 합니다:

어떤 API 데이터가 필요한가요? 이미 API에 있는 데이터인가요, 아니면 Backend 동료에게 요청해야 하나요?
- 만약 GraphQL을 사용한다면 쿼리 제안을 작성하고 BE 동료가 합의했는지 확인합니다.
GitLab UI 구성요소를 사용할 수 있나요? 적절한 구성요소가 무엇이며 필요한 기능을 모두 갖췄는지 확인하십니까?
GitLab 프로젝트에 기존 구성요소 또는 유틸리티가 있나요?
이 변경 내용은 기능 플래그 뒤에 저장되어야 할까요?
이 코드는 어느 디렉토리에 있어야 하나요?
이 기능의 일부를 재사용 가능하게 구축해야 할까요? 그렇다면 코드베이스에서 어디에 있어야 하며 어떻게 찾을 수 있나요?
- 참고: 현재는 이것이 고려 중이지만, vue_shared 폴더가 여전히 GitLab 전역 구성요소의 기본 디렉토리입니다.
이 변경 내용에는 어떤 종류의 테스트가 필요할까요? 단위 테스트 및 기능 테스트를 고려해야 하나요? SET에게 지침을 구해야 할까요, 아니면 테스트를 구현하는 데 편안한가요?
이 변경 내용의 규모는 어떻게 될까요? 최대한 500+-로 유지하십시오.

이 모든 질문에 대답이 있다면 안전하게 코드 작성에 들어갈 수 있습니다.

단계 3: 코드 작성

진행 중이거나 계획된 이슈에 대해 오랜 기간 작업할 수 없는 경우 팀과 원활하게 소통하는 것을 잊지 마십시오.

지원이 필요한 경우 브랜치를 푸시하고 병합 요청을 직접 팀원에게 공유하거나 #frontend 슬랙 채널에 게시하여 진행 방법에 대한 조언을 구하세요. 병합 요청을 초안으로 표시하여 완전한 검토를 준비하지 않았음을 명확히 전달할 수 있습니다. 언제라도 자존심을 낮추고 도움을 요청하는 것을 잊지 마십시오.

코드를 작성하는 동안 변경 사항을 철저히 테스트하십시오. 작성자는 코드를 테스트하고 예상대로 작동하고 기존 동작을 손상시키지 않도록 보장하는 책임이 있습니다. 리뷰어는 해당 부분에서 도움을 줄 수 있지만, 기대하지 마십시오. 여러 브라우저, 모바일 뷰포트 및 예상치 못한 사용자 흐름을 확인해야 합니다.

단계 4: 리뷰

코드를 검토하러 가야 할 때, 상당히 스트레스일 수 있습니다. 더 나은 경험을 위해 코드 리뷰 지침을 읽어보는 것이 좋습니다. 필수적으로 할 가치 있는 가장 중요한 조언 중 하나는 간단합니다:

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

이는 작은 실수를 잡아내고 리뷰어가 불확실하고 질문이 있을 수 있는 영역에 의견을 남기기 때문에 뛰어난 병합 요청 경험을 갖는 데 중요합니다. 이렇게 하면 프로세스가 크게 가속화됩니다.

단계 5: 확인

코드가 병합되면 (축하합니다!), 프로덕션 환경에서 작동하고 오류를 유발하지 않는지 확인하십시오.