CI/CD dari Nol: Kapan Lo Beneran Butuh, Tools yang Cocok, dan Funfact yang Jarang Dibahas

Lo gak butuh CI/CD.

Lo butuh proses deploy yang konsisten dan repeatable. CI/CD cuma alat buat mencapai itu. Bedain dulu, baru lo tau kapan beneran butuh.

Masalahnya, banyak yang pasang pipeline karena “katanya harus” - tanpa nanya: masalah apa yang mau diselesaiin? Ujungnya? Pipeline cuma jalananin test doang, deploy masih manual via SSH. Atau - lebih parah - pipeline 200 baris yang gak ada yang berani touch karena takut broken.

Artikel ini bukan tutorial “cara setup CI/CD”. Ini framework buat lo nentuin: kapan butuh, tools apa, dan seberapa kompleks.

Seberapa Populer CI/CD Sekarang?

Berdasarkan data adopsi dari beberapa sumber industri, GitHub Actions jadi yang paling banyak dipake. GitLab CI dan Jenkins juga masih punya basis pengguna kuat, terutama di enterprise yang butuh self-hosted solution.

Kapan Lo Beneran Butuh CI/CD?

Gak semua project butuh pipeline dari hari pertama. Miu bagi jadi 3 fase biar lo bisa nemuin posisi lo.

Fase 1: Project Kecil - 1-3 Developer, 1 Environment

Ciri-ciri:

• Lo sendiri atau tim kecil yang masih ngobrol langsung tiap hari
• Deploy masih pake rsync, scp, atau git pull di server
• Testing masih manual - jalanin di lokal, kalo oke deploy

Butuh CI/CD? Belum tentu.

Kalo tim lo kecil, komunikasi lancar, dan frekuensi deploy masih wajar - manual deploy itu valid. Malah masang pipeline di fase ini bisa kontraproduktif: lo malah sibuk maintain runner daripada nulis kode.

Tapi ada satu sinyal yang gak boleh lo abaikan: kalo lo udah ngerasa “ah males banget deploy” - itu tandanya lo butuh pipeline. Bukan karena nambah fitur, tapi karena proses manual udah jadi beban mental.

Kalo lo paksain pipeline, cukup yang simpel:

GitHub Actions - karena gratis 2.000 menit/bulan buat private repo. Cukup test → build → deploy ke satu server. Pipeline gak perlu lebih dari 20 baris YAML.

name: Deploy
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test
      - run: scp -r . user@server:/var/www/app

Fungsional, simpel, gak overkill. (Sumber: GitHub Actions billing docs)

Fase 2: Medium - 3-10 Developer, Staging + Production

Ciri-ciri:

• Udah mulai ada staging server yang mirip production
• Udah 3+ orang - gak semua tau detail infrastruktur
• Testing udah mulai butuh automation (unit test, integration test)
• Kadang ada 2 PR di-review barengan

Wajib CI/CD.

Di fase ini, manual deploy mulai terasa sakitnya. Lo pernah alamin: “staging oke, production error” atau “siapa yang deploy terakhir?” - itu tandanya pipeline bukan lagi opsional.

Tool recommendation:

Arsitektur pipeline yang ideal:

Push → Lint + Unit Test → Build Image → Deploy ke Staging → (Manual Approval) → Deploy ke Production

Yang sering terjadi di lapangan: pipeline udah jalan, test otomatis udah lewat, tapi deploy ke production tetap manual via UI console AWS/GCP. Kenapa? Karena tim gak percaya pipeline. Dan gak percaya karena testing di staging gak representatif, atau karena satu-satunya yang tahu cara deploy udah cuti.

CI/CD gak fix masalah kepercayaan tim. Itu masalah budaya, bukan tools.

(GitLab pricing: gitlab.com/pricing; Jenkins: open source, jenkins.io)

Fase 3: Production Grade - Multi-env, Multi-service, Infrastructure as Code

Ciri-ciri:

• Udah 50+ developer, 10+ service
• Infrastruktur di-manage pake Terraform
• Ada compliance & audit trail requirement (umum di banking/fintech)
• Rollback bukan cuma “git revert”, tapi butuh koordinasi antar service

CI/CD bukan pilihan - ini kebutuhan survival.

Di fase ini, pipeline bukan cuma ngurus aplikasi, tapi juga ngurus infrastruktur. Masuk Terraform.

Funfact: Terraform di Pipeline - Triky Banget

1. State Lock - “Error Acquiring the State Lock”

Ini pesan error yang keluar kalo 2 pipeline apply Terraform di waktu yang bersamaan. Source code Terraform sendiri yang nge-define error ini. (Confirmed dari HashiCorp Terraform repo dan dokumentasi state locking.)

Gimana cara kerjanya:

• S3 backend butuh DynamoDB table buat locking
• Waktu pipeline A pegang lock, pipeline B bakal nunggu - kalo kelamaan, error
• Lock dilepas setelah apply selesai - atau lo paksa lepas pake terraform force-unlock

Best practice: Jangan jalanin multiple pipeline yang apply ke state yang sama secara paralel. Buat queue atau sequential aja.

2. Blast Radius - Jangan Satukan Semua State

Konsep blast radius di Terraform: seberapa parah kerusakan yang bisa terjadi dari satu perintah terraform apply.

Kalo lo satuin semua service dalam satu state file, satu error di pipeline dev bisa:

• Kehapus resource staging
• Kehapus database production
• Atau - yang paling sering - nge-blow up semua resource gara-gara state conflict

Solusinya: satu state per environment (dev/staging/prod) dan idealnya satu state per service.

3. Workspaces - Jangan Kayak Git Branches

Banyak yang pake Terraform workspaces buat misahin environment - dev workspace, staging workspace, prod workspace. Mirip cara mereka pake branch di Git.

Dokumentasi Terraform bilang:

“CLI workspaces within a working directory use the same backend, so they are not a suitable isolation mechanism for this scenario.”

• HashiCorp Terraform Workspaces Docs

Artinya: kalo satu backend bermasalah, semua environment kena. Untuk isolasi proper, pake direktori root module terpisah masing-masing dengan backend config sendiri.

4. Plan-Apply Separation

Anti-pattern paling umum di CI/CD: terraform plan langsung diikutin terraform apply di pipeline yang sama.

Masalahnya: antara plan dan apply, keadaan infrastruktur bisa berubah. Plan udah basi.

• Ada approval gate
• Re-plan setelah approval
• Baru apply

Ini salah satu alasan kenapa tim gak percaya pipeline Terraform mereka - karena pernah kena “plan bilang aman, apply bilang error.”

Perbandingan Tools: Pricing Nyata

Ini perbandingan berdasarkan official pricing pages (Juni 2026):

Simulasi biaya tim medium (10 dev):

• GitHub Actions: $0 (pake 2.000 menit gratis) - ~$6/bulan kalo lebih (1000 menit extra x $0.006)
• GitLab CI Premium: $290/bulan (10x$29) + VM runner ~$20 = $310/bulan
• Jenkins: VM runner ~$20/bulan + maintenance - gratis software
• AWS CodePipeline: $1-5/bulan + compute (CodeBuild ~$15-30)
• GCP Cloud Build: $0-15/bulan

Catatan: Harga bisa berubah. Cek official pricing pages sebelum keputusan.

Seberapa Penting CI/CD?

Jujur: tergantung. Kalo lo:

• Solo dev, project sample codingan - gak penting
• Tim 5 orang, 2 service, deploy seminggu sekali - penting
• Tim 50 orang, 20 service, compliance - wajib

Nilai paling gede dari CI/CD bukan automation-nya. Tapi konsistensi dan audit trail. Lo tau persis:

• Apa yang berubah
• Kapan berubah
• Siapa yang approve
• Rollback gampang karena tinggal pake image sebelumnya

Tanpa pipeline, proses deploy cuma ada di kepala satu orang. Dan kalo orang itu cuti - selamat datang deployment Friday afternoon.

Kesimpulan

CI/CD itu spektrum. Gak harus full-blown Jenkins + Terraform dari hari pertama.

• Mulai dari yang paling simple. Pipeline 10 baris yang lo pahami > pipeline 200 baris yang gak ada yang berani touch.
• Fase 1 cukup GitHub Actions sederhana. Gak perlu mikirin self-hosted runner dulu.
• Fase 2 baru mikirin approval gate, staging, dan multi-env.
• Fase 3 baru masukin Terraform - dengan catatan paham state locking, blast radius, dan plan-apply separation.
• Paling penting - CI/CD gak fix masalah budaya tim. Kalo testing gak bener, staging gak representatif, atau tim gak percaya pipeline, pipeline cuma automation of chaos.

Terima kasih sudah meluangkan waktu buat baca artikel ini, semoga ada manfaat yang bisa diambil. 🐾