Selamat, kamu sudah punya pipeline CI/CD yang jalan end-to-end — dari push kode sampai live di production, lengkap dengan approval gate. Di artikel penutup ini, kita bahas hal-hal yang sering bikin pemula terjebak, cara debug yang efisien, dan ke mana kamu bisa lanjut belajar setelah ini.
Kesalahan Umum Pemula
Commit credential langsung di kode. Ini yang paling fatal. Sekali API key ter-commit ke git history, walaupun langsung dihapus di commit berikutnya, dia tetap ada di history dan bisa ditemukan. Selalu pakai Secrets, dan kalau sudah terlanjur ter-commit, langsung revoke/rotate credential-nya — jangan cuma dihapus dari kode.
Test yang flaky (kadang lolos, kadang gagal tanpa perubahan kode). Biasanya karena test bergantung pada urutan eksekusi, waktu (timing), atau state yang tidak di-reset antar test. Test yang flaky itu bahaya, karena lama-lama tim jadi terbiasa re-run pipeline tanpa investigasi — ujung-ujungnya kepercayaan ke CI hilang.
Pipeline terlalu lama, jadi jarang dipakai. Kalau pipeline butuh 20 menit untuk kelar, orang jadi malas menunggu dan mulai skip. Optimasi seperti caching dependency (cache: 'npm' yang kita pakai) dan menjalankan job paralel itu bukan cuma soal kecepatan, tapi soal menjaga kebiasaan tim tetap pakai CI/CD.
Tidak ada branch protection, jadi CI cuma formalitas. Sudah dibahas di artikel praktik CI pertama — kalau CI merah tapi orang masih bisa merge manual, gunanya CI berkurang drastis.
Environment production dan staging beda konfigurasi jauh. Kalau staging dan production beda versi Node, beda environment variable, atau beda struktur data — bug yang lolos di staging bisa muncul lagi di production. Usahakan sedekat mungkin (parity).
Terlalu banyak manual step yang "katanya" otomatis. Misalnya, masih ada step "jangan lupa update file X secara manual sebelum deploy". Kalau ada instruksi manual berulang, itu kandidat kuat untuk diotomasi masuk ke pipeline.
Checklist Debug Pipeline yang Bermasalah
Kalau pipeline kamu gagal dan bingung mulai dari mana, coba urutan ini:
Baca log dari step yang gagal, bukan cuma lihat status merah. Expand step-nya, cari baris error yang spesifik.
Reproduce di lokal dulu. Jalankan perintah yang sama persis (npm ci, npm test) di mesin lokal. Kalau gagal juga di lokal, ini bug kode, bukan masalah CI.
Kalau cuma gagal di CI tapi lokal aman, curigai perbedaan environment — versi Node/runtime, environment variable yang belum di-set, atau dependency yang beda karena package-lock.json tidak sinkron.
Cek urutan job/step dan needs. Pastikan job yang butuh hasil job lain memang sudah didefinisikan dependency-nya dengan benar.
Cek Secrets dan permission. Error seperti "401 Unauthorized" atau "permission denied" biasanya karena secret salah, kedaluwarsa, atau belum ditambahkan di repo yang benar.
Kalau workflow syntax error (misalnya file .yml tidak jalan sama sekali), gunakan validator YAML atau extension GitHub Actions di editor untuk cek indentasi dan struktur.
Kebiasaan paling penting: jangan langsung re-run pipeline berharap "kali ini lolos" tanpa tahu kenapa gagal. Kalau itu jadi kebiasaan, artinya kita sudah mulai kehilangan kepercayaan pada sinyal yang CI berikan — dan itu awal dari masalah yang lebih besar.
Roadmap Lanjutan — Mau Belajar Apa Lagi?
Seri ini sengaja fokus ke dasar-dasar biar kamu punya fondasi kuat. Kalau mau lanjut lebih dalam, ini beberapa arah yang bisa dieksplorasi:
Docker & containerization — mengemas aplikasi jadi container supaya environment benar-benar konsisten dari lokal sampai production. Banyak pipeline production modern build Docker image sebagai bagian dari job build.
Multi-environment deployment — punya environment staging/dev terpisah dari production, dengan pipeline yang deploy ke staging dulu otomatis, baru ke production setelah divalidasi.
Notifikasi pipeline — integrasi Slack/Discord/email supaya tim langsung tahu kalau ada pipeline yang gagal, tanpa harus cek dashboard manual.
Infrastructure as Code (IaC) — tools seperti Terraform untuk mengelola infrastruktur (bukan cuma kode aplikasi) lewat pipeline juga.
Tools CI/CD lain di luar GitHub Actions — kalau nanti kerja di perusahaan yang pakai platform lain, konsepnya (trigger, job, runner, artifact) sama persis, cuma sintaksnya beda:
-
GitLab CI/CD — mirip banget, pakai file
.gitlab-ci.yml.
-
Jenkins — lebih tua, self-hosted, sangat fleksibel tapi setup lebih kompleks.
-
CircleCI — populer juga, mirip konsepnya dengan GitHub Actions.
Kabar baiknya, karena kamu sudah paham konsep dasarnya di artikel anatomi pipeline — trigger, job, step, runner, artifact — belajar tool CI/CD lain nantinya tinggal soal adaptasi sintaks, bukan belajar dari nol lagi.
Penutup
Kita sudah menempuh perjalanan dari "kenapa CI/CD penting", memahami anatomi pipeline, praktik membuat CI pertama, menambahkan secrets dan build artifact, sampai deploy otomatis ke production dengan approval gate. Yang paling penting, kamu sekarang punya template pipeline nyata yang bisa dipakai ulang dan dimodifikasi untuk proyek kamu sendiri.
Terima kasih sudah mengikuti seri CI/CD for Beginners ini. Selamat mencoba di proyek kamu sendiri!