Git 현업 워크플로우 - 환경별 배포 전략

재성고·2025년 7월 4일
git
0

GIT

목록 보기
1/4
post-thumbnail

1. 현업 서버 환경 구성

일반적인 서버 환경

개발 → 스테이징 → 릴리즈 → 운영
(Dev)  (Staging)  (Release)  (Production)

각 환경의 역할

  • 개발 환경 (Dev): 개발자들이 기능을 테스트하는 환경
  • 스테이징 환경 (Staging): QA 테스트 및 통합 테스트 환경
  • 릴리즈 환경 (Release): 운영 배포 직전 최종 검증 환경
  • 운영 환경 (Production): 실제 사용자가 사용하는 환경

2. 환경별 Git 브랜치 전략

브랜치와 환경 매핑

# 브랜치 → 환경 매핑
feature/* → 개발 환경 (자동 배포)
develop → 스테이징 환경 (자동 배포)
release/* → 릴리즈 환경 (자동 배포)
main → 운영 환경 (수동 배포)
등등

실제 브랜치 구조

main (운영)
├── release/v1.2.0 (릴리즈)
├── develop (스테이징)
│   ├── feature/user-profile
│   ├── feature/payment-system
│   └── hotfix/login-bug

3. 환경별 배포 워크플로우

일반적인 기능 개발 흐름

# 1. 기능 개발 시작
git checkout develop
git pull origin develop
git checkout -b feature/shopping-cart

# 2. 개발 완료 후 개발 환경 배포 (자동)
git push origin feature/shopping-cart
# CI/CD가 자동으로 개발 환경에 배포

# 3. 스테이징 환경 배포를 위한 PR 생성
# feature/shopping-cart → develop PR 생성
# 코드 리뷰 후 merge → 자동으로 스테이징 환경 배포

릴리즈 프로세스

# 1. 릴리즈 브랜치 생성 (보통 릴리즈 매니저가 진행)
git checkout develop
git pull origin develop
git checkout -b release/v1.2.0

# 2. 릴리즈 환경 배포 (자동)
git push origin release/v1.2.0
# CI/CD가 자동으로 릴리즈 환경에 배포

# 3. 릴리즈 환경에서 최종 테스트
# 버그 발견 시 릴리즈 브랜치에서 직접 수정
git add .
git commit -m "fix: critical bug in payment flow"
git push origin release/v1.2.0

# 4. 운영 배포 (수동 승인 후)
# release/v1.2.0 → main PR 생성
# 최종 승인 후 merge → 운영 환경 배포

4. 현업에서의 실제 배포 시나리오

시나리오 1: 정기 릴리즈 (매주 화요일)

# 월요일: 릴리즈 브랜치 생성
git checkout -b release/v1.2.0

# 화요일 오전: 릴리즈 환경 최종 테스트
# 화요일 오후 2시: 운영 배포 (점심시간 이후)
# 화요일 오후 3시: 모니터링 및 롤백 준비

시나리오 2: 긴급 패치 (핫픽스)

# 운영 환경 긴급 버그 발견
git checkout main
git pull origin main
git checkout -b hotfix/payment-critical-bug

# 즉시 수정 후 릴리즈 환경 배포
git push origin hotfix/payment-critical-bug
# 릴리즈 환경에서 빠른 검증

# 승인 후 즉시 운영 배포
# hotfix/payment-critical-bug → main PR 생성
# 긴급 승인 후 배포

시나리오 3: 대규모 기능 출시

# 1주차: 기능 개발 완료
feature/major-feature → develop (스테이징 배포)

# 2주차: QA 테스트 및 버그 수정
develop에서 추가 버그 수정

# 3주차: 릴리즈 환경 배포
release/v2.0.0 생성 후 릴리즈 환경 배포

# 4주차: 운영 배포 (단계적 배포)
# 1단계: 일부 사용자 (10%)
# 2단계: 더 많은 사용자 (50%)
# 3단계: 전체 사용자 (100%)

5. 환경별 CI/CD 파이프라인 설정

GitHub Actions 예시

# .github/workflows/deploy.yml
name: Deploy to Environments

on:
  push:
    branches: [ feature/*, develop, release/*, main ]
  pull_request:
    branches: [ develop, main ]

jobs:
  deploy-dev:
    if: startsWith(github.ref, 'refs/heads/feature/')
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Development
        run: |
          echo "Deploying to Dev Environment"
          # 개발 환경 배포 스크립트

  deploy-staging:
    if: github.ref == 'refs/heads/develop'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Staging
        run: |
          echo "Deploying to Staging Environment"
          # 스테이징 환경 배포 스크립트

  deploy-release:
    if: startsWith(github.ref, 'refs/heads/release/')
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Release
        run: |
          echo "Deploying to Release Environment"
          # 릴리즈 환경 배포 스크립트

  deploy-production:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # 수동 승인 필요
    steps:
      - name: Deploy to Production
        run: |
          echo "Deploying to Production Environment"
          # 운영 환경 배포 스크립트

6. 현업 배포 규칙과 체크리스트

배포 시간 규칙

# 일반 배포 시간
- 평일 오후 2시-4시 (점심시간 이후, 퇴근 전)
- 화요일-목요일 (월요일 피하고, 금요일 피함)

# 긴급 배포
- 24시간 언제든지 (하지만 최소 2명 이상 대기)
- 롤백 계획 필수

배포 전 체크리스트

# 개발 환경 체크
☐ 기능 정상 동작 확인
☐ 단위 테스트 통과
☐ 빌드 오류 없음

# 스테이징 환경 체크
☐ QA 테스트 완료
☐ 통합 테스트 통과
☐ 성능 테스트 통과
☐ 보안 스캔 통과

# 릴리즈 환경 체크
☐ 운영 환경과 동일한 설정
☐ 실제 데이터로 테스트
☐ 모니터링 대시보드 확인
☐ 롤백 계획 수립

# 운영 환경 체크
☐ 데이터베이스 마이그레이션 확인
☐ 모니터링 알림 설정
☐ 로그 확인 가능
☐ 관련 팀에 배포 공지

7. 트러블슈팅과 롤백 전략

롤백 시나리오

# 운영 환경에서 문제 발생 시
# 1. 즉시 이전 버전으로 롤백
git checkout main
git revert HEAD
git push origin main

# 2. 또는 이전 태그로 롤백
git checkout v1.1.0
git checkout -b hotfix/rollback-v1.1.0
git push origin hotfix/rollback-v1.1.0
# 긴급 배포 프로세스로 진행

모니터링과 알림

# 배포 후 모니터링 항목
- 응답 시간
- 에러율
- 트래픽
- 메모리/CPU 사용률
- 데이터베이스 성능

# 알림 기준
- 에러율 5% 이상 → 즉시 알림
- 응답 시간 2배 이상 → 경고 알림
- 트래픽 50% 감소 → 주의 알림

8. 현업 팁과 주의사항

환경별 관리 팁

# 환경 변수 관리
DEV_DATABASE_URL=dev-db.company.com
STAGING_DATABASE_URL=staging-db.company.com
RELEASE_DATABASE_URL=release-db.company.com
PROD_DATABASE_URL=prod-db.company.com

# 환경별 설정 파일 분리
config/
├── development.json
├── staging.json
├── release.json
└── production.json

데이터베이스 마이그레이션 전략

# 안전한 마이그레이션 순서
1. 스테이징 환경에서 마이그레이션 테스트
2. 릴리즈 환경에서 실제 데이터로 테스트
3. 운영 환경 배포 전 백업
4. 운영 환경 마이그레이션 실행
5. 데이터 정합성 확인

커뮤니케이션 규칙

# 배포 전 필수 공지
- 개발팀: 배포 내용 공유
- QA팀: 테스트 결과 공유
- 운영팀: 배포 일정 공유
- 고객지원팀: 새로운 기능 안내

# 배포 후 필수 공지
- 배포 완료 알림
- 모니터링 결과 공유
- 이슈 발생 시 즉시 공지

마무리

현업에서는 안정성이 가장 중요합니다. 빠른 배포보다는 안전한 배포가 우선이며, 각 환경에서 충분한 검증을 거친 후에만 다음 단계로 진행합니다.

특히 롤백 계획은 항상 준비되어 있어야 하고, 배포 후 모니터링을 통해 문제 발생 시 즉시 대응할 수 있어야 합니다.

환경이 많을수록 복잡해지지만, 각 단계에서 문제를 미리 발견할 수 있어서 운영 환경의 안정성을 크게 높일 수 있습니다.

profile
재성고
다음 포스트

GIT fetch 와 pull 차이점

0개의 댓글