브랜치 단위 배포가 업무를 매끄럽게 할 수 있을까?

안녕하세요, 윙잇 백엔드 개발자 양원준입니다.

개발팀에서 브랜치 전략과 QA 방식을 개선하면서 브랜치 단위 배포 시스템을 도입했습니다.

기존에 겪고 있던 불편함을 어떠한 방식으로 개선하였는지 소개하고자 글을 작성하게 되었습니다.

초기 브랜치 전략의 문제점

개발팀의 규모가 작을 때는 

• develop 브랜치에 개발된 내용들을 merge하고
• merge된 내용마다 QA를 받아
• 모든 QA가 끝나면 develop을 master에 merge하여 배포하는 방식이었습니다.

→ 즉, 브랜치 전략은 다음과 같이 이루어집니다. 

위와 같은 전략은 다음과 같은 문제점이 있습니다.

• develop에 merge된 여러 개발 스토리들 중 하나라도 문제가 있어 QA가 늦어지게 되면, 다른 스토리들도 모두 연기됩니다.
• 배포를 나갈 수 없는 스토리의 경우 revert를 해야하며, 이에 따른 충돌 또한 감안하고 해결해야 하죠.

개발팀의 규모가 커짐에 따라 이러한 일이 더욱 빈번해 져서, 저희는 새로운 브랜치 전략을 세우게 되었습니다.

변경된 브랜치 전략의 문제점

스크럼, 스프린트 업무 처리 방식을 도입한 이후, 개발팀의 스토리 해결 방식은 다음과 같은 과정으로 이루어져 왔습니다.

이 중 QA를 진행하기 위해서 기존에 develop 브랜치에서 서버를 생성하였지만, QA 서버 브랜치로 작업한 브랜치를 따로 Merge하여 서버로 배포하고 QA가 마무리가 되면 다시 develop 브랜치로 Merge하여 배포대기 상태로 넘어가도록 변경하게 되었습니다.

→ 즉, 변경된 브랜치 전략은 다음과 같이 이루어집니다.

• 기존 브랜치 전략
  1. develop을 base로 한 qa 브랜치를 정기적으로 생성해둠
  2. develop을 base로 feature/a,b,c 브랜치 생성
  3. 코드 작성 후 feature → develop PR 생성 + 코드리뷰
  4. qa ← feature/a,b,c merge 후 qa 서버 배포
  5. qa 서버에서 qa 진행
  6. (qa 종료 후) feature/a,b,c → develop PR merge
  7. develop → master merge
  8. master 배포
     
     

변경된 전략대로 업무를 진행해 왔으나, 다음과 같은 문제 때문에 추가적인 작업이 필요한 경우가 많았습니다.

• qa 브랜치에 feature 브랜치들의 변경 사항들이 함께 반영되어있음

  • 같은 파일에 대한 수정이 있다면 충돌이 있고, 해결해도 develop으로 merge할 때 다시 해야 함
  • QA가 길어지면, 서로 기대하는 base(develop)의 버전이 다를 수 있는데 이를 반영할 수 없음
    
    

• 정기적으로 qa 브랜치를 업데이트 해주어야 함 (삭제 → 재생성)

  • 이전 QA 브랜치에 올렸던 내용들을 새로 생성되는 브랜치에 또 다시 올려야 함

 < 개발팀에서 서로 qa 사용 현황을 공유하는 모습.. 윽.. >

새로운 브랜치 전략

따라서, 저희의 work flow에 맞는 브랜치 전략의 개선이 필요했고, QA를 스토리 단위에서 끝마치고 develop 브랜치로 합쳐질 수 있는 방법에 대해 고민하여 아래와 같이 브랜치 전략을 변경해보았습니다. 

• 변경된 브랜치 전략
  1. develop을 base로 한 story 브랜치를 생성
  2. story 브랜치를 base로 feature 브랜치 생성
  3. 코드 작성 후 feature/a,b,c → story PR 생성 + 코드리뷰
  4. story ← feature/a,b,c merge 후 story 서버 배포
  5. story 서버에서 qa 진행
  6. (qa 종료 후) story → develop PR 생성 & merge
  7. develop → master merge
  8. master 배포
     
     

바뀐 브랜치 전략에서 기존 브랜치 전략의 문제점들이 해결될 수 있는지 살펴보면,

• qa 브랜치에 feature 브랜치의 변경 사항들이 함께 반영되어있음

  • 같은 파일에 대한 수정이 있다면 충돌이 있고, 해결해도 develop으로 merge할 때 또 해야함

    → develop으로 Merge할 때의 충돌만 해결하면 됨

  • QA가 길어지면, 서로 기대하는 base(develop)의 버전이 다를 수 있는데 이를 반영할 수 없음

    → story 브랜치를 생성하는 시점의 develop 버전을 독자적으로 가질 수 있음
    
    

• 정기적으로 qa 브랜치를 업데이트 해주어야 함 (삭제 → 재생성)

  • 이전 QA 브랜치에 올렸던 내용들을 새로 생성되는 브랜치에 또 다시 올려야 함

    → 담당자 본인의 story 브랜치에서 QA가 진행되기 때문에 더이상 발생하지 않음
    
    

브랜치 전략은 저희의 업무 flow에 맞게 변경을 했지만, 이에 앞서 해결해야 할 과제가 하나 더 남아있었습니다.

브랜치 단위 배포

바뀐 git 브랜치 전략은 결국 story 브랜치별로 서버가 생성이 되어야합니다. 그리고 story 브랜치 서버에서 QA가 끝나면, develop으로 story 브랜치를 Merge해야합니다.

저희는 Jenkins의 CI/CD 파이프라인, AWS 리소스를 통해 서버의 배포가 이루어집니다. 따라서 브랜치 단위 배포를 위해 세팅해주어야 할 작업은 다음과 같습니다.

• Jenkins
  • 정해진 브랜치 명칭(develop, master, story, ...) 외 다른 브랜치들을 follow하지 않도록 변경
  • story/ 하위의 브랜치인 경우 aws 리소스를 새로 구성하는 스크립트를 호출하도록 변경
• AWS
  • story/ 하위 브랜치의 경우 브랜치 이름을 조합하여 AWS 리소스들을 새로 생성하여 배포하는 스크립트 작성

우선 Jenkins에서는 multi-branch pipeline을 사용하여 develop, master, story 브랜치 이외의 브랜치는 빌드 대상에서 제외하도록 변경하였습니다.

그리고 story 브랜치의 배포 파이프라인에는 각 스토리 브랜치별로 독자적인 AWS 리소스 그룹을 생성하는 스크립트를 호출하도록 변경하였습니다.

기존 QA용 서버는 AWS에서 다음과 같은 리소스들로 구성되어 있습니다.

각 리소스 별로 아래와 같은 역할을 담당하고 있습니다.

• CodeDeploy
  • DeploymentGroup
    • 정해진 배포 전략에 맞춰 기존 컨테이너 이미지를 새 이미지로 교체하는 이벤트를 ECS에 전달하고, 트래픽을 재배치 시켜주는 작업 단위
• Elastic Container Service
  • Service
    • 컨테이너 관리 전략을 수행하는 단위 (Auto Scaling, 배포, 시스템 로깅)
  • TaskDefinition
    • 컨테이너 이미지 버전을 관리하는 단위
• Elastic Load Balancing
  • LoadBalancer
    • 외부(클라이언트)로부터 들어온 트래픽을 정해진 규칙에 맞게 내부 인스턴스로 분산
  • TargetGroup
    • 로드밸런서에서 통과한 요청을 정해진 target ip로 routing
• Route 53
  • RecordSet
    • DNS 및 도메인 이름 관리 시스템

각 리소스별로 아래와 같은 이름 규칙을 통해 리소스들을 생성하여 브랜치 단위로 묶음 관리를 하도록 구현하였습니다.

• DeploymentGroup

• Service, TaskDefinition

• LoadBalancer(HostingRule), TargetGroup

< story/ 하위 브랜치를 기반으로 Host, TargetGroup이 생성된다. >

독립된 서비스 간의 연결

FE/BE가 분리된 서비스의 경우 서로 네트워크 요청과 응답을 위한 연결을 해주어야 합니다.
브랜치 단위로 서버가 생성되고, AWS의 리소스들이 생성되기 때문에 각 서버들의 도메인 또한 브랜치 이름을 기반으로 생성합니다. 예를 들어, 윙잇 메인페이지 개편 스토리 진행 작업을 위한 브랜치 이름을 feature/improve-main-page로 생성했다고 가정해보면, FE/BE 서버의 도메인은 다음과 같이 세팅이 됩니다.

프론트엔드, 백엔드 프로젝트의 각 브랜치 이름을 통일하고 브랜치 단위 배포를 진행하게 되면, 젠킨스에서 프론트엔드의 환경변수에 백엔드 도메인에 관한 정보를 브랜치 이름을 기반으로 생성해주기 때문에 네트워크 요청 연결이 가능하게 됩니다.

마치며

이번 브랜치 전략 변경과 브랜치 단위 배포를 도입하면서 개발팀의 업무 프로세스가 더 매끄러워졌습니다. 우선 서로 qa 브랜치 혹은 서버를 사용하고 있는지 공유할 필요가 없어져서, 불필요한 작업을 줄일 수 있었습니다.

 또한 QA 담당자분들께서도 더 편해지셨습니다. 자신이 담당한 QA가 계속 올라갔다가 사라지는 일들이 발생하지 않기에, 기간에 구애받지 않고 QA가 가능하기 때문이죠.

이번 브랜치 단위 배포 업무를 수행하면서 AWS 리소스들의 역할 및 구성 요소, 동작 원리에 대해 파악할 수 있었고, Jenkins 파이프라인의 구성 및 관리에 대해 많은 것을 배울 수 있었습니다. 또한 업무에 많은 도움이 되는 학습의 기회를 얻으며 수행할 수 있게 되어 더욱 유익한 경험이었습니다.

저와 유사한 고민을 하시는 분들께 도움이 되길 바라며, 마치겠습니다 :)