CI/CD Adalah: Cara Kerja Pipeline, Contoh, dan Tools

Hampir semua tim pengembang hari ini menyimpan kodenya di Git. Setiap orang bekerja di branch (cabang kerja) masing-masing, lalu perubahannya digabungkan ke cabang utama. Menyimpan kode bukan lagi masalah. Yang sering menjadi masalah adalah kapan dan seberapa sering kode itu digabungkan.

Bayangkan buku kas sebuah toko. Jika transaksi dicocokkan setiap sore, selisih seribu rupiah bisa langsung dilacak ke struk hari itu. Jika baru dicocokkan sebulan sekali, selisih yang sama bisa berasal dari ratusan transaksi, dan mencarinya memakan berhari-hari. Kode bekerja dengan logika yang sama. CI/CD adalah praktik yang memaksa "pencocokan" itu terjadi sesering mungkin dan secara otomatis.

Di artikel ini kita akan membahas apa itu CI/CD dan apa yang terjadi di dalam pipeline-nya. Setelah itu, kita lihat satu contoh berkas workflow yang bisa langsung Anda pakai, pilihan tools beserta kuota gratisnya, dan sisi keamanannya.

Apa Itu CI/CD dan Singkatan dari Apa?

CI/CD adalah serangkaian praktik pengembangan perangkat lunak yang mengotomatiskan penggabungan, pengujian, dan perilisan kode. Tujuannya membuat setiap perubahan kecil langsung diperiksa, sehingga aplikasi selalu berada dalam kondisi siap dirilis. Anda juga akan menemukan penulisan "CI CD" atau "CICD", dan ketiganya merujuk ke hal yang sama.

Kepanjangan CI/CD terdiri dari dua bagian, tetapi huruf keduanya punya dua arti:

1. CI (Continuous Integration): integrasi berkelanjutan. Setiap perubahan kode digabungkan ke cabang utama sesering mungkin, lalu langsung di-build (dirakit menjadi aplikasi yang bisa dijalankan) dan diuji otomatis (automated testing).
2. CD (Continuous Delivery): pengiriman berkelanjutan. Hasil yang lolos uji otomatis disiapkan sampai siap rilis, tetapi keputusan merilis tetap di tangan manusia.
3. CD (Continuous Deployment): penerapan berkelanjutan. Hasil yang lolos uji langsung dirilis ke production (server yang dipakai pengguna sungguhan) tanpa persetujuan manual.

Jadi, jika ditanya CI/CD itu apa, jawabannya adalah praktik, bukan aplikasi. Jenkins, GitHub Actions, atau GitLab CI hanyalah alat yang menjalankannya. Tim yang memasang Jenkins tetapi baru menggabungkan kode sebulan sekali belum menjalankan CI, meskipun servernya menyala setiap hari.

Asal-Usul: Dari Extreme Programming ke Buku Continuous Delivery

Continuous integration lahir dari Extreme Programming (XP), metode pengembangan yang dirumuskan Kent Beck pada akhir 1990-an. Masalah yang ingin dihapus waktu itu punya julukan sendiri: integration hell. Tim bekerja terpisah berminggu-minggu, lalu menghabiskan berhari-hari menggabungkan hasilnya. Memperbaiki satu konflik sering memunculkan dua konflik baru.

Martin Fowler menuliskan praktik ini dalam esai Continuous Integration pada September 2000, lalu memperbaruinya pada Januari 2024. Jez Humble dan David Farley kemudian memperluas gagasan itu sampai ke tahap rilis lewat buku Continuous Delivery (2010), pemenang Jolt Excellence Award 2011.

Continuous Integration: Gabungkan Sedikit, Uji Setiap Kali

Continuous integration adalah kebiasaan menggabungkan perubahan kecil ke cabang utama minimal sekali sehari. Setiap penggabungan memicu proses otomatis yang merakit aplikasi dan menjalankan uji. Jika ada yang rusak, tim tahu dalam hitungan menit, saat perubahannya masih segar di kepala penulisnya.

Kuncinya ada pada ukuran perubahan. Perubahan 30 baris yang gagal uji mudah ditelusuri. Perubahan 3.000 baris hasil kerja tiga minggu yang gagal uji bisa memakan satu hari penuh hanya untuk menemukan bug-nya.

Banyak tim merasa sudah menjalankan CI karena punya server build. Untuk menguji apakah tim Anda benar-benar menerapkannya, ajukan tiga pertanyaan yang diturunkan dari kriteria Fowler:

1. Apakah setiap developer menggabungkan kodenya ke cabang utama minimal sekali sehari? Branch yang hidup berminggu-minggu hanya integrasi setengah jalan, meskipun rutin menarik perubahan. Cabang fitur masih sejalan dengan CI selama umurnya kurang dari sehari.
2. Apakah build dan uji selesai dalam 10 menit atau kurang? Angka 10 menit berasal dari pedoman XP. Pipeline yang butuh 40 menit membuat developer berhenti menunggu hasilnya, dan umpan baliknya kehilangan nilai.
3. Apakah build yang gagal diperbaiki sebelum pekerjaan lain dilanjutkan? Jika cabang utama dibiarkan merah dua hari, semua perubahan sesudahnya menumpuk di atas fondasi rusak.

Jika ketiga jawabannya "ya", tim Anda menjalankan CI. Jika ada satu saja "tidak", alatnya sudah ada, tetapi praktiknya belum.

Continuous Delivery dan Continuous Deployment: Bedanya di Satu Gerbang

Continuous delivery dan continuous deployment berbagi seluruh proses otomatis yang sama, kecuali di langkah terakhir. Pada delivery, ada satu gerbang persetujuan sebelum production yang dibuka manusia, biasanya cukup dengan satu klik. Pada deployment, gerbang itu dihapus dan setiap perubahan yang lolos uji langsung sampai ke pengguna.

Saat orang menyebut CI/CD tanpa penjelasan, huruf CD umumnya berarti continuous delivery. Bagi tim yang baru memulai, delivery juga pilihan yang lebih aman. Aplikasi keuangan atau kesehatan yang setiap rilisnya wajib disetujui auditor bahkan akan tetap di delivery selamanya.

Continuous deployment baru masuk akal jika tiga syarat terpenuhi. Pertama, uji otomatis menangkap kesalahan penting secara konsisten. Kedua, ada pemantauan yang langsung memberi tahu ketika error di production naik. Ketiga, rollback (kembali ke versi sebelumnya) bisa dilakukan dalam hitungan menit.

Pipeline CI/CD: Apa yang Terjadi Setelah Anda Melakukan Push

Pipeline CI/CD (sering juga ditulis CI/CD pipeline) adalah urutan langkah otomatis yang dijalankan setiap kali ada perubahan kode. Pemicunya biasanya push (pengiriman commit ke repository bersama) atau pull request (permintaan menggabungkan cabang). Platform Git mengabarkan peristiwa itu ke sistem CI, sering kali lewat webhook.

Urutan tahap yang umum dipakai adalah sebagai berikut, dan diagram di bawahnya merangkum alur yang sama:

1. Pemicu: push atau pull request masuk, dan pipeline mengambil salinan kode terbaru.
2. Build: dependensi dipasang, kode dikompilasi atau dirakit.
3. Uji cepat: unit test (pengujian fungsi satu per satu) dan linter (pemeriksa gaya dan kesalahan penulisan kode).
4. Uji lebih berat: integration test yang memeriksa beberapa komponen sekaligus, ditambah pemindaian keamanan.
5. Artefak: hasil build dikemas, misalnya berupa folder siap unggah atau container image.
6. Staging: artefak dipasang di staging, lingkungan tiruan production.
7. Production: artefak yang sama dirilis ke pengguna, otomatis atau lewat persetujuan.

Tahap 3 dan 4 sering disebut continuous testing, yaitu pengujian otomatis yang berjalan pada setiap perubahan, bukan hanya menjelang rilis.

Dua prinsip menentukan apakah pipeline ini berguna atau menyiksa. Prinsip pertama adalah fail fast: tahap yang murah dan cepat ditaruh paling depan. Tidak ada gunanya menunggu uji integrasi 8 menit jika kesalahan ketik bisa ditangkap linter dalam 10 detik.

Prinsip kedua adalah build sekali, pakai di semua lingkungan. Artefak yang diuji di staging harus persis sama dengan yang dikirim ke production. Jika production merakit ulang dari kode sumber, Anda tidak lagi merilis hal yang sudah diuji. Versi dependensi bisa saja berubah di antara dua build itu.

Contoh Workflow CI/CD dengan GitHub Actions

Berikut satu contoh pipeline CI/CD berupa berkas workflow GitHub Actions untuk situs web berbasis Node.js yang hasil build-nya berupa folder statis dist/. Workflow ini menguji setiap pull request, dan baru melakukan deploy ketika perubahan sudah masuk ke cabang main.

Simpan berkas berikut di repository Anda dengan nama .github/workflows/deploy.yml:

name: Uji dan Deploy

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  uji:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 26
          cache: npm
      - run: npm ci
      - run: npm test
      - run: npm run build
      - uses: actions/upload-artifact@v7
        with:
          name: situs
          path: dist/

  deploy:
    needs: uji
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/download-artifact@v8
        with:
          name: situs
          path: dist/
      - name: Kirim ke VPS lewat SSH
        env:
          KUNCI: ${{ secrets.SSH_KEY }}
          HOSTS: ${{ secrets.KNOWN_HOSTS }}
          TUJUAN: ${{ secrets.TUJUAN_DEPLOY }}
        run: |
          mkdir -p ~/.ssh
          echo "$KUNCI" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          echo "$HOSTS" > ~/.ssh/known_hosts
          rsync -az --delete dist/ "$TUJUAN"

Bagian-bagian yang perlu Anda pahami:

1. Blok on: pipeline berjalan untuk pull request ke main dan untuk push ke main. Job deploy memeriksa github.event_name == 'push', sehingga pull request hanya diuji dan tidak pernah dirilis.
2. permissions: contents: read: token bawaan workflow hanya boleh membaca repository, sehingga kerusakan terbatas jika ada langkah yang disusupi.
3. timeout-minutes: 10: menegakkan pedoman build cepat, dan uji yang macet tidak menghabiskan kuota menit Anda.
4. upload-artifact dan download-artifact: folder dist/ hasil job uji dibawa utuh ke job deploy, sesuai prinsip build sekali.
5. environment: production: di pengaturan repository, environment ini bisa diberi aturan required reviewers. Dengan aturan itu, workflow berubah dari continuous deployment menjadi continuous delivery, karena deploy menunggu persetujuan satu orang.
6. Langkah SSH: kunci privat, sidik jari server, dan alamat tujuan diambil dari GitHub Secrets, bukan ditulis di berkas. Isi TUJUAN_DEPLOY dengan format user@alamat-server:/var/www/situs/.

Opsi --delete pada rsync menghapus berkas di server yang sudah tidak ada di dist/, sehingga server identik dengan artefak. Karena itu, jangan arahkan tujuannya ke folder yang juga menyimpan unggahan pengguna. Pengiriman berjalan lewat SSH, jadi server tujuan membutuhkan akses SSH dan sebaiknya akun khusus deploy. VPS Indonesia dengan akses root penuh memudahkan pengaturan ini.

Kami memvalidasi berkas di atas dengan actionlint 1.7.12 per 31 Oktober 2026. Versi action yang dipakai adalah yang terbaru saat itu: checkout v7, setup-node v7, upload-artifact v7, dan download-artifact v8.

Pola yang sama berlaku untuk proyek Laravel atau Flutter. Ganti langkah npm dengan perintah proyek Anda. Untuk Laravel, misalnya composer install dan php artisan test; untuk Flutter versi web, flutter test dan flutter build web.

Tools CI/CD dan Kuota Gratisnya

Pilihan tools CI/CD paling praktis ditentukan oleh satu hal: di mana kode Anda disimpan. Platform yang menyatu dengan repository Anda hampir selalu lebih mudah dirawat daripada alat terpisah.

GitHub Actions, GitLab CI/CD, dan Azure Pipelines bisa dijalankan di runner milik Anda sendiri (self-hosted), sedangkan Jenkins memang hanya berjalan di server Anda.

Angka GitHub berasal dari kredit komputasi paket Free sebesar 12 dolar AS per bulan. Dengan tarif runner Linux 2-core 0,006 dolar per menit, kredit itu setara 2.000 menit. Runner Windows dan macOS jauh lebih mahal, sehingga kuotanya habis lebih cepat. AWS CodePipeline memakai skema lain: tipe V1 dihitung 1 dolar per pipeline aktif per bulan, sedangkan tipe V2 dihitung 0,002 dolar per menit eksekusi.

Bagaimana cara memilihnya? Jika kode sudah di GitHub, mulai dari GitHub Actions. Jika di GitLab, pakai GitLab CI/CD. Jenkins layak dipertimbangkan saat Anda membutuhkan plugin khusus atau pipeline harus berjalan di jaringan internal yang tertutup dari internet.

Manfaat CI/CD yang Bisa Diukur

Manfaat CI/CD paling jujur dinilai lewat angka, bukan lewat kesan "rilis jadi lebih cepat". Program riset DORA milik Google memakai lima metrik untuk mengukur kinerja rilis perangkat lunak. Kelimanya bisa Anda baca langsung dari riwayat pipeline:

1. Change lead time: waktu dari commit sampai berjalan di production.
2. Deployment frequency: seberapa sering tim melakukan deploy.
3. Failed deployment recovery time: waktu yang dibutuhkan untuk pulih dari deploy yang gagal.
4. Change fail rate: persentase deploy yang langsung membutuhkan rollback atau perbaikan darurat.
5. Deployment rework rate: persentase deploy tak terencana yang terjadi akibat insiden di production.

Tiga metrik pertama mengukur kecepatan, dua terakhir mengukur kestabilan. CI/CD yang sehat memperbaiki keduanya, karena perubahan kecil lebih cepat sampai ke production dan lebih mudah ditelusuri ketika rusak.

Laporan DORA 2025 dari survei terhadap hampir 5.000 profesional teknologi menambah satu alasan. Sekitar 90% responden kini memakai AI dalam pekerjaannya. AI terbukti menaikkan jumlah perubahan yang dirilis, tetapi juga ketidakstabilan. Ketika volume kode naik, pipeline yang menguji setiap perubahan berfungsi sebagai rem pengaman. Penjelasan lengkap metrik ini ada di artikel kami tentang DevOps.

Kelemahan CI/CD dan Hal yang Perlu Anda Pertimbangkan

CI/CD tidak gratis, baik dari sisi waktu maupun risiko. Berikut hal yang perlu Anda timbang:

1. Uji otomatis harus ditulis dan dirawat: pipeline secepat apa pun tidak berarti tanpa uji yang bermakna. Menulis uji untuk kode lama yang belum pernah diuji bisa memakan waktu berminggu-minggu.
2. Uji yang tidak stabil merusak kepercayaan: flaky test adalah uji yang kadang lolos dan kadang gagal tanpa perubahan kode. Jika tim terbiasa menekan "jalankan ulang", warna merah berhenti dianggap serius.
3. Pipeline lambat akan diakali: build yang lebih dari 10 menit mendorong developer menggabungkan perubahan lebih jarang. Akibatnya, tujuan CI berbalik arah.
4. Pipeline adalah sasaran serangan: pipeline menyimpan kunci server dan token rilis. Pada 14–15 Maret 2025, action populer tj-actions/changed-files disusupi dan mencetak secret ke log publik. Action ini dipakai lebih dari 23.000 repository, dan peneliti Endor Labs menemukan sekitar 218 di antaranya benar-benar membocorkan secret.
5. Pipeline hijau bukan jaminan fitur benar: uji hanya memeriksa hal yang terpikir untuk diuji. Pemantauan di production tetap dibutuhkan.
6. Tidak selalu sepadan: situs profil perusahaan yang diubah sebulan sekali tidak membutuhkan pipeline bertahap. Menyusunnya bisa lebih lama daripada seluruh deploy manual selama setahun.

Untuk poin keempat, langkah pengamannya cukup konkret. Kunci action pihak ketiga ke commit SHA (sidik unik satu versi kode), bukan ke tag yang bisa dipindahkan pemiliknya. Contohnya actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 untuk checkout v7.0.1. Batasi juga izin token seperti contoh workflow di atas, dan ganti secret segera jika ada action yang Anda pakai dilaporkan disusupi. Kebiasaan memasang pemeriksaan keamanan di dalam pipeline seperti ini dikenal sebagai DevSecOps.

Cara Mulai Menerapkan CI/CD di Proyek Kecil

Sebelum memasang pipeline, pastikan kode sudah di Git dan aplikasi bisa di-build dengan satu perintah. Pastikan juga sudah ada beberapa uji otomatis, dan tidak ada password atau kunci di dalam repository. Setelah itu, terapkan secara bertahap.

Langkah #1: Jalankan Uji di Setiap Pull Request

Mulai dari job uji saja, tanpa deploy. Targetkan pipeline selesai di bawah 5 menit agar tim terbiasa menunggu hasilnya. Biarkan berjalan satu sampai dua minggu sampai tidak ada lagi uji yang gagal secara acak.

Langkah #2: Lindungi Cabang Utama

Aktifkan aturan perlindungan branch agar main hanya bisa menerima pull request yang lolos pipeline. Sejak langkah ini, cabang utama dijamin selalu bisa di-build.

Langkah #3: Deploy Otomatis ke Staging

Tambahkan job deploy yang mengarah ke server staging setiap kali main berubah. Pakai artefak yang sama dengan yang diuji, seperti contoh workflow di atas. Pada tahap ini Anda sudah menjalankan continuous delivery ke staging.

Langkah #4: Buka Jalur ke Production dengan Persetujuan

Arahkan deploy ke production lewat environment yang membutuhkan persetujuan satu orang. Setelah tim melewati sekitar 20 rilis tanpa insiden dan proses rollback sudah teruji, barulah pertimbangkan menghapus persetujuan itu menjadi continuous deployment.

Pilihan strategi rilis di tahap ini, seperti blue-green atau canary, kami bahas di artikel tentang deployment.

Pertanyaan yang Sering Muncul

Apa bedanya CI/CD dan DevOps?

DevOps adalah budaya dan cara kerja yang menyatukan tim pengembang dan tim operasional. CI/CD adalah salah satu praktik teknis di dalamnya, khusus untuk jalur dari kode sampai rilis. Tim bisa memiliki pipeline CI/CD tanpa menerapkan DevOps, tetapi sulit menerapkan DevOps tanpa CI/CD.

Apa bedanya CI/CD dan Agile?

Agile adalah cara merencanakan dan mengerjakan perangkat lunak dalam iterasi pendek, misalnya sprint dua minggu. CI/CD adalah mekanisme teknis yang membuat hasil setiap iterasi bisa diuji dan dirilis kapan saja. Keduanya saling melengkapi: Agile mengatur ritme kerja, CI/CD memastikan ritme itu tidak macet di tahap rilis.

Apakah CI/CD harus memakai Docker atau Kubernetes?

Tidak. Contoh workflow di atas tidak memakai keduanya. Docker berguna agar build dan uji berjalan di lingkungan yang seragam, sedangkan Kubernetes baru relevan ketika aplikasi berjalan di banyak container sekaligus. Keduanya pelengkap, bukan syarat.

Bisakah CI/CD dipakai untuk website di shared hosting?

Bisa, selama hosting menyediakan akses SSH. Pipeline dapat mengirim hasil build lewat rsync seperti contoh di atas. Panel cPanel juga punya fitur Git Version Control yang bisa menjalankan deploy dari berkas .cpanel.yml. Untuk hosting tanpa SSH, pilihan yang tersisa adalah mengunggah lewat FTP, yang lebih lambat dan kurang aman.

Apa arti CI di perusahaan?

Jawaban atas pertanyaan "CI itu apa" bergantung pada konteksnya. Di luar dunia pengembangan perangkat lunak, CI umumnya berarti corporate identity, yaitu identitas visual perusahaan seperti logo, warna, dan jenis huruf. Maknanya sama sekali tidak berhubungan dengan continuous integration. Konteks kalimat yang menentukan arti mana yang dimaksud.

CD artinya apa, apakah sama dengan compact disc?

Dalam CI/CD, CD artinya continuous delivery atau continuous deployment. Singkatan CD yang lebih umum di luar konteks ini adalah compact disc, cakram optik untuk menyimpan musik dan data. Keduanya hanya kebetulan memakai singkatan yang sama.

Kesimpulan

CI/CD adalah praktik menggabungkan perubahan kecil sesering mungkin, mengujinya otomatis, lalu menjaga aplikasi selalu siap dirilis. Continuous integration memastikan kode yang digabungkan selalu bisa di-build. Continuous delivery memastikan hasilnya siap rilis kapan saja, dan continuous deployment melangkah lebih jauh dengan merilisnya otomatis.

Mulailah dari uji otomatis di setiap pull request, lalu tambah tahapnya sedikit demi sedikit. Untuk situs yang jarang berubah, deploy manual yang rapi dengan backup masih memadai. Begitu rilis terjadi beberapa kali seminggu, pipeline menghemat lebih banyak waktu daripada yang dibutuhkan untuk menyusunnya.

Semoga artikel ini membantu.