Di artikel sebelumnya, kita sudah paham kenapa CI/CD penting. Sekarang saatnya membedah apa saja yang membentuk sebuah pipeline CI/CD. Ibaratnya, sebelum masak, kita kenalan dulu dengan alat-alat dapurnya — supaya begitu masuk ke praktik dengan GitHub Actions, istilah-istilah yang muncul tidak lagi bikin bingung.
Trigger — Apa yang Memicu Pipeline Berjalan?
Trigger adalah event yang membuat pipeline otomatis mulai berjalan. Tanpa trigger, pipeline tidak akan jalan sendiri. Beberapa trigger yang umum dipakai:
main atau develop).Di sesi praktik nanti, kita akan pakai trigger push dan pull_request untuk CI, dan trigger push ke branch main untuk deployment.
Stage, Job, dan Step — Struktur di Dalam Pipeline
Setelah pipeline ter-trigger, isinya terstruktur. Supaya konsisten, kita samakan istilahnya dengan yang dipakai GitHub Actions:
.yml.test, job build, job deploy.checkout code, install dependencies, run tests.Poin penting: job bisa jalan paralel atau berurutan. Secara default, beberapa job bisa jalan bersamaan (paralel) untuk mempercepat pipeline. Tapi kalau job B butuh hasil dari job A — misalnya job deploy butuh job test lolos dulu — kita bisa bikin dia menunggu (sequential) memakai dependency antar job.
Contoh alur pipeline CI/CD yang khas:
Trigger: push ke branch main
└── Job: test (checkout → install deps → run test)
└── Job: build (checkout → install deps → build artifact)
└── Job: deploy (download artifact → deploy ke server)
Runner, Artifact, dan Environment
Runner (atau disebut juga agent)
Runner adalah "komputer" yang benar-benar menjalankan job kita. Bisa berupa virtual machine sementara yang disediakan platform CI/CD (misalnya GitHub-hosted runner: Ubuntu, Windows, macOS), atau bisa juga server milik sendiri (self-hosted runner). Setiap job biasanya dapat runner yang fresh/bersih — jadi hasilnya konsisten, tidak terbawa "sampah" dari run sebelumnya.
Artifact
Artifact adalah file hasil dari suatu job yang ingin kita simpan atau lempar ke job berikutnya. Misalnya, job build menghasilkan folder dist/ hasil compile — folder itu di-upload sebagai artifact, supaya job deploy bisa download dan memakai file itu tanpa harus build ulang dari nol.
Environment
Environment adalah "tempat" hasil deployment kita jalan — misalnya staging dan production. Tiap environment biasanya punya konfigurasi dan credential yang berbeda. Nanti kita juga akan membahas environment protection rules — cara mengunci environment production supaya cuma bisa di-deploy setelah ada approval.
Branching Strategy yang Cocok untuk CI/CD
Terakhir, bagaimana strategi branching yang cocok dipakai bersama CI/CD? Ada banyak model, tapi dua yang paling relevan untuk pemula:
main, develop, feature/*, release/*, hotfix/*. Cocok untuk software dengan siklus rilis terjadwal dan butuh banyak tahap QA. Tapi untuk pemula, ini agak kompleks dan kurang "cepat" untuk filosofi CI/CD yang menekankan integrasi sering.feature/xyz) yang cepat di-merge kembali ke satu branch utama (main atau trunk), idealnya dalam hitungan jam sampai 1-2 hari. Branch main selalu dalam kondisi siap deploy (deployable).Untuk seri ini dan kebanyakan tim kecil-menengah, kita akan pakai pendekatan yang mirip trunk-based: kerja di feature branch pendek, buka Pull Request ke main, CI jalan otomatis di PR itu, setelah lolos dan di-review baru merge. Setiap merge ke main bisa memicu deployment.
feature/tambah-endpoint ──PR──► main ──merge──► trigger CD
(CI jalan di sini) (deploy ke production)