Belajar gRPC - CI/CD, GitOps & Production Deployment

#Pendahuluan

Menulis kontrak .proto dan menjalankan server lokal itu mudah. Tantangan sebenarnya dimulai saat service harus dibangun, diuji, dan dideploy secara otomatis oleh tim yang berbeda. Episode 17 membawa gRPC ke dunia CI/CD dan GitOps: pipeline yang mengompilasi .proto, menjalankan linting dan test kontrak, membangun image, lalu mendeploy ke Kubernetes dengan Git sebagai satu sumber kebenaran.

Tujuan akhirnya: setiap perubahan di repo berakhir sebagai service yang berjalan — tanpa klik manual dan tanpa konfigurasi yang hanya ada di kepala seseorang.

#Pipeline Build untuk Proto

#Tahapan Pipeline

Pipeline gRPC yang sehat punya lima tahap: lint (kualitas kontrak), generate (codegen), test (unit dan integration), build (image), dan publish. Definisi pekerjaan GitHub Actions untuk memvalidasi kontrak:

name: proto-ci
 
on:
  pull_request:
    paths: ["proto/**"]
 
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bufbuild/buf-setup-action@v1
      - run: buf lint
      - run: buf breaking --against https://github.com/org/contracts.git#branch=main
      - run: protoc -I proto \
          --go_out=gen --go_opt=paths=source_relative \
          proto/catalog/v1/product.proto

Perhatikan paths: ["proto/**"]: pipeline hanya berjalan saat kontrak berubah — hemat waktu untuk perubahan yang tidak relevan. Dua perintah buf memastikan kualitas dan kompatibilitas kontrak.

#Linting dengan buf

buf lint memastikan kontrak mengikuti konvensi — misalnya field enum berawalan nama enum, message memakai PascalCase, dan field proto3 memakai snake_case. Ini seperti ESLint untuk kontrak protobuf, dan menjadi pintu pertama di pipeline.

#Validasi Kontrak dengan Automated Test

#Breaking Change Detection

Perubahan kontrak yang melanggar kompatibilitas harus menggagalkan build, bukan menimbulkan insiden produksi. Perintah buf breaking membandingkan kontrak baru dengan versi di main:

buf breaking --against https://github.com/org/contracts.git#branch=main

buf breaking --against ... memeriksa aturan seperti "field tidak dihapus" dan "nomor field tidak dipakai ulang". Bila ada pelanggaran, pipeline gagal dengan pesan yang menunjukkan perubahan bermasalah.

#Contract Test Runtime

Selain lint, jalankan test yang benar-benar memanggil server. Pola paling kuat: spin up server nyata di pipeline, lalu verifikasi dengan grpcurl:

go run ./server &
sleep 2
grpcurl -plaintext localhost:50051 \
  catalog.v1.CatalogService/GetProduct \
  -d '{"id":"p-001"}' || exit 1
kill %1

Perintah grpcurl ... -d '{"id":"p-001"}' memverifikasi bahwa kontrak yang di-generate benar-benar bisa dijalankan. Kegagalan apapun — dari server yang error sampai kontrak yang tidak cocok — langsung terdeteksi di CI.

#Deploy dengan GitOps di Kubernetes

#Manifest dalam Git

Prinsip GitOps: seluruh state deployment disimpan sebagai file dalam Git, dan ada controller yang menyamakan cluster dengan Git. Manifest dasar service gRPC:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalog
spec:
  replicas: 3
  selector:
    matchLabels:
      app: catalog
  template:
    metadata:
      labels:
        app: catalog
    spec:
      containers:
        - name: catalog
          image: registry.example.com/catalog:v1.4.2
          ports:
            - containerPort: 50051
          env:
            - name: GRPC_PORT
              value: "50051"
          readinessProbe:
            exec:
              command: ["/bin/grpc_health_probe", "-addr=:50051"]
---
apiVersion: v1
kind: Service
metadata:
  name: catalog
spec:
  selector:
    app: catalog
  ports:
    - port: 50051
      targetPort: 50051

File YAML ini mendefinisikan Deployment dengan tiga replika dan Service untuk menemukannya. readinessProbe dari episode 15 memastikan hanya pod sehat yang menerima traffic. Image dipin dengan tag versi — v1.4.2 — sehingga selalu bisa di-rollback.

#ArgoCD sebagai Controller

Controller GitOps seperti ArgoCD memantau repo, membandingkannya dengan cluster, dan menyinkronkan bila ada perbedaan:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: catalog
spec:
  destination:
    namespace: catalog
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/org/catalog-deploy.git
    path: manifests
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

syncPolicy.automated dengan selfHeal: true membuat ArgoCD mengembalikan cluster ke state Git setiap ada drift. Rollback menjadi semudah mengembalikan commit — bukan menjalankan perintah rahasia di terminal.

#Penutup

Inti yang harus dibawa pulang:

• Pipeline gRPC: lint, generate, test, build, publish — berjalan otomatis di setiap perubahan kontrak.
• buf lint menjaga konvensi; buf breaking menggagalkan perubahan yang merusak kompatibilitas.
• Contract test dengan grpcurl membuktikan kontrak benar-benar berjalan.
• GitOps menyimpan seluruh state deployment sebagai file dalam Git.
• ArgoCD menyamakan cluster dengan Git dan melakukan self-heal saat terjadi drift.
• Deployment berversi memungkinkan rollback kapan saja.

Di episode 18 — episode terakhir — kita membahas ekosistem modern dan tooling stabil terbaru: buf, grpcurl, ghz, dan grpc-health-probe, fitur stabil terbaru protobuf dan gRPC seperti reflection dan xDS server-side load balancing, serta tren produksi: service mesh, API contract enforcement, dan observability pipeline.