TIL. 지속적 통합/배포(CI/CD)를 위한 Git Workflow 전략

Kim Chioh·2021년 4월 23일
0

Git Flow
2010년 Vicent Driessen이라는 분이 만든 가장 널리 알려진 Git 작업 절차입니다. Git Flow는 master와 develop이라는 항상 존재하는 주 브랜치가 있고, feature-, hotfix-, release-라는 필요에 따라 생성하는 브렌치가 있습니다. 물론, 이후 improvement-, bugfix- 등 프로젝트에 따라 다양한 브랜치 모델이 추가되기도 하였습니다.

이 절차는 다음과 같은 형태로 진행됩니다.

master 브랜치에서 develop 브랜치를 분기합니다.
개발자들은 develop 브랜치에 자유롭게 커밋을 합니다.
기능 구현이 있는 경우 develop 브랜치에서 feature- 브랜치를 분기합니다.
배포를 준비하기 위해 develop 브랜치에서 release-
브랜치를 분기합니다.
테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.
그리고 이 절차가 반복됩니다.

프로덕트를 빌드하는 일이 힘들고 시간이 걸리던 과거가 있었습니다. 개발자들은 빌드를 위해 수동으로 컴포넌트들을 통합하고 빌드했으며, 그렇게 어렵게 만들어진 결과물은 테스트를 위해 또 많은 시간을 보내야 했습니다. Git Flow가 인기를 얻었던 것은 이러한 그 시대의 개발 인프라에 만족했기 때문입니다.

이 flow는 배포 시기가 명확한 프로젝트에 특화되어 있습니다.

배포가 없을 때에는 개발자가 자유롭게 커밋을 진행하지만, 배포를 위해 release-* 브랜치가 만들어지면 집중적으로 버그 수정을 합니다. 이는 전통적인 방식의 개발 흐름에서는 문제가 없지만 지속적 통합/배포가 가능해진 요즘에는 오히려 문제를 일으킵니다. 배포 가능한 버전을 만들기 위한 사전 작업이 필요하기 때문이죠. 배포를 하려면 각 잡고 몰아치기를 해야 합니다.

최근에는 프로덕트를 통합하고 배포하는 일이 클라우드에서 자동으로 이루어집니다. 커밋만 올리면 알아서 동작하므로, 누가 되었든 항상 최신 빌드를 사용 할 수 있습니다. 이런 개발 프로세스의 발전으로 인해 이제 더 이상 예전처럼 배포 주간을 두고 배포를 위한 브랜치를 만들어 따로 관리 할 필요가 없습니다.

GitHub Flow

2011년 GitHub에서 제시한 워크플로는 언제나 배포 가능한 빌드를 만들기 위한 방안이었습니다. Git Flow가 release를 위한 브랜치를 따로 두고 집중적으로 테스트를 하는 것과 달리 GitHub Flow는 커밋이나 feature- 브랜치에서 테스트를 완료하고 Pull Request와 Code Review를 거쳐 master 브랜치에 merge합니다. 따라서, release- 브랜치 없이도 항상 배포 가능한 상태를 유지 할 수 있게 됩니다. 반면에 자율적인 테스트에 의존하기 때문에 배포에 앞서서 철저한 테스트 과정을 거치는 Git Flow에 비해 빌드의 안정성이 떨어질 가능성이 있습니다.

이 둘을 통합 할수는 없을까?

GitHub Flow처럼 개발자들이 지속적으로 브랜치를 merge 하지만, 통합 테스트가 완료된 커밋들만 선별적으로 배포를 할 수는 없을까요? GitHub Flow에 staging 브랜치를 추가하고 interactive rebase를 이용해 develop 브랜치로부터 원하는 커밋들만 골라서 가져올 수 있습니다.

이 방법을 이용하려면 develop, staging, production, 이렇게 세 가지의 상시 브랜치를 유지해야 합니다. develop은 Pull Request를 거친 커밋들이 자유롭게 올라갑니다. 배포 보다는 기능 구현에 초점을 맞춘 브랜치이므로, 배포 주기에 구애받지 않고 커밋을 올릴 수 있습니다. staging 브랜치는 배포가 확정 된 커밋들이 있을 곳입니다. 참고로 이 staging 빌드는 Git Flow의 release 브랜치와 성격이 다릅니다. release가 배포를 위해 브랜치를 분기시켜 테스트와 버그 수정을 한 후 배포가 완료되면 다시 원래의 브랜치로 merge되는 반면, staging 브랜치는 지속적으로 유지됩니다. 따라서, 지속적 통합/배포 기능을 구축해두었다면 팀원 누구든 배포 가능한 빌드를 staging 빌드로 테스트 해 볼 수 있습니다.
production - staging 브랜치에서 테스트가 완료되면, production 브랜치를 staging 브랜치로 merge하는 것만으로 배포가 완료됩니다.

한줄 요약 - 개발자의 커밋들이 develop 브랜치를 거쳐 staging으로 merge 되고, 이후 production으로 배포되는 과정

참고 블로그 : https://blog.ull.im/engineering/2019/06/25/git-workflow-for-ci-cd.html

profile
Just do what to do

0개의 댓글