Dari Commit ke Production: Bagaimana Tools Saling Berkomunikasi dalam Pipeline Nyata

Anda melakukan push commit. Lalu apa?

Jika Anda pernah melihat deployment terhenti karena server CI tidak mendapat notifikasi, atau karena seseorang harus menyalin artifact secara manual dari satu tempat ke tempat lain, Anda pasti tahu betapa menjengkelkannya hal itu. Tools sudah tersedia. Pipeline sudah dikonfigurasi. Namun di suatu titik, rantai tersebut putus. Seseorang harus SSH ke sebuah server, menjalankan perintah secara manual, dan berharap tidak ada yang salah.

Saat itulah CI/CD berhenti menjadi otomatis dan berubah menjadi kumpulan langkah manual yang dibungkus dengan tooling.

Pekerjaan sesungguhnya dari sebuah pipeline bukan terletak pada satu tool pun. Melainkan pada bagaimana tool-tool tersebut saling terhubung. Commit di repositori Anda harus memicu server CI. Server CI harus tahu ke mana harus mengirim artifact yang sudah jadi. Registry artifact harus memberi tahu tool deployment bahwa versi baru sudah siap. Dan tool deployment harus berkoordinasi dengan proses migrasi database sebelum atau sesudah versi baru mulai berjalan.

Rantai pemicu dan aliran data inilah yang membuat pipeline benar-benar bekerja. Mari kita telusuri dari awal.

Rantai Pemicu: Setiap Tool Memiliki Dua Tugas

Setiap tool dalam pipeline memainkan dua peran. Ia menerima pemicu dari tool sebelumnya, dan ia mengirim pemicu ke tool setelahnya. Jika salah satu koneksi putus, pipeline akan berhenti. Tim harus turun tangan secara manual, dan Anda kembali ke masalah yang seharusnya dipecahkan oleh CI/CD: proses manual yang lambat dan rawan kesalahan.

Rantai dimulai dengan sebuah commit. Seorang developer menggabungkan perubahan ke branch utama, atau membuka pull request yang kemudian digabungkan. Server Git mendeteksi peristiwa ini. Peristiwa itu harus sampai ke server CI. Mekanisme pengirimannya bisa berupa webhook, polling, atau event bus. Metodenya tidak terlalu penting dibandingkan fakta bahwa server CI tahu ada kode baru yang menunggu.

Diagram urutan berikut mengilustrasikan rantai pemicu dan aliran data ini:

Berikut adalah contoh konkret dari rantai pemicu tersebut dalam workflow GitHub Actions:

name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: |
          docker tag myapp:${{ github.sha }} registry.example.com/myapp:${{ github.sha }}
          docker push registry.example.com/myapp:${{ github.sha }}
      - name: Trigger deployment
        run: |
          curl -X POST https://deploy.example.com/api/deploy \
            -H "Authorization: Bearer ${{ secrets.DEPLOY_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"artifact": "myapp", "version": "${{ github.sha }}", "env": "staging"}'
sequenceDiagram participant Dev as Developer participant Git as Git Server participant CI as CI Server participant Reg as Artifact Registry participant Dep as Deployment Tool participant DB as Database Migration participant Prod as Production Environment Dev->>Git: commit push Git->>CI: webhook trigger CI->>CI: build & test CI->>Reg: push artifact Reg->>Dep: notification Dep->>DB: migration run DB->>Dep: migration complete Dep->>Prod: deploy artifact Prod->>Dep: deployment complete

Server CI menjalankan pipeline-nya. Ini mencakup tahap build, test, dan packaging. Outputnya adalah sebuah artifact. Artifact tersebut bisa berupa binary yang sudah dikompilasi, image container, file konfigurasi, atau paket migrasi database. Artifact harus dikirim ke registry. Registry bukan sekadar folder di server. Ia adalah sistem penyimpanan terstruktur di mana setiap artifact memiliki versi, metadata, dan informasi provenance tentang bagaimana artifact itu dibuat.

Sekarang tool deployment perlu tahu bahwa versi baru sudah tersedia. Beberapa tool deployment memonitor registry secara langsung. Yang lain menunggu pemicu dari server CI atau webhook dari registry. Bagaimanapun caranya, tool deployment harus menerima informasi bahwa versi X dari artifact Y sudah siap untuk environment tertentu.

Tool deployment kemudian melakukan deploy ke environment target. Namun deployment aplikasi jarang berdiri sendiri. Sebelum versi baru berjalan, database seringkali membutuhkan perubahan: kolom baru, indeks yang dimodifikasi, atau migrasi data. Migrasi database harus berjalan sebagai bagian dari deployment, bukan sebagai langkah manual terpisah. Urutannya penting. Terkadang migrasi harus berjalan sebelum versi aplikasi baru dimulai. Terkadang harus berjalan setelahnya. Itu tergantung pada apakah perubahannya kompatibel ke belakang (backward compatible).

Setelah deployment selesai, pipeline belum selesai. Anda perlu verifikasi bahwa versi baru berjalan normal. Ini bisa berupa health check, smoke test, atau sinyal observability yang menunjukkan tidak ada lonjakan error secara tiba-tiba. Jika verifikasi gagal, rollback harus dipicu secara otomatis atau dengan satu klik.

Aliran Artifact: Data yang Bergerak Antar Tool

Sepanjang rantai ini, data mengalir antar tool. Metadata commit, versi artifact, status pipeline, hasil tes, konfigurasi environment, dan kredensial untuk mengakses setiap tool. Data ini harus berpindah dari satu tool ke tool berikutnya tanpa campur tangan manual.

Inilah yang dimaksud dengan aliran artifact. Semakin bersih aliran artifact, semakin sedikit error yang disebabkan oleh informasi yang hilang di tengah jalan. Ketika sebuah deployment gagal karena seseorang lupa memperbarui file konfigurasi, atau karena versi artifact yang salah di-deploy, akar masalahnya hampir selalu adalah aliran artifact yang rusak.

Aliran artifact yang dirancang dengan baik mencakup:

  • Pengidentifikasi unik untuk setiap artifact yang merujuk kembali ke commit dan pipeline run yang tepat.
  • Konfigurasi spesifik environment yang disimpan terpisah dari artifact itu sendiri, sehingga artifact yang sama dapat dipromosikan melalui staging ke production tanpa perlu rebuild.
  • Manajemen kredensial yang memungkinkan setiap tool untuk mengautentikasi ke tool berikutnya tanpa secret yang di-hardcode.
  • Propagasi status sehingga setiap tool dalam rantai tahu apakah langkah sebelumnya berhasil atau gagal.

Pipeline Tidak Selalu Linier

Rantai pemicu terdengar linier, tetapi pipeline nyata tidak sesederhana itu. Terkadang satu commit memicu beberapa pipeline secara bersamaan: satu untuk aplikasi, satu untuk infrastruktur, satu untuk database. Atau beberapa commit terkumpul sebelum memicu sebuah deployment. Beberapa tim menggunakan model release branch di mana commit dikumpulkan dan di-deploy bersama. Yang lain men-deploy setiap commit langsung ke production.

Pola pemicu dan aliran data menentukan bagaimana pipeline Anda berperilaku di bawah tekanan. Jika Anda memilih tool tanpa memahami bagaimana mereka akan terhubung, Anda akan berakhir dengan pipeline yang berfungsi saat demo tetapi rusak di production. Tool yang tampak hebat di atas kertas mungkin tidak terintegrasi dengan baik dengan registry artifact Anda. Tool deployment yang menangani container dengan indah mungkin tidak memiliki dukungan untuk migrasi database.

Inilah sebabnya mengapa pemilihan tool harus dimulai dari rantai, bukan dari fitur individual. Petakan bagaimana sebuah commit menjadi layanan yang berjalan di production. Identifikasi setiap titik serah terima. Kemudian evaluasi tool berdasarkan seberapa baik mereka menangani serah terima tersebut.

Risiko Tool Sprawl

Ketika setiap tim memilih tool mereka sendiri tanpa koordinasi, hasilnya bukanlah pipeline yang mulus. Melainkan tool sprawl. Satu tim menggunakan Jenkins. Tim lain menggunakan GitHub Actions. Tim database memiliki tool migrasi mereka sendiri. Tim infrastruktur menggunakan Terraform dengan backend state yang berbeda. Setiap tool bekerja secara terisolasi, tetapi menghubungkannya membutuhkan skrip kustom, langkah manual, dan banyak pengetahuan tribal.

Tool sprawl bukan hanya masalah pemeliharaan. Ini adalah masalah keandalan. Setiap integrasi kustom adalah titik kegagalan. Setiap serah terima manual adalah tempat terjadinya kesalahan. Tujuannya bukanlah menggunakan tool yang sama untuk semuanya. Tujuannya adalah memiliki rantai pemicu dan aliran artifact yang koheren di seluruh tool apa pun yang Anda pilih.

Daftar Periksa Praktis untuk Menghubungkan Tool

Sebelum Anda memfinalisasi pemilihan tool, jalankan daftar periksa ini untuk setiap titik serah terima dalam pipeline Anda:

  • Bagaimana server Git memberi tahu server CI tentang commit baru?
  • Bagaimana server CI mendorong artifact ke registry?
  • Bagaimana tool deployment mengetahui tentang versi artifact baru?
  • Bagaimana tool deployment memicu migrasi database?
  • Bagaimana pipeline memverifikasi bahwa deployment berhasil?
  • Bagaimana rollback dipicu, dan apakah itu mencakup rollback database?
  • Data apa yang mengalir antara setiap pasangan tool, dan apakah data tersebut dikirim secara otomatis?

Jika salah satu dari serah terima ini membutuhkan seseorang untuk melakukan sesuatu secara manual, Anda telah menemukan celah yang akan menyebabkan masalah cepat atau lambat.

Kesimpulan

Sebuah pipeline hanya sekuat koneksi terlemahnya. Tool yang Anda pilih tidak sepenting bagaimana mereka saling melewatkan pemicu dan data. Mulailah dengan memetakan rantai dari commit ke production. Identifikasi setiap serah terima. Kemudian pilih tool yang cocok dengan rantai tersebut, bukan tool yang terlihat mengesankan secara terpisah. Pipeline terbaik bukanlah yang memiliki fitur paling banyak. Melainkan yang memungkinkan commit mengalir ke production tanpa ada yang harus berhenti dan memikirkan apa yang harus dilakukan selanjutnya.