시작하기

이 페이지는 프론트엔드 개발 프로세스를 안내하고 정상적인 병합 요청 주기가 어떻게 생겼는지 보여줍니다. 프론트엔드 팀의 조직에 대한 자세한 내용은 핸드북에서 확인할 수 있습니다.

첫 번째 병합 요청을 위해 고려해야 할 사항이 많으며, 압도적으로 느껴질 수 있습니다. 프론트엔드 온보딩 과정은 GitLab 프론트엔드에 기여하는 방법을 배우기 위한 6주간의 구조화된 커리큘럼을 제공합니다.

개발 생명 주기

1단계: 이슈 준비

작업을 시작하기 전에, 귀하에게 할당된 이슈를 읽고 모든 필수 부서가 적절히 참여했는지 확인하세요. 필요에 따라 댓글을 읽고 불분명한 점이 있으면 이슈에 작업이 무엇이라고 생각하는지 요약하여 댓글을 달고 귀하의 엔지니어링 또는 제품 관리자에게 확인하도록 알리세요. 모든 것이 명확해지면, 이슈에 적절한 워크플로우 레이블을 적용하고 병합 요청 브랜치를 생성하세요. 이슈에서 직접 생성하면, 이슈와 병합 요청은 기본적으로 연결됩니다.

2단계: 구현 계획

코드를 작성하기 전에, 다음 질문을 스스로에게 하고 명확한 답변을 얻으세요:

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

이 모든 질문에 답이 있다면, 코드를 작성하는 것으로 안전하게 진행할 수 있습니다.

3단계: 코드 작성

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

도움이 필요하면, 브랜치를 푸시하고 병합 요청을 동료에게 직접 공유하거나 Slack 채널 #frontend에서 어떻게 진행할지 조언을 받으세요. 병합 요청을 초안으로 표시할 수 있으며, 이는 완전한 검토를 위한 준비가 안 되었음을 명확하게 전달합니다. 항상 낮은 수치심을 기억하고 필요할 때 도움을 요청하세요.

코드를 작성하는 동안, 변경 사항을 철저히 테스트하는 것을 잊지 마세요. 코드를 테스트하고 예상대로 작동하는지, 기존 동작을 깨뜨리지 않았는지 확인하는 것은 작성자의 책임입니다. 리뷰어는 그에 대해 도와줄 수 있지만, 그러한 기대는 하지 마세요. 다양한 브라우저, 모바일 뷰포트 및 예상치 못한 사용자 흐름을 확인해야 합니다.

4단계: 검토

코드를 검토하기 위해 전송할 시간에, 상당히 스트레스를 받을 수 있습니다. 무엇을 기대할지에 대한 더 나은 감각을 얻기 위해 코드 리뷰 가이드라인을 읽어보는 것이 좋습니다. 가장 가치 있는 조언 중 하나는 필수적인 것은 단순히:

… 리뷰어와 불필요한 왕복을 피하기 위해, … 자신의 Merge Request에 대해 자가 검토를 수행하고, 코드 리뷰 가이드라인을 따르십시오.

이는 훌륭한 Merge Request 경험을 위한 핵심입니다. 작은 실수를 발견하고 리뷰어가 불확실하고 질문이 있을 수 있는 영역에 댓글을 남길 수 있습니다. 이는 프로세스를 엄청나게 빠르게 합니다.

5단계: 검증

코드가 병합된 후(축하합니다!), 프로덕션 환경에서 제대로 작동하는지 및 오류를 발생시키지 않는지 확인하십시오.

On this page