오늘 진행한 일

Git 브랜치 전략 확정

오전에 Git 브랜치 전략 특강이 있었다. 어제는 분명 우리끼리 정한 브랜치 전략을 컨펌 받는 느낌으로 특강을 듣자고 했었는데, 특강을 듣고 미션을 진행하고 나니 전략을 전면 수정할 필요가 있었다. Git 브랜치 전략 수정에 대한 회의를 하다 보니 하루가 다 지나갔다. Git 브랜치 전략 수정 과정에 대해서는 발생한 이슈에서 설명하도록 하겠다.

디자인 회의

중간에 디자인에 대한 회의도 진행했다. 어제 대강 큰 틀은 정한 상황이었는데, 좀 더 고도화를 하기 위해서 시간을 보냈다. 다른 페이지들은 세세한 부분을 수정하는 정도였고, 메인 페이지와 마이 프로필 페이지 쪽에서 많은 변경이 있었다. 우선 현재 랜딩 페이지로 정해져 있는 페이지의 경우, 인기 있는 장비 리스트를 5개에서 4개로 바꾸면서 조금 더 큰 컴포넌트를 화면에 보일 수 있도록 했고, 각각의 컴포넌트들의 외곽선을 없앴다. 그러고 나니 가시성도 좋아지고 훨씬 깔끔해보이게 되었다.

프로필 페이지의 경우 아직 완성 단계는 아닌데, 최초 깃허브 로그인 시 회원 가입으로 받는 정보들(현재는 년차와 직군)을 함께 보여주는 칸을 만들었고, 대표 장비를 수정하는 버튼의 위치를 장비 리스트를 보여주는 곳에서 대표 장비를 보여주는 섹션으로 이동시켰다. 그리고 유저에게 보여줄 이름도 그냥 장비가 아닌 XXX's 픽, XXX's 아이템으로 보여주기로 했다.

코드 리뷰, approve, merge에 대한 규칙 정하기

스프린트 2부터는 몹 프로그래밍이 끝나고 각각의 기능에 대한 개발팀으로 진행되기 때문에 다른 팀에서 작성한 코드에 대해서 숙지하고 피드백을 줄 수 있도록 코드 리뷰를 진행해야 한다. 때문에 리뷰를 받고 approve를 받은 뒤 merge하는 과정이 필요한데, 이에 대한 규칙을 정했다.

우선 issue → feature의 PR까지 approve를 받아버리면 프로젝트 진행에 차질이 생긴다고 판단, feature → release, hotfix → main, bugfix → main PR에 대해서만 코드 리뷰 및 approve를 진행하기로 결정했다. 그리고 일과 시간인 저녁 6시까지 발생한 PR에 대해서는 다음날 데일리 미팅 이전까지 리뷰를 진행하기로 했다. merge를 하는 기준은 자기 팀이 아닌 모든 인원이 approve를 하면 merge 하기로 했고, 반드시 PR을 작성한 팀이 직접 merge를 하기로 결정했다.

오늘 발생한 이슈

Git 브랜치 전략

스프린트 1에서는 main - feature 로 브랜치가 이루어져 있었다. 여기서 feature는 이슈마다 각각의 브랜치를 생성하고, main으로 PR을 날려서 merge하는 방식이었다. 하지만 자동 배포를 하기 위해서 main 브랜치는 정말 배포해야 할 때만 건드리고 그 외에 개발하는 브랜치는 따로 분리해야 할 필요가 있었기 때문에, 사이에 dev 브랜치를 두기로 정했었다.

하지만 오늘 Git 미션을 진행하면서 문제가 생겼는데, 만약 A와 B라는 두 개의 기능을 만들었는데, A는 아직 QA 중이고, B는 QA가 끝나서 B만 배포해야 하는 상황일 때, A → B 순으로 dev 브랜치에 커밋되어 있을 경우 문제가 생겼다. 이럴 경우 A를 revert해야 하는 상황이 발생했다. (dev는 선형적으로 모든 feature들을 가지고 유지하는 브랜치이므로)

그래서 Git 브랜치 전략을 전면 수정하기로 하고 고민을 많이 해봤다. 우선은 가장 먼저 확정된 부분은 기존에 feature 브랜치들을 issue 단위로 만들던 것을 기능 단위로 만들기로 변경하는 부분이었다. 예를 들면 프로필 기능을 만든다 라는 feature 브랜치를 만드는 것이다. 그렇다면 issue들은 어디서 관리하냐고 하면, 해당 feature 브랜치에서 다시 이슈 별로 브랜치를 분기해서 feature 브랜치로 머지하는 방식을 선택했다.

이렇게 하면 하나의 feature 자체는 다른 feature와 연동되는 기능을 제외한 자체 기능들에 대해서는 충분히 테스트를 진행할 수 있다. 그리고 기능 구현이 완료되고 테스트도 완료되면 이 feature들을 모아서 통합 환경을 구성하고 통합 테스트, 즉 QA를 진행할 브랜치가 필요했는데 이 브랜치 이름을 release로 정했다.

feature들을 하나로 통합하는 과정을 release로 하지 말고 release는 배포 준비 작업을 하고, 통합 과정은 dev 브랜치에서 진행하자는 의견도 있어서, dev 브랜치를 유지하자 vs 없애고 release에서 다 처리하자 라는 두 가지 의견이 대립했다. 아마 회의 전체에서 해당 논의가 가장 오래 걸렸던 것 같다. 이 논의는 결국 굳이 없어도 될 브랜치를 만들 필요가 없다 라는 의견에 따라 dev 브랜치를 없애는 것으로 결정지어졌다. 최종적으로는 다음과 같은 그림의 Git 브랜치 전략이 만들어졌다.

• issue: feature나 bugfix에서 분기하는 각각의 이슈에 대한 브랜치. feature또는 bugfix로 PR 및 머지
• feature: release에서 분기하는 하나의 기능 단위에 대한 브랜치, release로 PR 및 머지
• release: main에서 분기하며 하나의 배포 주기 당 하나 생기는 배포용 브랜치로 테스트 서버를 통한 통합 테스트 및 해당 과정에서 나오는 버그에 대한 수정을 담당. main으로 PR 및 머지
• bugfix: release 브랜치를 테스트하는 과정에서 버그가 발생하면 분기하여 수정을 하는 브랜치. release로 PR 및 머지
• main: 최종 배포 브랜치. main에 merge되면 자동으로 배포 서버에 배포되도록 설정.
• hotfix: 배포 서버에 문제가 발생하면 main에서 분기하여 문제를 수정하는 브랜치. hotfix를 main으로 머지 시 release 브랜치에서는 rebase 하여 동기화한다.

내일 목표

내일부터는 본격적으로 코드를 작성하게 된다. 우선은 Review - Product 간 연관관계를 맺고 랜딩 페이지에서 리뷰 조회 시 제품의 정보를 보여줄 수 있도록 DTO를 새로 만드는 작업의 완성을 목표로 한다.