feature 추가가 끝난 develop 브랜치에서 main 브랜치로 안정적으로 merge 하기 위한 release 브랜치를 추가하려고 합니다.
문제 상황
피처 작업이 어느 정도 끝난 develop 브랜치에서 main 브랜치로 pull request를 생성하고, 자동화된 배포 과정에서 문제(log 실패, 비밀 읽기 실패 등)가 터졌을 때, 이 문제를 수정하기 위한 전용 브랜치가 있어야 하지 않나 생각했습니다.
이 브랜치가 없을 경우, 배포를 위한 브랜치를 develop에서 또 분기해서 작업을 한 뒤, develop에 PR을 날리고, merge 한 뒤에 다시 main 브랜치에 PR을 하는 것이 비효율적이라 느껴졌습니다.
이미 저희 같은 문제점을 해결하기 위해 git flow에서는
release 브랜치를 따로 두고 있더라구요. 처음엔 develop 브랜치로 충분하지 않나 생각했는데, 실제 문제를 경험해보니 필요하다고 느껴졌습니다. (맞으면서 배운다)해결 방식
- develop 에서 피처 추가가 끝나서 새로운 버전으로 배포하는 시점이 왔을 때, develop에서 분기된 release 브랜치를 생성합니다.
- 먼저 release 브랜치에서 main 브랜치로 pr을 생성해서 Github Action의 CI / CD 프로세스를 진행합니다.
- 배포가 성공적으로 이루어 졌을 경우 그대로 merge 하고, 그렇지 않을 경우 release 브랜치에서 수정 작업을 진행한 뒤 commit - push 합니다.
cf) 실제 서비스에서는 release 브랜치에서 QA를 진행한다고 하네요. 아마 QA 전용 컴퓨터가 존재하고 Pray의 부하 테스트 같은 작업을 그 컴퓨터에서 진행할 것 같습니다!- 성공할 때 까지 3을 반복합니다. (수많은 commit 생성)
- merge하면 release 브랜치의 변경 사항을 develop에도 반영해야 하므로, develop에 PR을 날려서 CI 테스트를 끝내고 merge 합니다.