배포 Zone 및 git 브랜치 전략 정리

1. 개발 및 배포 환경 (Zone) 구성

개발에서 배포까지의 과정은 4가지 Zone으로 구분됨.

1). Local (로컬환경)

• 실제 개발을 진행하며, 디버깅 및 로컬 테스트를 수행하는 로컬 환경

  • Local Zone DataBase : 가벼운 테스트를 위해 개발자가 직접 적재 혹은 로컬 실행을 통해 적재되는 정보
    • 가끔은 개발자간 데이터베이스 내 데이터 일관성을 위해 Migration SQL 구문으로 주고받음
    • 원시적인 방법으로 CSV(Comma Seperated Value) 파일을 주고받을 순 있으나 파일 크키가 큼

• 프론트엔드는 Localhost 웹 브라우저를 통한 테스트 (예, React의 HotLoader 활용한 실시간 디버깅)

• 백엔드는 Localhost Postman를 통한 테스트 (예, Spring 으로 개발한 API)

---

2). Develop (개발 테스트 환경)

• 로컬에서 충분한 테스트를 완료한 코드가 모이는 첫 번째 공유 테스트 환경

• 개발자가 자유롭게 데이터를 적재하며 다양한 유즈케이스를 검증.

  • Develop Zone DataBase : 테스트를 위해 개발자들이 직접 적재 혹은 테스트를 통해 적재되는 정보
    • 로컬에서보다 적재된 데이터량이 많고, 개발자들이 테스트를 진행하여 더 다양한 유즈케이스 커버
    • 개발자간 데이터를 주고받을 필요없이 마음껏 단일 Develop DB에 적재할 수 있다.

• 로컬에서 개발을 완료했다는 것은 개발자 개인이 수행해볼 수 있는 최대한의 유즈케이스를 커버했다는 뜻

  • 주의: 이 단계에서 버그를 찾는 것이 당연하게 여겨져서는 안 되며, 로컬에서 최대한 디버깅해야 함.

• 프론트엔드는 자신이 만든 프론트엔드가 다양한(개발자) 유저에 잘 표기가 되었는가?

• 백엔드는 자신이 만든 API가 백엔드, 프론트엔드가 실제 호출했을때 문제가 없는가?

---

3). Staging (배포 전 테스트 환경)

• 운영 환경과 가장 유사한 환경에서 최종 배포전 네트워크 및 인프라 환경에 대한 마지막 테스트

• 하나의 버그가 치명적인 상황(경제적 이슈)을 불러일으키는 거대 유저를 보유한 기업의 경우에 많이 구축

• 운영 환경과 비슷한 DB 데이터를 가져오되, Sanitizing(익명화)을 통해 개인정보 보호.

  • Staging Zone DataBase : 운영존과 가장 가까운 수준의 데이터량을 적재
    • 일반적으로 Develop Zone 과 Production Zone 의 DB 에 적재된 데이터량의 편차가 심함
    • 비유를 하자면 Develop Zone 데이터량이 100 이면, Production Zone 데이터량은 10000 이상
    • 수많은 데이터를 직접 적재하기 힘들기 때문에, 운영존 DB 에서 동기화해옴
      • 단, Sanitizing 이란것을 통해 개인정보들에 대해 난수화 - 개인정보보호 법적 보호

• 대규모 서비스에서는 필수적이나, 비용 문제로 스타트업이나 중소기업에서는 생략되기도 함.

  • 비용의 문제 : 운영존과 비슷한 환경을 구성하기 위해 사용해야하는 AWS 비용은 운영만큼 든다.

---

4). Production (운영 환경)

• 실제 유저가 사용하는 환경으로 개발 및 수정 등에 신중해야하며, 제약이 심함

  • Production Zone 데이터베이스 : 실제 유저가 사용하는 운영 DB
    • 데이터베이스에 대한 ALTER 명령어는 매우 신중해야한다. 리인덱싱 이슈 등
    • 이상적으로는 백업 전략을 통해 치명적인 문제가 발생할 경우 돌아갈 DB 스냅샷이 필요
      • 언제나 그렇듯 대체의 환경과 기업에서 이상적인 상황을 적용하지는 않는다. 현실과의 타협

• 운영 배포 후에는 장애 대응 및 롤백 전략이 필수적임.
• 개발과 테스트를 완료한 경우, 실제 유저들이 해당 기능을 사용할 수 있게 최종 배포를 해야한다.

---

2. Git 브랜치 전략 (git-flow)

원칙은 모든 배포는 격리된 브랜치에서 작업을 완료한 뒤 PR를 통해 배포를 위한 브랜치에 머지해야한다.
배포 안정성을 위해 3가지 주요 브랜치를 운영.

1). Master/Main - 운영/배포 브랜치

• 운영 환경(Production Zone)에 배포되는 안정적인 코드가 포함됨.
• 버그 발생에 대한 불확실성이 낮고, 항상 무결성을 보장해야 하며, 롤백이 가능해야 함.

2). Develop (Staging) - 테스트 브랜치

• 로컬에서 충분히 테스트한 코드가 모여 최종 테스트를 수행하는 브랜치.
• Staging 브랜치를 추가로 둘 수도 있으나, 일반적으로 Develop에서 테스트 후 운영 배포.

3). Feature - 개발 브랜치

• 개별 기능 개발을 위한 브랜치로, Develop 브랜치를 기점으로 생성.

• 브랜치 네이밍 예시

  • feature/HELLO-001 → 티켓 ID 기반 브랜칭
  • feature/login-with-oauth → 기능 설명 기반 브랜칭
    • aaron/login-with-oauth → 개발자 이름을 추가하여 명시적 구분

• 로컬에서 개발을 완료한 경우 Develop 브랜치에 PR 요청을 하여 마지막 테스트를 준비한다.

  • PR 요청을 통해 로컬에서 완료한 개발 코드를 개발자들에게 최초 노출하여 코드 리뷰를 받을 수 있고
  • PR 요청을 통해 Github Workflow 로 CI (테스팅) 파이프라인을 연결하였다면, 코드 유효성 테스트