Git flow에서 CI/CD는 어떤 브랜치에 구축하는 것이 좋을까?

 

필수 기능 구현을 어느정도 마치고 도메인 merge 작업도 conflict를 해결해가며 잘 이루어지고 있다. 회원 쪽 UserDetails 가 아직 구현되진 않아서 연결하는 데 시간을 들여야하지만, 연결 작업이 크게 어려울 것 같다는 생각은 없다. 아무튼 이와 더해 의도치 않게 프로젝트 기간이 1일 연장되면서 시간이 충분히 확보되었다. 드디어 내가 기다리고 기다리던 CI/CD 구축에 도전해볼 수 있게 되었다.

 

아무튼, 이전에 학습했던 내용을 토대로 배포 서버에 Jenkins 컨테이너를 실행하고, 필요한 플러그인이나 Credentials을 등록해야 한다는 것을 알고 있었다. GitHub 레포지토리에 Webhook으로 PR, Merge 등을 설정해주면 Jenkins가 이 hook을 받아 내가 설정한 Jenkins Pipeline 로직을 실행할 것이었다.

 

이에 따라 GitHub의 어떤 브랜치에 CI/CD를 적용할 것인지에 대해 생각해야 했다. 이전 프로젝트들에서는 프론트엔드, 백엔드, 데이터 등 다양한 팀의 작업이 develop 브랜치에서 합쳐지고 있었고, 짧은 기간이었지만 나름 규모있는 토이 프로젝트였던만큼 바로바로 배포 버전에 대한 피드백이 있었어야 했기에, develop 브랜치에 CI/CD를 구축했었다.

 

하지만, 이번 프로젝트에서는 API path 에서부터 버전을 명시했던만큼 배포 버전을 관리할 수 있는 구조를 가져가고 싶다는 생각이 명확했다.

 

 

 

우리 팀은 Git flow와 유사한 브랜치 전략을 세웠기 때문에, develop 브랜치에서 코드의 Merge 작업이 빈번하게 일어나고 있었다. 이에 CI는 develop 브랜치의 PR Webhook에 따라 동작하게 하고, release 브랜치의 Push Webhook에 따라 CI/CD Pipeline을 구축하기로 했다.