개발 라이프 사이클

시작하기

이 페이지에서는 프론트엔드 개발 프로세스를 안내하고 일반적인 Merge Request 주기가 어떤지 보여줍니다. 프론트엔드 팀의 조직에 대한 자세한 내용은 핸드북에서 확인할 수 있습니다.

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

개발 라이프 사이클

단계 1: 이슈 준비

작업을 시작하기 전에 할당된 작업 항목을 읽고, 모든 필수 부서가 참여했는지 확인하세요. 필요한 경우 댓글을 읽고, 명확하지 않으면 이슈에 댓글을 게시하여 작업 내용을 요약하고 엔지니어링 또는 제품 매니저를 언급하세요. 그런 다음 모든 것이 명확해지면 문제에 올바른 워크플로 레이블을 적용하고 Merge Request 브랜치를 생성하세요. 이슈에서 직접 생성하면 기본적으로 이슈와 Merge Request이 연결됩니다.

단계 2: 구현 계획

코드를 작성하기 전에 다음 질문에 대답할 수 있도록 확실한 대답을 얻으세요.

어떤 API 데이터가 필요한가요? 이미 API에 있는 것인가요, 아니면 백엔드 동료에게 문의해야 하나요?
- 이것이 GraphQL이라면 쿼리 제안을 작성하고 BE 동료에게 합의되었는지 확인하세요.
GitLab UI 컴포넌트를 사용할 수 있을까요? 적절한 컴포넌트가 무엇이며 필요한 모든 기능을 갖추고 있나요?
GitLab 프로젝트에 기존 컴포넌트나 유틸리티가 있나요?
이 변경을 피처 플래그 뒤로 두어야 하나요?
이 코드는 어느 디렉터리에 있어야 하나요?
이 기능의 일부를 재사용 가능하게 만들어야 하나요? 그렇다면 코드베이스에는 어디에 있어야 하며 검색 가능하도록 어떻게 만드나요?
- 참고: 지금은 이것이 계속 검토 중이지만, vue_shared 폴더가 여전히 GitLab 전역 컴포넌트의 기본 디렉터리입니다.
어떤 종류의 테스트가 필요할까요? 단위 테스트와 기능 테스트를 고려해야 하나요? SET에게 지침을 구할까요, 아니면 테스트를 구현하는 것에 익숙한가요?
이 변경은 얼마나 클까요? 최대한 500+-의 차이를 유지하려고 노력하세요.

이러한 모든 질문에 대답이 있다면 안심하고 코드 작성으로 이동할 수 있습니다.

단계 3: 코드 작성

진행 중이거나 계획된 이슈에 작업을 진행할 수 없거나 장기간에 걸쳐 작업할 수 없는 경우 팀과 소통해야 합니다.

도움이 필요한 경우 브랜치를 푸시하고 Merge Request을 직접 팀원에게 공유하거나 #frontend 슬랙 채널에 게시하여 어떻게 진행해야 하는지 조언을 구하세요. Merge Request을 임시로 표시하여 완전한 검토 준비가 되지 않았음을 명확하게 전달할 수 있습니다. 언제든지 낮은 수준의 수치심을 가지고 도움이 필요할 때 도움을 요청하세요.

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

단계 4: 검토

코드를 검토하러 보내는 시기가 되면 꽤 스트레스를 받을 수 있습니다. 더 나은 예상을 얻기 위해 코드 검토 지침을 읽는 것이 좋습니다. 필수적인 가치 중 하나로 다음을 꼭 기억하세요.

… 리뷰어와의 불필요한 소통을 피하고자 … 자신의 Merge Request에 대한 자체 검토를 수행하고 코드 검토 지침을 따르세요.

이것은 작은 실수를 잡아내고 리뷰어가 불확실하거나 질문이 있는 영역에 주석을 남기는데 매우 중요합니다. 이것은 과정을 엄청나게 빠르게 진행시킵니다.

단계 5: 확인

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