효율적인 Monorepo 브랜치 전략: 안정적인 배포를 위한 가이드

 

안녕하세요! 오늘은 여러 클라이언트 애플리케이션과 서버 애플리케이션을 포함하는 Monorepo 환경에서 효과적인 브랜치 전략을 구축하는 방법에 대해 이야기해보려 합니다. 이 전략은 코드 품질을 유지하고, 모든 서비스에 걸쳐 원활한 배포 프로세스를 보장하기 위해 설계되었습니다.

 

 

📒 소개

Monorepo는 여러 프로젝트를 하나의 저장소에서 관리하는 방식으로, 코드의 재사용성과 일관성을 높이는 데 유용합니다. 하지만 여러 애플리케이션이 함께 개발되고 배포되다 보면 브랜치 관리가 복잡해질 수 있습니다. 이에 따라, 효율적인 브랜치 전략을 수립하는 것이 중요합니다.

 

 

📗 워크플로우 이미지 참고

워크플로우의 전반적인 흐름을 이해하기 위해 위 이미지를 참고하세요.

 

 

이미지 설명

배포 브랜치 'master'

• 제품으로 출시될 수 있는 브랜치
• 'develop' 브랜치를 merge(병합)을 통해 최종본을 릴리즈
• CI/CD 트리거를 통해 자동화 배포 진행

개발 브랜치 'develop'

• 프로젝트를 진행하는 주요 브랜치
• 'feature' 브랜치로 issues(이슈), feat(기능) 별로 분배
• Pull requests(검토 및 병합)을 통해 관리

기능 별 브랜치 'feature'

• 각 기능이나 이슈별로 나뉘어 개발
• 개별적인 push(배포)를 통해 'develop' 브랜치에서 통합

브랜치 생성 및 병합 과정

1. 초기 브랜치: master와 develop 브랜치가 존재하며, develop 브랜치는 master에서 시작됩니다.
2. 버그 수정: develop 브랜치에 지속적으로 버그 수정 커밋 추가
3. 기능 추가: 새로운 기능 추가 시 develop 브랜치에서 feature 브랜치 생성
4. 병합: 기능 완료 후 feature 브랜치를 develop 브랜치로 병합
5. 릴리즈 준비: develop 브랜치에서 release 브랜치 생성 후 QA 진행
6. 최종 병합: QA 통과 시 release 브랜치를 master와 develop 브랜치로 병합
7. 버전 태그: master 브랜치에 버전 태그 추가

---

 

🙏 필수 규칙

Monorepo 내에서 일관성과 질서를 유지하기 위해 다음 규칙을 엄격히 준수해야 합니다:

1. 각 서비스별 전용 배포 브랜치: 각 서비스(클라이언트 애플리케이션과 서버)는 자체적인 배포 브랜치를 가져야 합니다. 이 브랜치는 프로덕션 환경에 코드를 배포하는 데 사용됩니다.
2. 각 서비스별 전용 개발 브랜치: 각 서비스는 자체적인 개발 브랜치를 가져야 합니다. 이 브랜치는 새로운 기능 개발과 버그 수정을 통합하는 데 사용됩니다.
3. 마스터 브랜치: 프로덕션 릴리스 준비가 된 코드를 나타내는 중앙 master 브랜치가 있어야 합니다. 이 브랜치는 항상 안정적이고 배포 가능한 상태여야 합니다.

 

브랜치 구조

개요

브랜치 구조는 각 서비스의 병렬 개발 및 배포 프로세스를 지원하도록 조직되어 있습니다. 주요 브랜치는 다음과 같습니다:

• master: 프로덕션 릴리스 준비가 된 최신 안정적인 코드
  • fork: 클라이언트 개발 주요 개발 브랜치 (각각의 fork 브랜치 존재)
• test/service1: service1 테스트 배포 브랜치
• deploy/service1: service1 배포 브랜치
• test/service2: service2 테스트 배포 브랜치
• deploy/service2: service2 배포 브랜치
• test/service3: service3 테스트 배포 브랜치
• deploy/service3: service3  배포 브랜치
• develop/server: 서버 애플리케이션의 주요 개발 브랜치
• test/server: 서버 애플리케이션의 통합 및 시스템 테스트를 위한 스테이징 브랜치
• deploy/server: 서버 애플리케이션의 배포 브랜치

---

브랜치 설명

master

• 목적: 프로덕션 릴리스 준비가 된 최신 안정적인 코드를 포함하는 메인 브랜치입니다.
• 사용법: 테스트 및 승인이 완료된 서비스별 개발 브랜치(develop/<서비스명>)에서 변경 사항을 병합합니다.
• 중요 사항: 항상 배포 가능한 상태여야 하며, 테스트되지 않거나 불안정한 코드는 병합을 피해야 합니다.

🙂 클라이언트 애플리케이션 브랜치

fork 받은 개인의 브랜치

• 목적: service1, service2, service3 클라이언트 애플리케이션의 주요 개발 브랜치입니다.
• 사용법: 개발자는 이 브랜치에서 기능 브랜치를 생성하고, 완료된 작업을 test/<서비스명>에 보낸 후 문제가 없으면 master 브랜치로 병합합니다.
• 워크플로우:
  • 기능 개발 및 버그 수정
  • 브랜치 내에서 코드 리뷰 및 테스트
  • master로 병합 준비

test/service1, test/service2, test/service3

• 목적: 클라이언트 테스트를 위한 스테이징 영역입니다.
• 사용법: 안정성이 확보될 때까지 개인의 fork 브랜치에서 코드를 받아 철저히 테스트합니다.
• 워크플로우:
  • 다른 서비스와의 통합 테스트
  • 성능 및 회귀 테스트
  • 발견된 버그는 개인의 fork 브랜치에서 수정 후 푸시

deploy/service2, deploy/service2, deploy/service3

• 목적: 해당 클라이언트 애플리케이션의 배포 브랜치입니다.
• 사용법: 각 클라이언트에 특정한 코드를 master에서 이 브랜치로 병합하여 배포합니다.
• 워크플로우:
  • master에서 코드 수신
  • 프로덕션 환경으로의 배포 프로세스 트리거

🙃 서버 애플리케이션 브랜치

develop/server

• 목적: 서버 애플리케이션의 주요 개발 브랜치입니다.
• 사용법: 활성 개발이 이루어지며, 개발자는 기능 브랜치를 완료 후 병합합니다.
• 워크플로우:
  • 기능 개발 및 버그 수정
  • test/server로 이동하기 전 초기 테스트

test/server

• 목적: 서버 애플리케이션의 통합 및 시스템 테스트를 위한 스테이징 영역입니다.
• 사용법: 안정성이 확보될 때까지 develop/server에서 코드를 받아 철저히 테스트합니다.
• 워크플로우:
  • 다른 서비스와의 통합 테스트
  • 성능 및 회귀 테스트
  • 발견된 버그는 develop/server에 수정 사항 푸시

deploy/server

• 목적: 서버 애플리케이션의 배포 브랜치입니다.
• 사용법: test/server에서 테스트를 통과하고 master에 병합된 코드를 받아 프로덕션에 배포합니다.
• 워크플로우:
  • master에서 코드 수신
  • 프로덕션 환경으로의 배포 프로세스 트리거

---

⭐ 배포 프로세스 ⭐

🙂 클라이언트 배포 순서

1. 개발: master에서 fork를 받아 개인의 브랜치에서 기능 브랜치를 생성하여 작업합니다.
2. 테스트: test/<서비스명> 브랜치 내에서 코드를 테스트합니다.
3. 마스터로 병합: 안정화되면 변경 사항을 master에 병합합니다.
4. 배포: master에서 해당 클라이언트에 특정한 코드를 deploy/<서비스명>으로 병합하여 프로덕션에 배포합니다.

🙃 서버 배포 순서

1. 개발: develop/server에서 기능 브랜치를 생성하여 작업합니다.
2. 개발 브랜치로 병합: 완료된 기능은 develop/server로 병합합니다.
3. 테스트 서버에서 테스트: 변경 사항을 test/server로 병합하여 통합 및 시스템 테스트를 수행합니다.
4. 마스터로 병합: 모든 테스트를 통과한 후 코드를 master에 병합합니다.
5. 배포: master에서 코드를 deploy/server로 병합하여 프로덕션에 배포합니다.

---

위의 브랜치 전략을 준수함으로써 효율적인 개발과 신뢰할 수 있는 배포를 지원하는 구조화된 워크플로우를 보장할 수 있습니다. 이 문서에 설명된 필수 규칙과 모범 사례를 따르면, 팀은 높은 코드 품질을 유지하고 통합 이슈를 줄일 수 있습니다. Monorepo 환경에서의 효과적인 브랜치 관리는 프로젝트에 굉장히 중요하다고 생각합니다. 피드백은 항상 환영합니다!

---

참고 자료:

• https://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

 

감사합니다!