Rand_Chat 프로젝트의 GitHub Branch 전략과 , CI/CD 전략을 설계,구성하고 가이드한다.

배포환경

---

서비스 별 별도의 인스턴스 (다중 인스턴스환경)

• 백엔드 - 회원서버 : EC2 (Docker)
• 백엔드 - 매칭서버 : EC2 (Docker)
• 백엔드 - 채팅서버 : EC2 (Docker)
• 프론트엔드 : EC2 (Docker)
• Nginx , Certbot : EC2(Docker-Compose)
• 데이터베이스 : RDS(Master,Read-only)
• 인메모리 : ElastiCache-Redis(Single Node) -> 추후 클러스터로 변경가능
• 파일시스템: S3
  
  
  

운용 브랜치

---

• main
• develop
• feature
• hotfix
• tag

개발자 Branch / CD 전략

---

• 각 개발자는 feature/** 브랜치를 운용해 기능별 개발을 한다.
  
• 완성된 기능은 develop으로 PR을 한다.
• 단위테스트에 통과한 PR에 대해 DevOps(Kim Yong Jun)이 Merge를 한다.
• 각 개발자는 원격 develop을 상시 풀을 받는다. (기능별 Merge가 된 후에도)
• 기능별 PR을 했다면 , 최신 develop을 Pull 받고, 새로운 featrue를 만들어 개발하는 것을 권고한다.

CD 전략

---

• DevOps 담당자(Kim Yong Jun)는 통합된 main브랜치의 코드를 버전으로 태그를 관리하여 release / tag생성을 한다.
  
  
• 깃허브액션이 트리거되어 통합테스트를 진행한다.
  
  
• 통합테스트가 통과되었다면 , 각 서비스 별 이미지를 빌드하고 , 도커허브에 푸시한다.
  
  
• 모든 이미지가 푸시가 완료되면 , 해당 버전에 맞는 이미지를 서비스 별 EC2 인스턴스에서 각 이미지를 풀을 받아 구동한다.
  
  
• 버그 긴급수정 시 해당 태그를 가져와 수정 후 main브랜치에 Merge 및 재배포한다.
  (release/tag)
  
  
• 이전 버전을 배포하고 싶을 시 release노트를 재배포-날짜 형식으로 수정 후 edit하여 배포 프로세스를 트리거한다.
  
  
  

- 허브 푸시대상

• 백엔드 - 회원 서비스
• 백엔드 - 매칭 서비스
• 백엔드 - 채팅 서비스
• 프론트 엔드

Nginx는 자동배포를 진행하지만 , 이미지를 자동으로 푸시하지않는다.
(변경성 낮음, workflow낭비) -> 수동으로 이미지를 배포한다.

- 통합테스트 대상 인스턴스

• 통합테스트는 핵심기능 및 서비스에 중대한 영향을 끼칠 인스턴스에 대해 테스트한다.
  • 백엔드 : 매칭서버
  • 백엔드 : 채팅서버

제한사항 및 변경사항

---

서비스 별로 별도의 이미지 버전 및 별도의 배포 프로세스를 구동하려 했지만 , 깃허브 리포지토리가 하나이고 , 모듈이 모여있는 상황이라 제한되었다.

물론 할 수 있는 방법은 있었지만 , 비용적 측면에서 비효율적이라 판단하였다.

서비스는 별도의 인스턴스에서 동작하며 버전관리는 전체서비스 기준으로 하기로 결정하였다.