Belajar WebSocket - CI/CD Pipeline

#Pendahuluan

Mendeploy dengan cara manual adalah undangan bencana: ada langkah yang terlewat, environment yang tidak sinkron, atau kode yang tidak teruji berjalan di production. CI/CD mengubah itu menjadi alur otomatis: setiap perubahan teruji, lalu terdeploy tanpa tangan manusia.

Episode 30 membahas CI/CD pipeline untuk aplikasi WebSocket: apa yang dilakukan continuous integration, bagaimana continuous deployment bekerja dengan image Docker, contoh pipeline GitHub Actions, dan strategi rilis seperti blue-green dan canary.

#Continuous Integration

#Pintu Masuk Kualitas

Setiap perubahan kode melewati serangkaian pemeriksaan otomatis sebelum dianggap layak.

Perintah dasar di CI

bun install --frozen-lockfile
bun run lint
bun run test
bun run build

bun run test menjalankan semua test dari episode 26. CI yang kuat memblokir merge jika ada test gagal, lint error, atau build rusak — sehingga bug ditemukan dalam menit, bukan setelah sampai production.

#Cakupan CI untuk WebSocket

Selain lint dan build, pipeline WebSocket sebaiknya menjalankan:

Unit dan integration test: logika server dan interaksi klien-server.
Load test ringan: pastikan perubahan tidak menggandakan latensi.
Security scan: pindai dependency untuk CVE.
Type check: kode TypeScript terverifikasi sebelum dibangun.

#Continuous Deployment

#Image sebagai Artefak

CD membangun image Docker, mengirimnya ke registry, lalu mendeploy ke lingkungan target.

Build dan push image

docker build -t registry.example.com/ws-server:1.4.0 .
docker push registry.example.com/ws-server:1.4.0

Image dengan tag versi adalah artefak yang immutable dan bisa di-rollback. Tag latest tidak disarankan untuk production karena mengaburkan versi mana yang sebenarnya berjalan.

#Rollout di Kubernetes

Deploy image baru ke cluster, biarkan Kubernetes menangani rollout.

Update image di cluster

kubectl set image deployment/ws-server \
  ws-server=registry.example.com/ws-server:1.4.0

kubectl set image memicu rolling update. Health check dari episode 28 menentukan apakah pod baru dianggap sehat sebelum yang lama dihentikan.

#Pipeline GitHub Actions

#Workflow Contoh

GitHub Actions mengotomatisasi seluruh alur dalam satu file.

Workflow CI/CD WebSocket

name: deploy
 
on:
  push:
    branches: [main]
 
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v1
      - run: bun install --frozen-lockfile
      - run: bun run lint
      - run: bun run test
 
  deploy:
    needs: ci
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: registry.example.com
          username: ${{ secrets.REGISTRY_USER }}
          password: ${{ secrets.REGISTRY_PASS }}
      - run: docker build -t registry.example.com/ws-server:1.4.0 .
      - run: docker push registry.example.com/ws-server:1.4.0

needs: ci memastikan job deploy hanya berjalan jika ci lolos. Secret registry disimpan di GitHub Secrets, bukan ditulis di file.

#Strategi Deployment

#Blue-Green

Blue-green menjalankan dua lingkungan: versi lama (blue) dan versi baru (green).

Alihkan traffic ke green

kubectl apply -f deployment-green.yaml
kubectl rollout status deployment/ws-server-green
kubectl set service selector ...

Saat green siap dan health check lolos, traffic dialihkan sekaligus. Rollback semudah mengembalikan selector ke blue. Konsekuensinya butuh kapasitas dua kali lipat selama transisi.

#Canary

Canary melepas versi baru ke sebagian kecil traffic dulu.

Service mesh canary split

spec:
  http:
    - route:
        - destination:
            subset: stable
          weight: 90
        - destination:
            subset: canary
          weight: 10

weight: 10 mengarahkan 10 persen koneksi ke versi canary. Pantau error rate dan latensi (episode 18); jika sehat, naikkan beratnya perlahan hingga 100 persen. Canary lebih aman untuk koneksi WebSocket karena kegagalan hanya memengaruhi sebagian kecil pengguna.

#Connection Draining

Koneksi WebSocket yang panjang membuat deployment lebih rumit: pod lama tidak bisa langsung dimatikan. Kunci suksesnya adalah connection draining: saat pod menerima sinyal terminasi, ia berhenti menerima koneksi baru, melepas koneksi lama dengan kode 1001 (episode 15), dan keluar setelah semuanya pindah. Tanpa ini, pengguna yang sedang terhubung terputus di tengah aktivitas.

#Penutup

Episode 30 mengotomatisasi perjalanan kode: CI memblokir kualitas buruk di pintu masuk, CD mengirim artefak teruji ke production, dan strategi rilis menjaga pengguna tetap aman selama perpindahan.

Inti yang harus dibawa pulang:

CI menjalankan lint, test, build, dan security scan di setiap perubahan.
Image Docker dengan tag versi adalah artefak yang immutable.
GitHub Actions merangkai CI dan CD dalam satu workflow.
Blue-green mengganti versi sekaligus dengan rollback cepat.
Canary melepas versi baru ke sebagian traffic dan mengamati.
Connection draining menghindari putusnya koneksi WebSocket saat deploy.

Di episode 31 berikutnya kita membahas infrastructure as code: Terraform untuk cloud, Helm dan GitOps dengan ArgoCD, serta pengelolaan secret dan feature flag.