Belajar 9router - CI/CD & Deployment Automation

#Pendahuluan

Di episode 18 kalian mempelajari cara gateway bertahan ketika provider tumbang: failover, backup route, degraded mode, dan circuit breaker. Namun bertahan dari kegagalan hanyalah satu sisi. Sisi lainnya adalah mencegah perubahan yang salah masuk ke produksi — karena salah ketik nama model, policy rate limit yang terlalu rendah, atau provider yang belum dikonfigurasi bisa memicu insiden yang sama parahnya dengan outage provider.

Episode 19 membawa konfigurasi 9router ke jalur engineering yang benar: CI/CD dan deployment automation. Roadmap-nya tiga bagian: memvalidasi konfigurasi secara otomatis di CI, men-deploy perubahan route tanpa downtime, dan melakukan staged rollout policy baru yang bisa dihentikan kapan saja.

#Mengapa Route Change Perlu CI/CD

Konfigurasi routing bukan file statis yang berubah sebulan sekali. Di dunia nyata ia berubah tiap hari: model baru dirilis, harga provider berubah, policy per customer digeser. Jika setiap perubahan dikerjakan manual — edit YAML di server, restart, berdoa — maka tinggal menunggu waktu sampai kesalahan kecil masuk produksi.

CI/CD memindahkan semua itu ke jalur otomatis. Prinsipnya tiga: validasi sebelum merge, deploy yang konsisten dan bisa diulang, serta rollback yang cepat. Tidak ada satu pun yang bisa dilakukan dengan andal secara manual dalam jangka panjang.

#Validasi Konfigurasi di CI

Lapisan pertama adalah validasi otomatis. Setiap pull request yang menyentuh file konfigurasi 9router harus lolos pemeriksaan sebelum di-merge:

• Syntax check — file YAML valid dan bisa dibaca 9router.
• Schema validation — semua field sesuai skema: nama route unik, provider dikenal, model tersedia.
• Dry run — simulasi routing beberapa request sample untuk memastikan rule matching bekerja seperti diharapkan.

CLI 9router menyediakan perintah untuk semuanya:

9router validate routes.yaml
9router validate routes/ --strict
9router test run sample-requests.json --config routes.yaml

--strict menaikkan semua warning menjadi error — cocok untuk konfigurasi yang akan menuju produksi. Perintah test run menjalankan kumpulan request sample dan membandingkan keputusan routing dengan ekspektasi; seperti unit test untuk konfigurasi.

Untuk memastikan seluruh anggota tim menjalankan validasi yang sama, pasang git hook lokal lewat file konfigurasi hooks:

hooks:
  - id: 9router-validate
    files: \.(yaml|yml)$
    command: 9router validate
    stages: [pre-commit, pre-push]

Setiap perubahan YAML akan divalidasi otomatis sebelum commit dan sebelum push — kesalahan terhenti di meja pengembang, bukan menunggu ditemukan reviewer.

#Pipeline Deploy Otomatis

Setelah validasi lolos dan pull request di-merge, pipeline deploy mengambil alih. Workflow berikut berjalan di GitHub Actions: validasi, deploy ke staging, smoke test, lalu deploy ke produksi.

name: Deploy Routes
on:
  push:
    paths:
      - "routes/**"
      - ".github/workflows/deploy-routes.yml"
 
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: 9router validate routes/ --strict
      - run: 9router test run sample-requests.json
 
  deploy-staging:
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - run: 9router deploy routes/ --env staging
 
  smoke-test:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: 9router smoke-test --env staging
 
  deploy-production:
    needs: smoke-test
    runs-on: ubuntu-latest
    steps:
      - run: 9router deploy routes/ --env production

Pipeline ini hanya terpicu ketika file di direktori routes berubah — bukan setiap commit pada kode aplikasi. Setiap job bergantung pada job sebelumnya, sehingga konfigurasi yang buruk berhenti lebih awal. Kredensial provider tidak pernah ditulis di file ini; key disuntikkan dari secret yang disimpan di GitHub Actions. Model staging dan produksi juga tidak harus sama — bandingkan keduanya sebelum memutuskan merge dengan 9router diff staging production.

#Staged Rollout Policy Baru

Men-deploy langsung ke 100 persen traffic adalah kebiasaan berbahaya. Policy baru — menaikkan limit token, mengganti model utama, atau mengubah matching — bisa berperilaku tidak terduga pada traffic nyata. Staged rollout menyelesaikan ini dengan membagi traffic bertahap.

Konsepnya mirip canary: kirim 10 persen traffic dulu, pantau metrik, naikkan ke 50 persen, lalu 100 persen. Di 9router, ini dikelola lewat konfigurasi rollout:

rollout:
  name: migrate-chat-to-gpt-4o
  stages:
    - weight: 10
      duration: 15m
    - weight: 50
      duration: 30m
    - weight: 100
      duration: infinite
  auto_advance: true
  abort_on_error: true

weight menunjukkan persentase traffic yang diarahkan ke versi baru. auto_advance membuat 9router menaikkan bobot otomatis mengikuti jadwal, sementara abort_on_error menghentikan rollout dan kembali ke versi lama begitu error rate melewati ambang. Dengan cara ini setiap tahap bisa diamati sebelum pembagian diperbesar.

#Rollback Otomatis dan Manual

Tidak semua masalah langsung tertangkap di menit-menit awal. Terkadang error rate baru menonjol setelah beberapa menit. Karena itu strategi rollback harus siap dua jalur.

Rollback otomatis dipicu kondisi yang terdefinisi — misalnya error rate di atas 5 persen atau latency p95 yang melonjak. Saat terpicu, 9router mengembalikan konfigurasi ke versi terakhir yang sehat:

9router deploy routes/ --env production --previous
9router rollout abort migrate-chat-to-gpt-4o

Versi konfigurasi disimpan seperti versi kode — setiap deploy menghasilkan revisi bernomor. Opsi --previous mengembalikan ke revisi sebelumnya, dan abort menghentikan rollout yang sedang berjalan. Tim yang mampu rollback dalam hitungan menit jauh lebih berani bereksperimen, karena setiap perubahan punya jalan pulang.

#Penutup

Episode 19 mengubah konfigurasi 9router dari "file yang di-edit di server" menjadi artefak yang diuji, di-review, dan di-deploy seperti kode: validasi otomatis di CI, pipeline berjenjang dari staging ke produksi, staged rollout dengan bobot traffic, dan strategi rollback dua jalur.

Inti yang harus dibawa pulang:

• Validasi di CI menghentikan konfigurasi rusak sebelum masuk produksi, bukan setelahnya.
• Pipeline berjenjang memberikan kepercayaan sebelum traffic nyata terpengaruh.
• Staged rollout memungkinkan perubahan routing diamati bertahap, bukan dilompati sekaligus.
• Rollback otomatis dan manual sama-sama wajib; keduanya butuh versi konfigurasi yang tercatat.
• Konfigurasi yang teruji dan bisa di-rollback membuat tim berani bergerak cepat.

Di episode 20 kita memanfaatkan semua otomasi itu dengan mata yang lebih tajam: observability at scale — dashboard metrik route, model, dan tool; deteksi anomali pada keputusan routing; serta alerting untuk route yang gagal atau terdegradasi. Sampai jumpa!