CI/CD 완전 가이드

1. CI/CD란?

CI/CD는 코드 변경 사항을 빠르고 안전하게 프로덕션까지 전달하기 위한 자동화 프랙티스입니다. 사람이 수동으로 빌드·테스트·배포하는 과정을 파이프라인으로 대체합니다.

2. 파이프라인 단계

전형적인 파이프라인은 아래 단계를 순서대로 거치며, 각 단계가 실패하면 다음 단계로 진행하지 않습니다.

3. GitHub Actions 기초

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run buildyaml

4. 빌드 & 테스트 파이프라인

name: Test

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]   # 여러 버전에서 동시 테스트
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node-version }}
          path: coverage/
        if: always()yaml

5. Docker 이미지 빌드 & 레지스트리 푸시

name: Build & Push

on:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  docker:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write   # GHCR 푸시 권한
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:${{ github.sha }}
            ghcr.io/${{ github.repository }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=maxyaml

Dockerfile 작성 규칙과 멀티스테이지 빌드는 Docker 가이드를 참고하세요.

6. Kubernetes 배포 자동화

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: azure/setup-kubectl@v4

      - name: Configure kubeconfig
        run: echo "${{ secrets.KUBECONFIG_B64 }}" | base64 -d > kubeconfig

      - name: Rolling update
        run: |
          export KUBECONFIG=kubeconfig
          kubectl set image deployment/myapp app=ghcr.io/${{ github.repository }}:${{ github.sha }}
          kubectl rollout status deployment/myapp --timeout=120syaml

7. GitOps (ArgoCD)

GitOps는 "배포하고 싶은 상태"를 Git 저장소에 선언하고, 클러스터 내부의 컨트롤러가 그 상태와 실제 상태를 지속적으로 동기화하는 방식입니다. CI가 클러스터에 직접 kubectl apply하는 대신, Git에 매니페스트만 반영하면 배포가 완료됩니다.

# ArgoCD Application 정의
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/myapp-manifests
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # Git에서 삭제된 리소스는 클러스터에서도 제거
      selfHeal: true     # 수동 변경을 감지하면 Git 상태로 자동 복구yaml

8. 배포 전략

# Canary 예시 — Ingress 트래픽 분할 (nginx-ingress annotation)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"   # 신버전으로 5% 트래픽
spec:
  ingressClassName: nginx
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-v2
            port: { number: 80 }yaml

9. 다음 단계