Apa yang Sebenarnya Memicu Pipeline CI/CD untuk Berjalan

Seorang developer menyelesaikan perbaikan bug, mengetik git push, lalu pergi. Beberapa menit kemudian, chat tim ramai: "Build gagal." Tidak ada yang menyentuh konfigurasi pipeline. Tidak ada yang menekan tombol. Pipeline itu berjalan begitu saja.

Ini adalah hal normal di sebagian besar tim. Tapi jika Anda bertanya mengapa pipeline itu berjalan, jawabannya sering kabur: "Karena saya push kode." Itu benar, tapi melewatkan detail penting. Pipeline tidak berjalan dengan sendirinya. Sesuatu harus memicunya. Dan jenis pemicu yang Anda pilih mengubah cara tim bekerja, apa yang diuji, dan kapan sesuatu masuk ke produksi.

Mari kita bahas situasi nyata di mana pipeline mulai berjalan, dan apa arti setiap pemicu bagi alur kerja harian Anda.

Saat Developer Push Kode

Pemicu paling umum adalah commit yang di-push ke repositori bersama. Seorang developer menyelesaikan perubahan, melakukan commit secara lokal, dan push ke GitHub, GitLab, atau Bitbucket. Repositori mengirim webhook ke sistem CI/CD, dan pipeline mulai berjalan.

Kedengarannya sederhana, tapi detailnya penting. Commit membawa metadata: file mana yang berubah, siapa yang membuat perubahan, dan pesan commit. Pipeline yang baik menggunakan metadata ini untuk memutuskan apa yang harus dilakukan. Jika commit hanya menyentuh file README, Anda mungkin tidak perlu menjalankan seluruh rangkaian pengujian dan deploy ke staging. Tapi jika commit mengubah kode aplikasi, pipeline harus menjalankan semuanya.

Diagram di bawah menunjukkan bagaimana pemicu push bercabang berdasarkan metadata commit:

Berikut cara mendefinisikan pemicu push di workflow GitHub Actions:

name: CI Pipeline
on:
  push:
    branches:
      - main
      - 'feature/**'
    paths-ignore:
      - 'README.md'
      - 'docs/**'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
flowchart TD Push[Git Push] --> Webhook[Webhook ke CI/CD] Webhook --> Inspect[Periksa Metadata Commit] Inspect --> Branch{Cabang?} Branch -- feature --> Unit[Jalankan Unit Test & Lint] Branch -- main --> Full[Jalankan Rangkaian Tes Lengkap] Inspect --> Files{File Berubah?} Files -- hanya kode --> Unit Files -- termasuk docs --> Skip[Lewati Tes] Files -- campuran --> Full

Tim yang memperlakukan setiap commit dengan cara yang sama membuang waktu dan sumber daya komputasi. Pendekatan yang lebih cerdas adalah membiarkan pipeline memeriksa commit dan cabang sebelum memutuskan langkah selanjutnya. Misalnya, commit di cabang fitur mungkin hanya menjalankan unit test dan linting, sementara commit di cabang utama memicu integration test dan deployment staging.

Saat Pull Request Digabung

Banyak tim menggunakan pull request atau merge request sebagai gerbang review. Seorang developer membuka PR, rekan setim meninjau kode, dan ketika disetujui, seseorang menggabungkannya. Penggabungan itu sendiri bisa menjadi pemicu.

Ini berbeda dari pemicu commit biasa. Penggabungan biasanya menandakan bahwa perubahan telah melewati review manusia dan siap masuk ke cabang yang lebih stabil. Pipeline yang dipicu oleh penggabungan sering menjalankan pemeriksaan yang lebih ketat: rangkaian tes yang lebih panjang, pemindaian keamanan, atau tes migrasi database. Asumsinya adalah perubahan ini akan segera masuk ke produksi, jadi Anda menginginkan keyakinan yang lebih tinggi.

Beberapa tim juga menjalankan pipeline pada pull request itu sendiri, sebelum digabung. Ini memberikan umpan balik awal. Tapi pemicu penggabungan adalah momen kebenaran. Begitu kode berada di cabang utama, kode itu menjadi bagian dari riwayat bersama. Pipeline yang gagal pada titik ini berarti tim harus segera memperbaikinya, karena developer lain akan menarik kode yang rusak itu.

Saat Jam Berbicara

Tidak semua pipeline membutuhkan perubahan kode untuk berjalan. Pemicu terjadwal memulai pipeline pada waktu tertentu, terlepas dari apakah ada yang push kode.

Kasus penggunaan umum meliputi:

  • Menjalankan integration test yang panjang setiap malam saat tidak ada yang menunggu hasil.
  • Menyegarkan lingkungan staging dengan snapshot data produksi.
  • Memperbarui versi dependensi atau menjalankan pemindaian kerentanan.
  • Melakukan backup atau tugas pembersihan.

Pemicu terjadwal berguna untuk pekerjaan yang harus dilakukan secara teratur tetapi tidak bergantung pada aktivitas developer. Mereka juga menangkap masalah yang hanya muncul seiring waktu, seperti lingkungan tes yang perlahan menurun atau sertifikat yang akan kedaluwarsa.

Kekurangannya adalah pipeline terjadwal mungkin berjalan saat tidak ada yang berubah. Jika gagal, seseorang harus menyelidiki apakah kegagalan itu nyata atau hanya tes yang flaky. Tim harus menjaga pipeline terjadwal tetap fokus pada tugas yang benar-benar membutuhkan eksekusi periodik, bukan pada hal-hal yang bisa dipicu oleh perubahan kode.

Saat Seseorang Menekan Tombol

Pemicu manual memberikan keputusan akhir kepada manusia. Alih-alih pipeline mulai otomatis, seseorang masuk ke sistem CI/CD dan mengklik "Run" atau "Deploy."

Ini umum untuk deployment produksi. Bahkan jika semua pemeriksaan otomatis lolos, banyak tim menginginkan seseorang untuk secara eksplisit menyetujui deployment. Pemicu manual juga menangani situasi darurat: rollback ke versi sebelumnya, redeploy setelah lingkungan crash, atau menjalankan migrasi data satu kali.

Pemicu manual bukan hanya tentang kontrol. Mereka juga membawa tanggung jawab. Ketika seseorang memulai pipeline secara manual, mereka harus mencatat alasannya. Sistem CI/CD yang baik memungkinkan Anda menambahkan catatan: "Rollback ke v2.1.3 karena rilis terbaru memiliki kebocoran koneksi database." Metadata ini menjadi bagian dari jejak audit.

Risiko dengan pemicu manual adalah mereka bisa menjadi hambatan. Jika setiap deployment membutuhkan seseorang untuk mengklik tombol, dan orang itu sedang cuti, tidak ada yang rilis. Tim harus menyediakan pemicu manual hanya untuk tindakan yang benar-benar membutuhkan penilaian manusia, bukan untuk langkah rutin yang bisa diotomatisasi.

Mengapa Metadata Lebih Penting dari yang Anda Kira

Setiap pemicu membawa informasi. Pemicu commit membawa hash commit, nama cabang, dan penulis. Pemicu penggabungan membawa nomor pull request dan nama reviewer. Pemicu manual membawa nama operator dan alasan yang dinyatakan.

Metadata ini bukan hanya untuk pencatatan. Pipeline menggunakannya untuk membuat keputusan. Haruskah menjalankan rangkaian tes lengkap atau hanya smoke test? Haruskah deploy ke staging atau produksi? Haruskah memberi tahu on-call engineer atau hanya mengirim ringkasan ke channel tim?

Tanpa metadata, pipeline buta. Ia menjalankan langkah yang sama setiap kali, terlepas dari apa yang berubah. Itu berfungsi untuk proyek sederhana, tapi seiring pertumbuhan sistem, Anda membutuhkan logika kondisional. Pemicu adalah tempat pertama untuk menyuntikkan logika itu.

Daftar Periksa Singkat untuk Memilih Pemicu

Jika Anda menyiapkan pipeline baru atau meninjau yang sudah ada, pertanyaan-pertanyaan ini membantu Anda memutuskan pemicu mana yang akan digunakan:

  • Apakah setiap commit membutuhkan pipeline yang sama, atau bisakah Anda melewati langkah untuk perubahan hanya dokumentasi?
  • Apakah Anda menginginkan umpan balik pada pull request sebelum digabung, atau hanya setelah digabung?
  • Apakah ada tugas yang harus berjalan setiap hari meskipun tidak ada yang push kode?
  • Langkah mana yang membutuhkan persetujuan manusia, dan mana yang bisa berjalan otomatis?
  • Apakah pipeline Anda menangkap cukup metadata untuk men-debug kegagalan nanti?

Kesimpulan

Pemicu pipeline bukan sekadar tombol mulai. Ia adalah titik keputusan yang mendefinisikan kapan pekerjaan dimulai, konteks apa yang tersedia, dan seberapa banyak otomatisasi yang aman. Pilih pemicu berdasarkan risiko dan frekuensi setiap tindakan, bukan karena kebiasaan. Pipeline yang dipicu dengan baik menjalankan pemeriksaan yang tepat pada waktu yang tepat, tanpa menunggu seseorang ingat untuk mengklik tombol.