Memilih tools CI/CD bukan sekadar memilih file YAML yang paling mudah ditulis. Pipeline akan menjadi jalur resmi setiap perubahan kode menuju production. Ia menyentuh credential, artifact, runner, approval, rollback, dan biaya compute. Pilihan yang salah biasanya baru terasa ketika build mulai lama, runner kehabisan kapasitas, atau satu token deployment bocor dari log.

Apa yang sebenarnya dilakukan platform CI/CD

CI/CD platform biasanya menangani beberapa pekerjaan berbeda:

  • Continuous Integration: checkout kode, install dependency, lint, unit test, integration test, dan build artifact.
  • Continuous Delivery: menyimpan artifact, menjalankan approval, lalu menyiapkan release yang bisa dideploy.
  • Continuous Deployment: meneruskan release ke environment target tanpa approval manual.
  • Orchestration: menentukan dependency antar job, parallelism, retry, cache, dan environment variable.
  • Evidence: menyimpan log, test report, artifact, dan audit trail.

Satu produk bisa kuat di orchestration tetapi lemah di runner, atau sebaliknya. Karena itu bandingkan workflow lengkap, bukan hanya syntax pipeline.

GitHub Actions

GitHub Actions cocok ketika source code, pull request, issue, dan release sudah berada di GitHub. Workflow disimpan di .github/workflows/*.yml dan dapat berjalan pada hosted runner GitHub atau self-hosted runner.

name: test
on:
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test -- --runInBand
      - run: npm run build

Kekuatan utamanya adalah integrasi pull request dan marketplace action. Risiko utamanya adalah action pihak ketiga memiliki supply-chain risk. Pin action ke commit SHA untuk workload sensitif, batasi permission GITHUB_TOKEN, dan jangan memberi secret production ke job pull request dari fork.

GitHub-hosted runner praktis untuk workload yang tidak memerlukan akses private network. Self-hosted runner memberi kontrol network dan cache, tetapi kamu harus mengurus patching, isolation, cleanup workspace, dan kemungkinan persistence secret di mesin runner.

GitLab CI/CD

GitLab menyimpan pipeline di .gitlab-ci.yml. Runner dapat memakai Docker, shell, Kubernetes, atau executor lain. GitLab kuat untuk repository, registry, security scanning, environments, dan deployment workflow dalam satu platform.

stages: [test, build]

unit-test:
  stage: test
  image: node:22-bookworm
  script:
    - npm ci
    - npm test -- --runInBand

build-image:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  script:
    - docker build -t registry.example.com/app:$CI_COMMIT_SHA .
    - docker push registry.example.com/app:$CI_COMMIT_SHA

GitLab menarik untuk perusahaan yang ingin source control, registry, runner, environment, dan security dashboard lebih terintegrasi. Perhatikan model biaya runner, ukuran instalasi self-managed, dan kebutuhan upgrade jika GitLab dioperasikan sendiri.

Jenkins

Jenkins adalah automation server yang sangat fleksibel. Pipeline bisa ditulis dalam Jenkinsfile, didefinisikan melalui UI, atau dibangun dari plugin. Fleksibilitas ini adalah keunggulan sekaligus beban operasi.

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        sh 'npm ci'
        sh 'npm test -- --runInBand'
      }
    }
    stage('Build') {
      steps { sh 'docker build -t app:${GIT_COMMIT} .' }
    }
  }
}

Jenkins masih masuk akal ketika organisasi memiliki banyak sistem lama, plugin khusus, atau topology agent yang sudah matang. Kekurangannya: plugin perlu dipatch, controller perlu diamankan, credential binding harus benar, dan konfigurasi yang tersebar di UI sulit diaudit. Jenkins bukan pilihan ringan untuk tim yang baru membangun pipeline dari nol.

CircleCI dan Buildkite

CircleCI menawarkan managed CI dengan konfigurasi YAML, parallelism, caching, dan orb. Ia cocok untuk tim yang tidak ingin mengelola controller atau runner utama. Periksa lokasi data, akses private network, dan biaya berdasarkan credit ketika workflow makin sering berjalan.

Buildkite memisahkan control plane yang dikelola vendor dari agent yang berjalan di infrastruktur kamu. Model ini menarik jika pipeline perlu akses VPC, Kubernetes cluster, atau cache internal, tetapi tim tetap ingin UI dan orchestration managed. Biaya operasional berpindah ke agent fleet: patching, autoscaling, dan isolation tetap tanggung jawab kamu.

Azure Pipelines, Bitbucket Pipelines, dan Gitea Actions

Azure Pipelines cocok pada organisasi yang sudah memakai Azure DevOps Boards, Repos, Artifacts, dan Microsoft ecosystem. Ia mendukung hosted maupun self-hosted agent dengan environment dan approval yang cukup lengkap.

Bitbucket Pipelines praktis jika repository berada di Bitbucket dan workload relatif standar. Integrasi vendor mengurangi glue code, tetapi pilihan dan ekosistemnya perlu dibandingkan dengan GitHub atau GitLab sebelum migrasi.

Gitea Actions memakai konsep workflow yang kompatibel dengan banyak workflow GitHub Actions. Ini menarik untuk instalasi self-hosted yang mengutamakan kontrol data dan biaya, tetapi ukuran ecosystem action, dokumentasi, dan kemampuan managed service tidak sama dengan platform besar.

Perbandingan singkat

Platform Kekuatan Beban operasi Cocok untuk
GitHub Actions PR integration, marketplace, hosted runner Rendah sampai sedang Repo GitHub dan tim product
GitLab CI Runner, registry, security, environments Rendah managed, tinggi self-managed Platform engineering terpadu
Jenkins Fleksibilitas dan plugin Tinggi Legacy dan kebutuhan custom
CircleCI Managed CI, caching, parallelism Rendah Tim yang ingin fokus pada kode
Buildkite Managed control plane, agent private Sedang Enterprise dengan VPC internal
Azure Pipelines Azure DevOps integration Rendah sampai sedang Ekosistem Microsoft
Gitea Actions Self-hosted dan data control Sedang Infrastruktur mandiri atau edge

Tidak ada ranking universal. Pilihan terbaik bergantung pada lokasi source code, kebutuhan network, tingkat compliance, jumlah build, skill tim, dan budget runner.

Runner dan isolation

Runner adalah tempat kode pipeline benar-benar dieksekusi. Hosted runner memberikan baseline yang praktis, tetapi environment ephemeral dan akses private biasanya terbatas. Self-hosted runner dapat mengakses resource internal, namun memperluas blast radius: job yang tidak terpercaya berjalan di mesin yang kamu miliki.

Untuk runner self-hosted:

  • Jangan menjalankan job pull request yang tidak terpercaya pada runner production.
  • Gunakan ephemeral VM atau pod agar workspace tidak menyimpan secret dan artifact lama.
  • Batasi network egress dan akses ke metadata service.
  • Pisahkan runner build umum dari runner deployment.
  • Bersihkan Docker socket; akses /var/run/docker.sock setara akses root terhadap host.
  • Pantau CPU, disk, queue time, dan runner health.

Kubernetes runner mempercepat provisioning, tetapi menambah kompleksitas cluster, RBAC, image supply chain, dan cleanup pod. Jangan memilih Kubernetes hanya karena pipeline terlihat modern.

Secrets, artifact, dan supply chain

Secret harus disimpan di secret store platform atau external secret manager. Jangan mencetak environment variable, token, atau credential ke log. Gunakan OIDC federation bila cloud provider mendukungnya agar pipeline memperoleh credential berumur pendek tanpa menyimpan static cloud key.

Artifact harus immutable dan dapat ditelusuri ke commit. Gunakan image tag berbasis commit SHA, simpan SBOM, scan dependency serta container image, dan verifikasi signature sebelum deploy. Tag latest nyaman untuk demo tetapi buruk untuk rollback dan audit.

Pin dependency action, Docker base image, dan package lockfile. Review perubahan pipeline seperti review source code karena pipeline dapat menjalankan arbitrary command dengan hak akses tinggi.

Deployment strategy

Pipeline yang baik memisahkan build dari deploy. Build sekali, hasilkan artifact immutable, lalu promosikan artifact yang sama dari staging ke production. Jangan rebuild saat production deploy karena hasilnya bisa berbeda dari hasil test.

Untuk layanan web, pilihan deployment meliputi:

  • Rolling: sederhana dan hemat resource, tetapi perlu backward compatibility.
  • Blue-green: rollback cepat, tetapi butuh kapasitas dua versi.
  • Canary: risiko lebih kecil untuk traffic nyata, namun routing dan observability lebih kompleks.
  • Feature flag: deploy kode lebih dulu, aktifkan fitur belakangan; memerlukan disiplin cleanup flag.

Approval manual bukan pengganti test. Ia hanya menambah titik keputusan. Pastikan rollback command dan prosedur database migration sudah diuji.

Contoh pipeline yang sehat

Urutan yang umum:

  1. Validate YAML dan dependency lockfile.
  2. Lint dan unit test secara parallel.
  3. Integration test dengan database atau service ephemeral.
  4. Build artifact atau container image.
  5. Scan dependency, image, dan IaC.
  6. Publish artifact immutable.
  7. Deploy staging.
  8. Smoke test dan migration check.
  9. Approval bila memang dibutuhkan.
  10. Deploy production dan monitor rollback signal.

Durasi pipeline harus diukur. Cache membantu, tetapi cache yang korup atau tidak invalid dapat membuat hasil menyesatkan. Simpan test report meskipun job gagal agar root cause tidak hilang.

Kesalahan yang sering terjadi

  • Semua job dijalankan serial sehingga feedback lambat.
  • Satu runner dipakai untuk test untrusted dan deployment production.
  • Secret disimpan di repository atau ditulis ke log.
  • Pipeline hanya menguji happy path dan tidak punya rollback.
  • Image dibuild ulang di setiap environment.
  • Migration database dijalankan tanpa backward compatibility.
  • Action/plugin dipakai tanpa pin versi atau review source.
  • CI dianggap berhasil hanya karena build selesai, tanpa smoke test dan metrics deploy.

Cara memilih untuk beberapa skenario

Untuk tim kecil dengan source di GitHub, mulai dengan GitHub Actions dan hosted runner. Tambahkan self-hosted runner hanya ketika private network atau kebutuhan compute memang jelas.

Untuk organisasi yang ingin platform terpadu dan sudah memakai GitLab, GitLab CI mengurangi integrasi antarproduk. Self-hosted GitLab perlu owner yang bertanggung jawab atas upgrade, backup, dan security response.

Untuk organisasi dengan Jenkins lama, migrasi tidak selalu harus sekaligus. Standarkan Jenkinsfile, kurangi plugin, pindahkan credential ke secret manager, lalu migrasikan workload satu per satu jika biaya maintenance sudah lebih besar daripada manfaat kompatibilitas.

Checklist sebelum memilih

  • [ ] Source code berada di platform mana?
  • [ ] Pipeline perlu akses private network atau cloud account apa?
  • [ ] Hosted runner cukup atau wajib self-hosted?
  • [ ] Berapa build per hari dan berapa concurrency yang dibutuhkan?
  • [ ] Bagaimana secret, OIDC, artifact, dan SBOM dikelola?
  • [ ] Siapa yang patch runner, plugin, dan controller?
  • [ ] Apakah rollback dapat dijalankan dengan satu artifact immutable?
  • [ ] Apakah audit log dan retention memenuhi kebutuhan organisasi?
  • [ ] Bagaimana biaya dihitung ketika jumlah repository dan build meningkat?

Tools CI/CD yang baik bukan yang punya fitur paling banyak. Yang lebih penting adalah pipeline dapat dipahami, hasil build dapat direproduksi, credential terisolasi, dan tim mampu memulihkan deployment yang gagal tanpa menebak-nebak.