CI/CD Tanpa Drama: Pipeline Sederhana tapi Andal

Daftar Isi

CI/CD yang Sehat Itu Seperti Apa?
Kesalahan Umum yang Bikin Pipeline Jadi Drama
Desain Pipeline Minimal: Build, Test, Scan, Deploy
Pisahkan Fast Feedback dan Deep Validation
Strategi Deploy Aman: Canary, Blue-Green, atau Rolling?
Rollback Plan yang Benar-Benar Bisa Dipakai
Metrik Pipeline yang Wajib Dipantau

CI/CD yang Sehat Itu Seperti Apa?

Setiap tim ngomong “kita sudah punya CI/CD”, tapi kualitasnya bisa sangat beda. Ada yang:

Build sering merah karena flakiness, tapi di-ignore.
Deploy otomatis “katanya” ada, tapi semua orang takut pencet tombol.
Pipeline butuh 30 menit lebih untuk hal-hal yang harusnya selesai dalam beberapa menit.

CI/CD yang sehat biasanya punya ciri:

Cepat untuk feedback harian: perubahan kecil bisa dapat hasil build + test dalam hitungan menit, bukan puluhan menit.
Stabil dan bisa dipercaya: kalau pipeline hijau, kemungkinan besar change aman; kalau merah, memang ada yang perlu diperbaiki (bukan sekadar test random).
Transparan: semua orang di tim bisa melihat apa yang sedang berjalan, siapa yang terakhir deploy, versi apa yang ada di environment tertentu.
Mudah dirawat: menambah step baru (misalnya security scan) tidak butuh ritual besar; konfigurasi tidak penuh saling ketergantungan yang misterius.

Target artikel ini: menunjukkan cara mendesain pipeline yang cukup sederhana untuk dijalankan tim kecil–menengah, tapi tetap andal dan bisa berkembang seiring kebutuhan.

Kesalahan Umum yang Bikin Pipeline Jadi Drama

Beberapa pola yang sering membuat pipeline jadi sumber stres:

Semua test digabung jadi satu tahap panjang
Unit test, integration test, end-to-end, lint, security scan… semua dijalankan berurutan dalam satu job. Akibatnya:
- Waktu feedback sangat lama.
- Sulit tahu bagian mana yang sebenarnya sering gagal.
Environment build tidak deterministik
- Mengandalkan state di runner (cache yang tidak jelas, tool versi random).
- Susah direproduksi di lokal.
Tidak ada pemisahan antara build dan deploy
- “Deploy” berarti build ulang langsung dari branch yang sedang jalan.
- Tidak ada artefak yang jelas yang bisa dilacak (image, zip, dsb).
Terlalu banyak conditional path yang rumit
- YAML penuh if/when yang sulit diikuti.
- Sulit menjelaskan ke engineer baru bagaimana alur dari PR sampai production.
Tidak ada rollback yang jelas
- Kalau ada masalah, solusinya “hotfix secepat mungkin” atau “rollback manual di server”.

Menghindari jebakan ini dimulai dari desain pipeline minimalis dengan alur yang mudah dijelaskan dalam satu diagram sederhana.

Desain Pipeline Minimal: Build, Test, Scan, Deploy

Sebagai baseline, pipeline yang sehat biasanya punya empat tahap utama:

Build
- Compile/bundle aplikasi.
- Bangun image/container atau artefak yang akan dideploy.
- Hasilnya: artefak versi tertentu yang bisa dilacak (misalnya Docker image tag, file release).
Test
- Minimal: unit test + integration test tingkat dasar.
- Idealnya paralel dengan linting.
Scan
- Security scan (dependency, image).
- Static analysis yang lebih berat bisa ditempatkan di tahap ini atau terpisah.
Deploy
- Mengambil artefak dari tahap Build (bukan build ulang).
- Deploy ke environment (staging/production) dengan strategi yang jelas (dibahas di bawah).

Contoh pseudo-pipeline:

jobs:
  build:
    # build dan publish image

  test:
    needs: build
    # jalankan unit/integration test pakai image/dokumen dari build

  scan:
    needs: build
    # jalankan security scan pada image/dokumen yang sama

  deploy:
    needs: [test, scan]
    # deploy hanya jika test & scan hijau

Kunci penting:

Artefak yang sama dipakai di test, scan, dan deploy → mengurangi risiko “yang dites dan yang dideploy beda”.
Tahap bisa berkembang (misalnya tambah job e2e terpisah) tanpa mematahkan struktur dasar.

Pisahkan Fast Feedback dan Deep Validation

Tidak semua check harus dijalankan di setiap push. Kalau semua hal berat dipaksa jalan terus, developer akan bosan menunggu pipeline dan mulai meng-ignore hasilnya.

Pisahkan:

Fast feedback (menit)
- Lint.
- Unit test cepat.
- Build dasar.
- Tujuan: memberi sinyal cepat saat kamu buka PR atau push perubahan kecil.
Deep validation (puluhan menit, bisa async)
- Integration test yang berat.
- End-to-end test yang bergantung pada banyak service.
- Security scan menyeluruh, SCA, SAST yang memakan waktu.

Beberapa strategi:

Jalankan fast feedback di setiap push ke branch feature & PR.
Jalankan deep validation:
- Di merge ke main.
- Atau dijadwalkan (nightly) untuk suite yang sangat berat.

Dengan pola ini, developer:

Tetap mendapat feedback cepat untuk hal-hal yang mereka ubah.
Tetap terlindungi oleh validasi mendalam yang berjalan di jalur rilis utama.

Strategi Deploy Aman: Canary, Blue-Green, atau Rolling?

Setelah build & test beres, pertanyaan berikutnya: bagaimana cara merilis tanpa bikin user jadi tester utama?

Tiga pola yang umum:

Rolling deploy
- Instance lama diganti bertahap oleh versi baru.
- Simpel dan didukung banyak platform (Kubernetes, ECS, dsb).
- Risiko: jika ada bug, sebagian user sudah terkena sebelum kamu sadar.
Blue-Green deploy
- Dua environment paralel: blue (aktif) dan green (baru).
- Deploy ke green, lakukan smoke test, lalu switch traffic.
- Rollback relatif mudah: kembalikan traffic ke environment sebelumnya.
- Butuh resource lebih (dua environment aktif).
Canary deploy
- Rilis ke sebagian kecil traffic dulu (misalnya 5–10%).
- Pantau metric (error rate, latency, business metric).
- Jika aman, tingkatkan persentase sampai 100%.

Untuk banyak tim kecil–menengah, pola hybrid sering dipakai:

Rolling deploy + sedikit canary di depan (misalnya hanya 1 pod dulu).
Atau blue-green sederhana untuk service yang sangat kritis (payment, auth).

Yang penting: strategi deploy harus tertulis dan otomatis sedapat mungkin, bukan keputusan ad-hoc setiap kali rilis.

Rollback Plan yang Benar-Benar Bisa Dipakai

Rollback yang bagus bukan sekadar “kalau ada masalah kita rollback saja”, tapi jawaban spesifik untuk:

Bagaimana cara kembali ke versi sebelumnya?
Berapa lama biasanya butuh waktu?
Apa konsekuensi ke data?

Beberapa prinsip praktis:

Simpan artefak beberapa versi ke belakang
- Misalnya minimal 3–5 versi terakhir yang bisa dideploy ulang kapan saja.
Automate rollback sederhana
- Contoh: perintah atau workflow “deploy versi X” yang sama mudahnya dengan deploy versi terbaru.
Pikirkan soal data migration
- Skema DB yang di-migrate maju tapi tidak backward compatible membuat rollback berbahaya.
- Gunakan pola migration yang mendukung rollback (misalnya expand–contract: tambahkan kolom dulu, gunakan di code, baru hapus lama setelah aman).
Latih di staging
- Sesekali, latihan rollback di environment non-production untuk memastikan prosedur benar-benar bisa dijalankan dan tidak hanya tinggal di wiki.

Tujuannya: saat incident terjadi, tim tidak perlu debat panjang soal “boleh rollback atau tidak” karena skenario-nya sudah dipikirkan sebelumnya.

Metrik Pipeline yang Wajib Dipantau

Supaya pipeline terus membaik (bukan makin lambat tanpa disadari), kamu perlu beberapa metrik dasar:

Lead time dari commit ke production
- Berapa lama, rata-rata, sebuah perubahan yang sudah di-merge sampai ke production?
Frekuensi deploy
- Seberapa sering tim merilis?
- Deploy yang terlalu jarang bisa sinyal bahwa pipeline atau proses rilis terlalu berat.
Change failure rate
- Persentase deploy yang menyebabkan incident, rollback, atau hotfix urgent.
Durasi pipeline
- Waktu rata-rata fast feedback.
- Waktu rata-rata deep validation.

Metrik-metrik ini sejalan dengan DORA metrics (deployment frequency, lead time for changes, change failure rate, dan mean time to restore), dan bisa dijadikan:

Bahan diskusi di retrospektif: apakah pipeline membantu atau menghambat?
Dasar prioritas: apakah saat ini lebih penting mempercepat test, menambah observabilitas, atau merapikan strategi rollback?

Yang penting, jangan jadikan angka-angka ini sebagai alat menghukum. Gunakan sebagai kompas untuk membuat delivery tim jadi lebih tenang, bukan lebih tertekan.