개발 수명주기

시작하기

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

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

개발 수명주기

단계 1: 이슈 준비

어떤 작업을 수행하기 전에 할당된 이슈를 읽고 모든 필요한 부서가 참여되었는지 확인하고 필요한 경우 코멘트를 읽어 명확하지 않은 경우 이슈에 코멘트를 게시하여 작업 내용을 요약하고 담당 엔지니어나 제품 관리자를 핑하여 확인하세요. 그런 다음 모든 것이 명확해지면 올바른 워크플로 레이블을 이슈에 적용하고 Merge Request 브랜치를 생성하세요. 이슈에서 직접 생성한 경우 이슈와 Merge Request은 기본적으로 연결됩니다.

단계 2: 구현 계획

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

어떤 API 데이터가 필요한가요? 저희 API에서 이미 사용 가능한가요, 아니면 백엔드 동료에게 문의해야 하나요?
- 이것이 GraphQL인 경우 쿼리 제안을 작성하고 BE 동료에게 합의를 확인해야 합니다.
GitLab UI 구성요소를 사용할 수 있나요? 적절한 구성요소가 있고 필요한 모든 기능을 갖췄는지 확인하세요.
사용할 수 있는 기존 구성요소나 유틸리티가 있나요?
이 변경 사항은 피처 플래그 뒤에 있어야 하나요 ?
이 코드는 어떤 디렉터리에 위치해야 하나요?
이 기능의 일부를 재사용해야 하나요? 그렇다면 코드베이스에서 어디에 위치해야 하며 어떻게 찾을 수 있게 만들어야 하나요?
- 참고: 지금은 이것이 여전히 고려 중이지만 vue_shared 폴더가 여전히 GitLab 전역 구성요소의 우선적인 디렉터리입니다.
어떤 종류의 테스트가 필요한가요? 유닛 테스트 및 특징 테스트를 고려해야 하며 SET에게 지침을 요청해야 하거나 테스트를 구현하는 데 편안한가요?
이 변경 사항의 규모는 어떻게 되나요? 최대한으로 500+-까지 차이를 유지하려고 노력하세요.

만약 이 모든 질문에 답이 있다면 안전하게 코드 작성에 진행할 수 있습니다.

단계 3: 코드 작성

진행 중인 경우 팀과 소통하거나 계획된 이슈에 긴 시간 동안 작업할 수 없는 경우 도움이 필요한 경우 확실하게 상황을 공유하세요.

도움이 필요하다면 브랜치를 push하고 Merge Request을 직접 팀원에게 또는 #frontend Slack 채널에 공유하여 어떻게 진행해야 하는지에 대한 조언을 구하세요. Merge Request을 임시로 표시(퍼블릭하지 않음)하여 완전한 검토에 준비되지 않았음을 명확히 전달할 수 있습니다. 언제든지 낮은 수준의 부끄러움을 가져 도움이 필요할 때 도움을 요청하세요.

코드를 작성하는 동안 변경 사항을 철저히 테스트하도록 하세요. 작성자의 책임으로 여러분의 코드를 테스트하고 예상대로 작동하고 기존 동작을 손상시키지 않도록 해야 합니다. 리뷰어는 그 측면에서 도와줄 수 있지만 그런 기대를 하지 마세요. 다양한 브라우저, 모바일 뷰포트 및 예상치 못한 사용자 플로우를 확인하세요.

단계 4: 리뷰

코드를 리뷰어에게 보낼 시간이 되면 상당히 스트레스를 받을 수 있습니다. 더 나은 기대를 갖기 위해 코드 리뷰 가이드라인을 읽는 것이 좋습니다. 필수적인 가장 가치 있는 조언 중 하나는 간단히:

… 리뷰어와 불필요한 주고받음을 피하기 위해 … 본인의 Merge Request에 대해 자체 리뷰를 수행하고 코드 리뷰 지침을 따르세요.

이것이 우수한 Merge Request 경험을 갖는 데 중요합니다. 왜냐하면 여러분은 작은 실수를 잡아내고 리뷰어가 확신을 갖지 못할 때 코멘트를 남기고 질문을 할 수 있기 때문입니다. 이는 프로세스를 엄청나게 가속화시킵니다.

단계 5: 확인

코드가 Merge되었을 때 (축하합니다!), 프로덕션 환경에서 작동하고 어떤 오류도 발생시키지 않는지 확인하세요.