Belajar Vitess - CI/CD & Release Management

#Pendahuluan

Sampai di sini kalian sudah tahu cara mengoperasikan Vitess — tapi bagaimana mengirim perubahan ke produksi secara aman dan berulang? Episode 19 membahas disiplin pengiriman: konfigurasi dikelola di git, perubahan divalidasi di pipeline, skema di-versioned, dan upgrade dijalankan bergiliran tanpa downtime.

Roadmap episode 19: GitOps untuk konfigurasi, pipeline CI/CD, versioning schema changes, rolling upgrades, lalu testing di staging. Ini episode yang mengubah "operator yang andal" menjadi "tim yang konsisten".

#GitOps untuk Konfigurasi Vitess

Prinsip GitOps: git adalah satu-satunya sumber kebenaran. Semua konfigurasi — values.yaml helm, VSchema, DDL schema, skrip vtctlclient — disimpan di repo. Perubahan tidak diterapkan langsung ke cluster, tapi lewat pull request, review, lalu pipeline.

Struktur repo yang disarankan:

vitess-config/
  environments/
    staging/
      values.yaml
      vschema.json
      schema/
        001_init.sql
        002_add_users.sql
    production/
      values.yaml
      vschema.json
      schema/
        001_init.sql
        002_add_users.sql
  scripts/
    apply-vschema.sh
    apply-schema.sh

environments/staging dan environments/production memisahkan konfigurasi per lingkungan — tidak ada alasan untuk tidak sinkron antara staging dan production.

Setiap perubahan harus lewat review, bukan langsung ke cluster. Aturan ini menjaga agar tidak ada satu orang pun yang bisa mengubah produksi tanpa dilihat rekan tim.

#Pipeline CI/CD

Pipeline CI menjalankan validasi sebelum perubahan diterapkan. Tahapan yang biasa:

• Lint dan validasi YAML — pastikan semua file bisa di-parse.
• Validasi VSchema — cek dengan alat Vitess sebelum apply.
• Dry-run helm — verifikasi manifest yang akan diterapkan.
• Test terintegrasi — jalankan migrasi di database test.

Contoh tahap validasi di pipeline:

jobs:
  validate:
    steps:
      - run: helm template vitess vitess/vitess -f environments/staging/values.yaml
      - run: vtctlclient ApplyVschema -vschema_file=environments/staging/vschema.json --dry-run users
      - run: mysql -h 127.0.0.1 -P 15306 < environments/staging/schema/002_add_users.sql

ApplyVschema ... --dry-run memvalidasi VSchema tanpa menerapkannya, dan perintah mysql menjalankan skema di database test. Pipeline yang gagal menghentikan pengiriman — persis seperti test merah menghentikan merge.

#Versioning Schema Changes

Skema database harus di-versioned seperti kode. Pola yang umum: direktori migrasi bernomor berurutan, diterapkan sekali, dan tidak boleh diubah setelah diterapkan.

ALTER TABLE users ADD COLUMN created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

Perintah ALTER TABLE users ADD COLUMN created_at berada di file 003_add_created_at.sql. Untuk tabel besar, jangan lupa pakai online schema change (episode 10) — pipeline memutuskan apakah perubahan ringan (DDL langsung) atau besar (online).

#Rolling Upgrades

Upgrade komponen Vitess — VTGate, VTTablet, atau versi Vitess itu sendiri — dilakukan bergiliran agar tidak ada downtime. Strateginya:

1. Upgrade VTGate dulu (stateless, aman diganti).
2. Upgrade VTTablet satu per satu, menunggu tiap tablet sehat sebelum lanjut.
3. Pantau metrik setiap tahap sebelum memindahkan beban.

Helm menangani rolling update otomatis untuk Deployment:

helm upgrade vitess vitess/vitess -f values.yaml \
  --namespace vitess --version 21.0.0
kubectl rollout status deploy/vtgate -n vitess

helm upgrade mengganti Pod VTGate secara bergiliran, dan kubectl rollout status menunggu sampai upgrade selesai. Untuk VTTablet, pastikan strategy di StatefulSet aman dan pantau replikasi selama proses.

#Testing di Staging

Tidak ada perubahan produksi yang aman tanpa diuji di staging yang menyerupai produksi. Poin yang harus disiapkan di staging:

• Skala menyerupai: jumlah shard dan replika yang sama dengan produksi.
• Data realistik: sampel data dengan volume dan pola akses mendekati produksi.
• Workload nyata: jalankan replikasi traffic produksi atau benchmark yang mewakili.
• Gerbang promosi: staging lulus, baru produksi.

#Penutup

Pada episode 19 ini kalian sudah memahami pengiriman perubahan Vitess secara terstruktur: GitOps dengan git sebagai sumber kebenaran, pipeline CI/CD yang memvalidasi konfigurasi dan skema, versioning schema changes, rolling upgrades tanpa downtime, serta testing di staging sebelum promosi.

Inti yang harus dibawa pulang:

• Git adalah satu-satunya sumber kebenaran untuk konfigurasi Vitess.
• Setiap perubahan lewat PR dan review, bukan diterapkan langsung.
• Pipeline harus memvalidasi YAML, VSchema, dan skema sebelum apply.
• Skema di-versioned dengan migrasi bernomor yang tidak boleh diubah setelah dipakai.
• Rolling upgrade: VTGate dulu, lalu VTTablet satu per satu.
• Staging yang menyerupai produksi adalah gerbang wajib sebelum rilis.

Di episode 20 berikutnya kita hadapi skenario terburuk: disaster recovery dan business continuity — strategi backup penuh dan parsial, recovery drills, data integrity checks, dan penanganan region outage dengan failover rehearsal. Sampai jumpa!