Belajar Microservices - CI/CD & GitOps per Layanan

#Pendahuluan

Semua episode sebelumnya membangun satu layanan — kini tiba saatnya mengotomasi ratusan deploy setiap minggu untuk tujuh layanan. Kalau deploy manual, microservices adalah beban; kalau terotomasi, ia menjadi keunggulan. Episode ini menyatukan semuanya: pipeline CI, image, dan cara manifest sampai ke cluster.

Mengapa episode ini penting? Karena "microservices" dan "CI/CD" adalah pasangan yang tak terpisahkan — kecepatan deploy per layanan adalah alasan utama arsitektur ini dipilih. Satu pipeline yang jelek membuat tujuh layanan lebih susah di-deploy daripada satu monolith.

#Pipeline GitHub Actions (Per Service)

Pipeline per layanan mengikuti urutan quality gate yang kita tetapkan di episode 22:

name: auth-service CI/CD
 
on:
  push:
    branches: [main]
    paths:
      - 'services/auth-service/**'
      - 'packages/shared-types/**'
      - 'packages/client-db/**'
      - '.github/workflows/auth-service.yml'
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run lint --cwd services/auth-service
      - run: bun test --cwd services/auth-service
      - run: bun run test:contract --cwd services/auth-service
      - run: bun run test:integration --cwd services/auth-service # Testcontainers
 
  build-push:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: services/auth-service
          file: services/auth-service/Dockerfile
          push: true
          tags: ghcr.io/tokokita/auth-service:${{ github.sha }}
 
  deploy:
    needs: build-push
    runs-on: ubuntu-latest
    steps:
      - run: argocd app sync auth-service  # (episode GitOps di bawah)

Kunci pertama: path-filtering. Karena monorepo, workflow di-trigger hanya saat direktori service atau shared package yang dipakainya berubah. Mengubah notification-service tidak me-rebuild auth-service — CI tetap cepat walau repo besar.

#Image Tag Semver

${{ github.sha }} sebagai tag memberi traceability ("commit mana yang menghasilkan image ini?"). Di produksi, gunakan tag semver dari semantic-release (v1.4.2) sebagai tag yang stabil dan mudah di-rollback — sesuai catatan di episode 16.

#Deployment Strategy: Blue-Green & Canary

Rolling update (episode 17) aman dan otomatis. Dua strategi tambahan yang sering dipakai untuk layanan kritikal:

#Blue-Green

Dua environment identik: blue (lama) dan green (baru). Setelah green lolos smoke test, alihkan 100% trafik; blue disimpan untuk rollback cepat.

• Kelebihan: rollback instan (balik trafik).
• Kekurangan: biaya dua kali kapasitas.

#Canary

Trafik diarahkan bertahap: 5% → 25% → 100% ke versi baru — sambil memantau error rate & latency. Jika metrik jelek, hentikan dan balik.

# Argo Rollouts: analyser memutuskan lanjut/rollback dari metric Prometheus
canary:
  steps:
    - setWeight: 5
    - pause: { duration: 10m }     # amati error rate
    - setWeight: 25
    - pause: { duration: 10m }
    - setWeight: 100

Canary lebih hemat resource daripada blue-green dan memberi sinyal data sebelum semua trafik — combo paling populer di produksi 2026.

#GitOps: Manifest = Sumber Kebenaran

GitOps mengubah repo manifest menjadi satu-satunya cara cluster berubah. Argo CD membandingkan state yang diinginkan (manifest di git) dengan state nyata (cluster) dan melakukan sync otomatis:

push manifest → repo git → Argo CD detect drift → sync → cluster sesuai git
rollback = revert commit manifest (bukan keluar dari cluster)

Keuntungan terbesarnya: audit trail. Setiap perubahan cluster tercatat sebagai commit — "siapa mengubah apa, kapan" — dan rollback adalah operasi git yang biasa. Tidak ada lagi konfigurasi liar yang diterapkan manual via kubectl run --image=... --from-literal.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tokokita
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/tokokita/infra-gitops
    path: overlays/production
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: tokokita
  syncPolicy:
    automated:
      selfHeal: true   # cluster dikembalikan ke git bila drift

#Migrasi Konfigurasi: Secrets dan Environments

#Secrets via External Secrets

Manifest GitOps tidak boleh memuat Secret (base64 bukan enkripsi). Pakai referensi ExternalSecret (episode 19) — nilai ditarik runtime dari Vault/AWS. Git tetap bersih, rotation tidak memicu pull-request manifest.

#Environment Promotion

Pola tiga lingkungan tokokita:

dev      (Compose, semua service, developer loop cepat)
  ↓ push branch feature → preview / lingkungan dev otomatis
staging  (k3d cluster asli + Argo CD, contract & e2e, mirip produksi)
  ↓ merge ke staging → deploy staging → test
production (cluster produksi, ingress TLS, SLO aktif)
  ↓ merge ke main + tag semver → deploy produksi

Arah alirannya satu arah, doorstep di tiap level tertulis sebagai workflow. Di level produksi, deploy bisa diposisikan manual-approve oleh pemilik layanan.

#Penutup

Episode 23 menuntaskan otomasi tokokita:

• GitHub Actions per service + path-filtering (monorepo) → CI cepat; urutan lint→test→contract→integration→image→deploy.
• Image tag: git sha untuk traceability; semver untuk produksi.
• Deploy: blue-green (rollback instan) vs canary (bertahap + metric analysis).
• GitOps Argo CD: manifest = sumber kebenaran; rollback = revert commit; selfHeal.
• Secrets: External Secrets (referensi, bukan salinan); environment promotion: dev → staging → production.

Di episode 24 selanjutnya, kita menutup pertanyaan-pertanyaan produksi: production checklist & cost — runbook dan rollback per service, SLI/SLO (99.9% API vs 99.95% order), ekonomi cost per service, dan DR/backup lengkap dengan restore test rutin. Sampai jumpa di episode 24!