기존에 우리 프로젝트에서 에러가 발생하면, Develop브랜치에서 hotfix 브랜치를 파서 > Develop브랜치에 머지를 했다. 하지만 Develop브랜치에 반영을 할 경우, Master 브랜치에는 영향을 미치지 못한다. 이 Git전략은 잘못되었다고 생각했다.
우리 프로젝트가 채택한 Git Flow전략에서 빠르게 에러를 수정하는 Hotfix브랜치는 원래 master브랜치에서 생성이 되어야 한다. 현재 무언가 잘못되었다.
<aside> ❓ Git Flow전략이 뭔데?
2010년 Vincent Driessen이 그의 블로그에 올리며 인기를 끌며 대중적으로 사용하게된 브랜치 전략이다. 그는 2020년, 웹 애플리케이션에서 이 Git Flow전략이 적합하지 않다고 이야기하였다. 그 이유로, 웹 애플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공되므로 여러 버전의 소프트웨어를 지원할 필요가 없다고 한다. 앱은 여러 버전으로 관리하여 병렬적으로 지원할 필요가 있지만, 웹은 항상 최신의 단일 버전만을 사용하며 하루에 여러 번 릴리즈 될 수 있기 때문이다.
</aside>
하나의 버전만을 사용하기 위해서 Git Flow전략이 적합하지 않다고는 하는데, 우리 서비스는 운영 서버(Main 브랜치)와 개발 서버(Develop 브랜치)를 구분하여 운영하고 있다. 운영 서버는 실제로 사용자들이 이용하는 서비스, 개발 서버는 우리 팀원들이 배포 전에 테스트할 수 있는 서비스이다. 이 둘을 구분해야 더 오류 없이 운영이 가능하다. 운영 서버에 배포하기 전에 웹에서 혹은 앱에서 개발 서버로 테스트를 해볼 수 있기 때문이다. 앱 또한 개발 버전과 운영 버전을 구분해두었다.
우리 서비스가 웹뷰 기반 앱이여서 그런가 생각해볼 수 있지만, 웹이여도 상황은 동일했을 것이라 생각한다.
Github Flow 방식은 Main브랜치와 feature브랜치만 두고, 항상 배포되는 Main브랜치를 중심으로 한 브랜칭 전략이다. 이 방식은 장애 상황에 대해 가장 빠른 롤백 시나리오가 필요하지 않은 경우 적합하다고 한다. 배포 서버와 운영 서버를 분리하여 운영하는 우리 서비스에는 적합하지 않다고 판단하였다.
보통 운영은 main, 개발은 develop브랜치에서 이뤄진다. main에서 develop로 판 다음, feature브랜치 단위로 파서 작업을 진행해 해당 작업을 마치면 develop에 머지를 하는 방식이다.
지금 발생한 문제가 있다. develop에서 hotfix를 파서 에러를 수정해서 develop에 머지를 했다. 그런데 이 문제는 실제 앱(운영 서버)에서 발생한 에러였다. 물론 개발 서버에서도 발생했던 에러였다. 해당 에러를 픽스하여 develop를 main에 머지를 하려했는데 develop에서 한 작업(국가 설정 기능)이 백엔드 서버에서는 아직 배포가 이뤄지지 않았다. 백엔드 서버에서는 국가 설정 기능을 개발 서버에만 업데이트를 하고, 운영 서버에 올리지 않고 다음 개발 과업인 커뮤니티를 개발하고 있는 중이다. 이에 대한 해결책은 두 가지가 떠오른다.