Belajar ML Engineer - CI/CD untuk ML

#Pendahuluan

Setelah di episode 9 kita mengemas model ke container dan menyajikannya sebagai service, muncul pertanyaan yang sama seperti software engineering klasik: bagaimana semua perubahan ini dikelola, diuji, dan dideploy secara otomatis dan aman? Jawabannya adalah CI/CD — dan untuk ML, jawabannya sedikit lebih rumit karena "perubahan" di ML bisa datang dari kode, data, maupun model.

CI/CD untuk ML bukan sekadar "jalankan test lalu deploy". Ada gerbang khusus ML yang wajib ada: data validation (apakah data baru masih konsisten?), model evaluation gate (apakah model baru lebih baik dari yang live?), dan drift check sebelum deploy. Episode ini membangun pipeline CI/CD ML yang lengkap dan bisa dipakai nyata.

#Konsep Dasar CI/CD

CI (Continuous Integration): setiap perubahan (kode, data, config) memicu build + test otomatis.
CD (Continuous Deployment/Delivery): perubahan yang lolos di-deploy ke staging/produksi, secara otomatis atau dengan persetujuan.

Untuk ML, CI menguji kode dan pipeline; CD menangani training ulang dan deployment model. Dua alur ini sering disebut CI (kode) dan CT/CD (training & deployment).

#Pipeline CI dengan GitHub Actions

.github/workflows/ml-ci.yml

name: ML CI
on:
  pull_request:
    paths:
      - "src/**"
      - "tests/**"
      - "requirements*.txt"
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install deps
        run: pip install -r requirements.txt
      - name: Lint
        run: ruff check src tests
      - name: Unit tests
        run: pytest tests/ -q

Setiap PR yang menyentuh kode ML memicu: lint, unit test, dan type check. Ini lapisan pertama pertahanan — menangkap typo dan transformasi yang salah sebelum sampai ke training.

#Gerbang Validasi Model (Model Validation Gates)

Bagian yang membedakan CI/CD ML dari CI/CD biasa. Sebelum model baru boleh ke produksi, ia harus melewati gerbang otomatis:

Job validasi model

  validate-model:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - name: Retrain dengan data tes kecil
        run: python -m src.train --max-samples 50000
      - name: Validasi data (schema, drift ringan)
        run: python -m src.validate_data --reference data/ref.parquet
      - name: Evaluasi vs baseline produksi
        run: python -m src.evaluate --vs production

Gerbang yang umum:

Gate	Apa yang dicek	Gagal jika
Data validation	Schema, tipe kolom, missing rate	Schema berubah tanpa izin
Eval gate	Metric model baru vs produksi	Tidak lebih baik dari baseline
Bias/fairness check	Performa per segmen	Segmen minoritas drop drastis
Explainability gate	Feature importance stabil	Fitur dominan berubah total

Konsep kuncinya: PR ML tidak cukup "code review" — butuh review hasil evaluasi. Model baru yang tidak lebih baik dari yang live harus ditolak pipeline, bukan dideploy.

#Pipeline Deployment

Saat merge ke main, pipeline deployment berjalan: train model, register ke registry, build image, deploy ke staging, lakukan smoke test, lalu promote ke produksi.

Pipeline deploy model

  deploy:
    runs-on: ubuntu-latest
    needs: validate-model
    steps:
      - name: Train & register
        run: python -m src.train --register
      - name: Build image
        run: docker build -t registry/churn-api:$GITHUB_SHA .
      - name: Deploy ke staging
        run: ./scripts/deploy.sh staging $GITHUB_SHA
      - name: Smoke test staging
        run: ./scripts/smoke_test.sh
      - name: Promote ke produksi
        run: ./scripts/deploy.sh production $GITHUB_SHA

#Strategi Rollback yang Aman

Tiga teknik yang wajib kalian kenal:

Blue/green: dua environment (blue = lama, green = baru); pindah trafik dengan switch, rollback = switch balik.
Canary: rilis ke sebagian kecil trafik dulu, amati metrik, lalu perluas — dengan rollback otomatis jika metrik turun.
Shadow deploy: traffic produksi diputar ke model baru secara paralel tanpa memengaruhi keputusan; hasilnya dibandingkan.

Kombinasi yang umum: canary di staging + blue/green di produksi, dipicu oleh evaluasi metrik yang terukur.

#Alur CI/CD ML Secara Utuh

100%

Important

Gerbang evaluasi hanya berguna jika metriknya dibandingkan terhadap kondisi nyata produksi, bukan sekadar threshold statis. Model yang "lebih baik di test set" tapi lebih buruk di segmen yang paling menguntungkan bisnis harus ditolak. Hubungkan gerbang CI ke metrik bisnis, bukan hanya ROC-AUC.

#Common Pitfalls

Pitfall	Dampak	Pencegahan
CI hanya code test, tanpa gate ML	Model jelek lolos ke produksi	Gerbang data + eval + fairness
Train di CI dengan data acak	Hasil tidak reproducible	Dataset ber-version, seed tetap
Deploy manual	Terlalu lama, rawan human error	Otomatisasi dengan strategi rollback
Tanpa canary	Regresi performa langsung ke semua user	Canary + metrik pembanding
Registry tidak diintegrasikan	Deploy versi salah	Deploy selalu dari registry, bukan file lokal

#Penutup

Pada episode 10 ini, kalian telah membangun otomasi penuh:

CI: lint, unit test, dan type check untuk setiap perubahan kode.
Gerbang validasi model: data validation, eval gate, bias check — model jelek ditolak otomatis.
CD: train → register → build → staging → smoke test → produksi.
Rollback aman: blue/green, canary, dan shadow deploy.

Di episode 11 selanjutnya kita akan membahas Model Monitoring & Drift — memantau data dan concept drift, metrik model di produksi, serta alerting yang membuat kalian tahu ada masalah sebelum pengguna mengeluh. Sampai jumpa di episode 11!