[Git] CI/CD 정책

오늘은 GitHub 배포 정책 중에서 CI/CD 정책에 대해서 작성해보도록 하겠습니다. 우선 CI/CD에 대해서 설명을 해보도록 하겠습니다!!

 

 

1. 들어가며

최근 프로젝트에서는 코드 변경이 있을 때마다 서버에 수동으로 배포하는 과정이 반복되었습니다. 이 과정은 단순하지만 인적 오류가 발생하기 쉽고, 배포 속도 또한 느렸습니다.
이를 개선하기 위해 GitHub Actions 기반 CI/CD 자동 배포 파이프라인을 구축했습니다. 이 글에서는 그 과정과 주요 설정 방법을 공유합니다.

 

2. CI/CD란 무엇인가?

CI/CD(Continuous Integration / Continuous Deployment) 는
개발자가 작성한 코드를 자동으로 빌드, 테스트, 배포하는 일련의 자동화 프로세스입니다.

• CI (지속적 통합)
  코드 변경 시 자동으로 테스트 및 빌드가 수행되어 문제를 조기에 발견함.
• CD (지속적 배포)
  테스트를 통과한 코드가 자동으로 서버나 클라우드 환경(GCP, AWS 등)에 배포됨.

이 두 단계를 통해 개발자는 “코드 작성에만 집중”할 수 있고,
운영 환경은 항상 최신 상태를 유지하게 됩니다.

 

3. 사용한 도구와 환경

구성 요소 사용 기술

소스 관리	GitHub
CI/CD 도구	GitHub Actions
배포 환경	Google Cloud Run
컨테이너 빌드	Docker
프레임워크	Django (Python 3.12)

 

4. 파이프라인 구조

자동화 파이프라인은 다음 두 단계로 구성됩니다.

1. Build & Test 단계 (CI)
   • develop 브랜치에서 변경 발생 시,
     Django 앱을 빌드하고 기본 테스트(python manage.py check) 수행.
   • 문제가 없으면 Docker 이미지를 생성.
2. Deploy 단계 (CD)
   • main 브랜치로 병합되면,
     GitHub Actions가 GCP 서비스 계정 키(GCP_SA_KEY)를 이용해 Cloud Run에 자동 배포.

 

아래의 방향성을 가져갑니다.

 

Develop branch → GitHub Actions (Build/Test)
                    ↓
                Docker Build
                    ↓
Main branch merge → GCP Cloud Run Deploy

 

5. 주요 설정 파일

name: PDFmask CI/CD Pipeline

on:
  push:
    branches:
      - main

jobs:
  build:
    name: Build & Test Django App
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: python manage.py check

  deploy:
    name: Deploy to GCP (CD)
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Authenticate to Google Cloud
        uses: google-github-actions/auth@v1
        with:
          credentials_json: ${{ secrets.GCP_SA_KEY }}
      - name: Deploy to Cloud Run
        uses: google-github-actions/deploy-cloudrun@v1
        with:
          service: pdfmask-service
          region: asia-northeast3
          image: gcr.io/${{ secrets.GCP_PROJECT_ID }}/pdfmask:latest

 

 

6. 시뮬레이션

실제 프로젝트에서의 브랜치 구조와 CI/CD 흐름

보통 하나의 프로젝트는 다음과 같은 브랜치 구조로 운영됩니다.
Main (배포용) → Develop (테스트용) → Feature (기능 개발용) → 기타 개인 작업 브랜치

 

1. Feature 브랜치 – 기능 개발 단계

새로운 기능이나 수정 사항을 구현할 때는 개인 브랜치에서 개발을 진행합니다.
구현이 완료되면 로컬 서버에서 테스트를 수행하기 위해 해당 기능을 feature 브랜치에 merge 합니다.
이 단계에서는 실험적인 수정도 자유롭게 가능합니다.

 

2. Develop 브랜치 – 통합 테스트 단계

feature에서 기능이 정상적으로 동작하면 develop 브랜치로 병합하여 코드를 최신화합니다.
develop은 실제 서비스용은 아니지만,
GCP 테스트 인스턴스에 임시로 배포하여 실환경과 유사한 조건에서 문제를 검증합니다.
이를 통해 사용자 환경에서 발생할 수 있는 오류를 사전에 점검합니다.

 

3. Main 브랜치 – 실제 배포 단계

develop에서 기능 검증이 완료되면 main 브랜치에 병합합니다.
main 브랜치에 코드가 반영되면 자동으로 Docker 이미지를 생성하고 GCP에 배포되어,
즉시 서비스에서 새로운 기능이 사용 가능해집니다.

 

이 과정을 통해 개발자는 수동 배포 과정에서 발생하는 시간 낭비를 줄이고,
코드 품질 개선과 기능 개발에 더 집중할 수 있는 환경을 구축하게 됩니다.

 

 

이렇게 실제로 로컬에서 돌리다가 GCP 테스트 인스턴스에서 테스트 했을 때 문제가 발생했던 내용입니다. 이걸 바로 Main에 배포하게 되면 문제가 발생하기 때문에 Develop 브랜치에서 오류를 찾아 문제를 해결 후 코드 검토를 받고 Main에 올릴 수 있게 됩니다!!

 

물론 작업 과정은 프로젝트 하는 팀원에 따라 달라질 수 있습니다. 하지만 CI/CD는 개발자의 수동 배포 과정을 줄이고 코드 품질 개선과 기능 개발에 더 집중한다는 공통점만 알고 있으시면 될 것 같습니다!

 

틀린 내용이나 궁금한 사항이 있으시다면 적어주시면 감사하겠습니다!