CI/CD Integration Testing: Panduan Praktis Pipeline

Perubahan pada layanan pembayaran bisa saja lolos ribuan unit test namun tetap merusak produksi karena billing API menginterpretasikan idempotency key secara berbeda dari ekspektasi layanan. Kegagalan ini mungkin tidak terdeteksi sampai nightly integration job mencapai interface, jauh setelah commit melewati bagian pipeline yang cepat.

Itulah masalah operasional pada Pengujian integrasi CI/CD. Unit test membuktikan bahwa logika terisolasi berjalan dengan benar. Integration test memberikan bukti bahwa komponen, service, schema, queue, dan dependensi eksternal masih sinkron. Dalam pipeline delivery modern, bukti tersebut harusnya membantu keputusan triage, bukan menjadi penghalang berupa deretan pengecekan lambat yang akhirnya diabaikan developer.

CI/CD telah menjadi model software delivery yang mainstream. Sebuah Laporan DevOps testing 2024 dari mabl menyebut hampir 90% organisasi global memprioritaskan transformasi DevOps, sementara sedikit di bawah 50% tester yang terlibat dalam mendefinisikan dan memelihara proses CI/CD dan hanya 10% organisasi melaporkan bahwa mereka sama sekali tidak melakukan deploy CI/CD. Konsekuensi praktisnya jelas: verifikasi integrasi kini harus berjalan pada skala delivery.

Table of Contents

• Mengapa integration testing adalah control point CI/CD
  • Bangun control point secara sengaja
• Posisi integration test di antara unit dan end-to-end
  • Tiga pola integrasi yang berguna
• Mengelola environment dan data untuk test yang representatif
  • Urutan job yang dapat direproduksi
  • Gunakan virtualisasi secara terarah
• Contoh Pipeline untuk GitHub Actions, GitLab CI, dan Jenkins
  • Aksi GitHub
  • GitLab CI
  • Jenkins
• Taktik Keandalan untuk Flaky Integration Test
  • Ukur dulu sebelum mengubah kebijakan
  • Hilangkan penyebab umum
• Kebijakan Gating dan Aturan Promosi Deployment
  • Gunakan gate khusus tiap stage
  • Buat bypass terlihat jelas
• Checklist Adopsi dan Observability untuk Kepercayaan Jangka Panjang
  • Tahap satu, buat sinyal yang ada bisa dipercaya
  • Tahap dua, tingkatkan kemiripan lingkungan
  • Tahap tiga, hubungkan observabilitas ke triage

Mengapa integration testing adalah control point CI/CD

Integration testing adalah saat risiko rilis menjadi nyata. Unit test bisa mengonfirmasi bahwa payment handler memformat idempotency key dengan benar, tetapi hanya integration test yang bisa membuktikan bahwa handler, HTTP client, billing API, persistence layer, dan retry behavior bekerja selaras saat beroperasi bersama.

Hal ini menjadikan tahap integrasi sebagai titik kontrol alami antara continuous integration dan continuous delivery. Sebuah commit tidak boleh dianggap layak deploy hanya karena unit test-nya sudah green. Commit itu harus memperoleh promosi dengan menghasilkan bukti tepercaya bahwa interface yang diubahnya masih berfungsi dalam pengaturan mirip produksi.

Perbedaan ini penting karena integrasi yang sering tanpa verifikasi otomatis hanya memindahkan defect lebih cepat. Tinjauan sistematis atas pendekatan peningkatan CI/CD mengidentifikasi prioritas yang berulang, termasuk mengurangi waktu build dan test, meningkatkan visibilitas hasil, mendukung continuous testing, mendeteksi kesalahan, dan meningkatkan keandalan deployment. Tinjauan lain dalam catatan riset yang sama mendefinisikan continuous integration sebagai integrasi code yang sering, diverifikasi oleh automated build yang menyertakan test, sehingga defect bisa dideteksi dengan cepat.

Bangun control point secara sengaja

Mulailah dengan mengklasifikasikan integration test berdasarkan keputusan yang didukungnya:

• Pengujian yang memblokir (blocking tests) melindungi kontrak kritikal dan dijalankan secara sinkron sebelum merge atau promosi.
• Tes yang dikarantina tetap terlihat dan terus memberikan bukti, namun tidak menghambat delivery saat tim sedang menginvestigasi ketidakstabilan.
• Pengujian asinkron menguji workflow yang lebih luas, komposisi staging penuh, atau infrastruktur mahal setelah commit lolos dari fast gate.

Ini lebih berguna daripada berdebat apakah setiap test harus "masuk CI." Pertanyaan yang tepat adalah apakah sebuah test cukup reliabel dan bernilai untuk memengaruhi keputusan promosi tertentu.

Aturan praktis: Gunakan gate berdasarkan bukti integrasi yang stabil, bukan sekadar keberadaan suite integrasi.

Sisa implementasinya mengikuti aturan tersebut. Gunakan dependency yang mirip produksi di mana interface bisa gagal, jalankan pengecekan independen secara paralel, ukur false failures, dan tentukan kondisi eksplisit untuk quarantine dan promosi. Tim yang ingin menghubungkan pekerjaan ini ke praktik delivery yang lebih luas juga dapat meninjau manfaat continuous integration.

Posisi integration test di antara unit dan end-to-end

Testing pyramid adalah model biaya, bukan hukum yang kaku. Unit test berjalan cepat karena mengisolasi fungsi, class, atau modul. Kecepatan ini membuatnya ideal untuk feedback instan, namun penggunaan mock dapat menyembunyikan kegagalan yang justru terjadi pada sistem seams, seperti perbedaan serialisasi, batasan database, konfigurasi autentikasi, atau perilaku queue.

End-to-end test mengambil posisi sebaliknya. Test ini menjalankan user journey di seluruh stack, sehingga sangat berharga untuk workflow berisiko tinggi. Test ini juga melewati batas browser, jaringan, service, dan infrastruktur, sehingga diagnosis dan stabilitasnya menjadi lebih sulit. Jika setiap merge harus menunggu seluruh rangkaian end-to-end, developer akan menerima sinyal lambat yang seringkali kurang informatif dibandingkan integration test terfokus pada level API.

Integration test berada di tengah-tengah. Test ini menggunakan dependency asli atau yang mendekati asli untuk memverifikasi perilaku service-to-service tanpa memerlukan orkestrasi UI yang lengkap. Layer ini dapat mencakup panggilan HTTP dan gRPC, publishing queue, migrasi database, interaksi cache, serta kompatibilitas schema.

Tiga pola integrasi yang berguna

In-process component test dengan Testcontainers jalankan komponen aplikasi bersamaan dengan dependensi seperti PostgreSQL, Redis, atau Kafka. Pola ini sepadan dengan biaya setup-nya jika risiko defect melibatkan persistensi, serialisasi, transaksi, atau semantik broker. Ini memberikan dependensi nyata pada test namun tetap menjaga batasan test tetap sempit.

Contract test antar-service dengan Pact atau schema registry fokus pada kesepakatan antara consumer dan provider. Ini pilihan tepat saat tim merilis service secara independen dan butuh feedback cepat terkait contract drift. Contract test tidak seharusnya menggantikan behavioral integration test, tapi bisa mencegah interface yang tidak kompatibel masuk ke shared environment.

Test level API terhadap staging stack yang terkomposisi memanggil beberapa service yang sudah dideploy melalui network path aslinya. Gunakan pola ini untuk workflow di mana routing, autentikasi, service discovery, konfigurasi deployment, atau kebijakan infrastruktur sangat krusial. Pastikan set test fokus pada jalur bisnis yang kritis, karena staging stack penuh lebih mahal untuk di-provision dan lebih sulit diisolasi saat terjadi kegagalan.

Jaga agar rangkaian merge sinkron tetap ringkas. Target praktisnya adalah menjaga jalur integrasi di bawah 10 menit per merge commit, lalu pindahkan skenario luas ke eksekusi asinkron. Tim yang ingin fondasi lebih luas untuk pembagian ini dapat meninjau apa saja cakupan automated testing, namun prinsip utamanya tetap sederhana: investasikan biaya untuk realisme yang memengaruhi keputusan rilis.

Mengelola environment dan data untuk test yang representatif

Test yang berjalan di environment yang salah bisa memberikan rasa percaya diri palsu. Test di shared environment yang tidak stabil bisa menyebabkan false failure. Agar andal, integration testing CI/CD membutuhkan strategi environment yang membuat batasan dependency menjadi eksplisit dan state data dapat direproduksi.

Mulailah dengan dependency yang bisa dijalankan secara akurat. Testcontainers dapat menyediakan instance PostgreSQL, Redis, dan Kafka yang disposable untuk setiap job. Keuntungan utamanya bukan pada Docker itu sendiri, melainkan kontrol atas versi, konfigurasi, startup, dan teardown.

Urutan job yang dapat direproduksi

Gunakan urutan yang tetap daripada membiarkan code melakukan improvisasi setup:

1. Jalankan dependency. Boot container PostgreSQL, lalu tunggu health check yang nyata daripada berasumsi bahwa proses yang sedang berjalan sudah siap menerima traffic.
2. Jalankan migrasi. Gunakan jalur migrasi yang sama dengan aplikasi. Jangan buat skema test manual yang bisa berbeda dari produksi.
3. Muat fixture deterministik. Hanya masukkan data yang diperlukan untuk skenario tersebut, dan berikan data terisolasi pada setiap job agar proses paralel tidak saling mengubah state satu sama lain.
4. Jalankan contract assertion. Verifikasi format request, perilaku response, event schema, transisi status, dan hasil persistensi.
5. Bersihkan semua data. Hapus container dan volume sementara meski test gagal, agar job berikutnya tidak mewarisi state yang korup.

Booting PostgreSQL selama 90 detik adalah biaya yang wajar jika bisa menangkap defect migrasi dan transaksi. Menggunakan staging cluster penuh adalah keputusan berbeda. Ini memakan lebih banyak infrastruktur, memicu configuration drift, dan menambah titik kegagalan. Mulailah dengan environment yang paling ramping, lalu perluas saat cakupan contract atau insiden produksi menunjukkan adanya failure mode yang terlewat.

Gunakan virtualisasi secara terarah

Beberapa sistem pihak ketiga tidak bisa di-provision dengan aman di setiap pipeline. WireMock, Mountebank, dan Hoverfly bisa mensimulasikan dependency tersebut, namun simulasi harus diperlakukan sebagai contract yang terawat, bukan sekadar jalan pintas. Mock yang hanya mengembalikan response ideal tidak akan mengungkap masalah expiry autentikasi, rate limiting, payload malformed, penanganan timeout, atau evolusi schema.

Ephemeral preview environment sangat berguna saat risiko bergantung pada beberapa layanan yang dideploy bersamaan. Docker Compose bisa menyediakan komposisi lokal dan CI yang ringkas, sementara Kubernetes namespace dapat mengisolasi environment pull-request jika perilaku deployment itu sendiri perlu diuji. Pendekatan apa pun yang Anda gunakan, pastikan versi dependency dipaku (pin) dan catat konfigurasi yang digunakan pada setiap run.

Secrets membutuhkan disiplin yang sama dengan data. Simpan kredensial di luar test fixtures dan lakukan rotasi akses melalui mekanisme proteksi platform. Panduan Capgo untuk mengelola secrets di pipeline CI/CD memberikan panduan relevan agar nilai sensitif tidak masuk ke konfigurasi repository.

Walkthrough visual singkat dapat membantu tim menyelaraskan lifecycle environment:

Contoh Pipeline untuk GitHub Actions, GitLab CI, dan Jenkins

Runner kurang penting dibandingkan struktur workflow. Build sekali, sediakan dependency secara terprediksi, bagi grup test yang independen, publish hasil yang dapat dibaca mesin, dan buat batasan blocking menjadi jelas. Sintaksis mungkin berbeda antar platform, tetapi aturan operasional tersebut tetap konsisten.

Aksi GitHub

Matrix bekerja dengan baik saat integration test dapat dibagi berdasarkan domain atau shard. Service container menjaga dependency tetap dekat dengan runner, sementara output JUnit memberikan format hasil yang stabil bagi pull request dan sistem downstream.

name: integration

on:
  pull_request:

jobs:
  integration:
    strategy:
      fail-fast: false
      matrix:
        suite: [billing, orders, notifications]
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: app_test
        options: >-
          --health-cmd "pg_isready -U postgres -d app_test"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 12
      redis:
        image: redis:7
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run test:integration, --suite=${{ matrix.suite }}
      - if: always()
        uses: actions/upload-artifact@v4
        with:
          name: junit-${{ matrix.suite }}
          path: test-results/*.xml

Pinning versi action dan dependency mengurangi environment drift. GitHub Actions menyediakan paralelisme terutama melalui matrix dan job terpisah, jadi gunakan matrix hanya jika setiap shard memiliki data terisolasi dan durasi yang terprediksi.

GitLab CI

GitLab CI dapat memisahkan tahap persiapan, eksekusi test, dan reporting. Child pipelines sangat berguna jika repositori besar mengelola banyak service dengan environment integrasi yang berbeda. Artifacts akan menjaga hasil JUnit tetap ada meskipun job test gagal.

stages:
  - build
  - integration

build-image:
  stage: build
  script:
    - docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

integration:
  stage: integration
  parallel:
    matrix:
      - SUITE: [billing, orders, notifications]
  image: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  services:
    - name: postgres:16
      alias: postgres
    - name: redis:7
      alias: redis
  script:
    - ./scripts/migrate-test-db.sh
    - npm run test:integration, --suite="$SUITE" --reporter=junit
  artifacts:
    when: always
    reports:
      junit: test-results/*.xml

Gunakan GitLab child pipelines jika kepemilikan service atau topologi deployment membuat satu file monolitik sulit dikelola. Biarkan parent pipeline bertanggung jawab atas keputusan promosi, agar tidak terjadi kondisi di mana satu child pipeline pass sementara sinyal rilis keseluruhannya tetap ambigu.

Jenkins

Jenkins berguna saat tim membutuhkan self-hosted agents atau akses jaringan khusus. Jenkinsfile deklaratif dapat menetapkan Docker-based agents dan menjalankan suite secara paralel, namun tim harus mengelola maintenance plugin, controller, agent, dan image.

pipeline {
  agent none

  stages {
    stage('Build') {
      agent { docker 'node:22' }
      steps {
        sh 'npm ci'
        sh 'npm run build'
        stash name: 'build', includes: 'dist/**'
      }
    }

    stage('Integration') {
      parallel {
        stage('Billing') {
          agent { docker 'my-org/integration-runner:stable' }
          steps {
            unstash 'build'
            sh './scripts/start-test-dependencies.sh'
            sh 'npm run test:integration, --suite=billing'
          }
        }
        stage('Orders') {
          agent { docker 'my-org/integration-runner:stable' }
          steps {
            unstash 'build'
            sh './scripts/start-test-dependencies.sh'
            sh 'npm run test:integration, --suite=orders'
          }
        }
      }
    }
  }

  post {
    always {
      junit 'test-results/*.xml'
    }
  }
}

Untuk tim yang sudah menggunakan GitHub, build dan release otomatis dengan GitHub Actions dapat memberikan pola deployment yang berguna. Pilihan desain pentingnya tetap sama untuk ketiga runner: jangan jadikan setiap test yang berat sebagai blocker merge sinkron.

Taktik Keandalan untuk Flaky Integration Test

Retry berguna untuk diagnosis, tapi blanket retry adalah strategi reliabilitas yang buruk. Ini bisa mengubah defect nyata menjadi build hijau, menyembunyikan instabilitas lingkungan, dan membuat dashboard pass-rate terlihat lebih sehat dari kondisi pipeline sebenarnya.

Skala masalah ini terlihat dari data engineering yang dipublikasikan. Google melaporkan sekitar 16% pengujian mengalami flakiness dan sekitar 1,5% dari seluruh test run menghasilkan hasil yang flaky, sementara studi lain menemukan 4,56% kegagalan tes Google disebabkan oleh flaky test, sebagaimana dirangkum dalam panduan AWS continuous integration and delivery testing. Data Google juga menunjukkan sekitar 84% transisi CI dari pass-ke-fail adalah flaky, bukan bug sebenarnya, dan proyek Microsoft melaporkan sekitar 4,6% flaky test dalam sebuah studi, menurut tinjauan statistik flaky test dari Panto.

Ukur dulu sebelum mengubah kebijakan

Pantau flakiness sebagai:

jumlah kegagalan flaky ÷ total eksekusi × 100

Gunakan jendela 7 hingga 30 hari, dan hitung berdasarkan suite, test, runner image, dependency, dan environment. Test yang gagal hanya pada satu runner memiliki masalah remediasi yang berbeda dengan test yang gagal di setiap environment.

Gunakan kategori triage ini:

• Kegagalan Produk: blokir gate terkait dan perbaiki code atau contract.
• Kegagalan Environment: perbaiki health checks, resource limits, networking, atau setup dependency.
• Kegagalan test: perbaiki urutan assertion, shared state, timing, cleanup, atau desain fixture.
• Instabilitas tidak terklasifikasi: karantina sementara, tapi tentukan owner dan tanggal kedaluwarsanya.

Hilangkan penyebab umum

Shared mutable state menyebabkan ketergantungan urutan. Berikan setiap job schema yang terisolasi, identifier unik, atau boundary rollback transaksi. Sistem asinkron butuh polling berbasis kondisi dengan timeout terbatas, bukan sleep sembarangan. Inject clock ke dalam logika ekspirasi, dan tunggu container health alih-alih hanya menunggu proses startup.

Sharding mengurangi wall-clock time, tapi tidak memperbaiki test yang buruk. Jalankan shard secara independen, simpan logs untuk setiap shard, dan jalankan ulang hanya test atau shard yang gagal untuk diagnosis. Jangan jalankan ulang seluruh pipeline hanya karena satu integration check mengalami kegagalan lingkungan.

Sebuah test hanya bisa keluar dari karantina setelah memenuhi kebijakan stabilitas yang ditentukan, seperti eksekusi green berturut-turut di semua environment tempat ia akan berjalan. Ambang batas pastinya harus ditentukan oleh tim dan dicatat dalam kebijakan. Bagian terpenting adalah promosi didapatkan melalui stabilitas yang teramati, bukan sekadar menghapus label karantina.

Kebijakan Gating dan Aturan Promosi Deployment

Quality gate harus menjawab satu pertanyaan: apakah artifact ini punya bukti yang cukup terpercaya untuk pindah ke environment berikutnya? Ia tidak boleh menjadi tempat pembuangan untuk setiap test yang telah dikumpulkan organisasi.

Kesenjangan penegakan adalah peringatan. Survei 2025 yang dikutip oleh analisis pengujian CI/CD Testkube melaporkan bahwa 72% organisasi memiliki QA otomatis di CI/CD, sementara hanya 26% menerapkan quality gates untuk memblokir deployment saat tes gagal. Adopsi tanpa penegakan membuat keputusan rilis bergantung pada ingatan, urgensi, atau checklist manual.

Gunakan gate khusus tiap stage

Saat commit, blokir berdasarkan unit test cepat dan subset integrasi stabil yang melindungi interface yang berubah atau kritis. Di staging, tambahkan pengecekan environment gabungan yang lebih luas dan validasi konfigurasi deployment. Sebelum produksi, wajibkan artifact yang disetujui, validasi protected-environment yang berhasil, dan approval eksplisit bila model risiko Anda menuntutnya.

Jangan samakan “pass rate” dengan target persentase mentah. Sebuah suite bisa menunjukkan pass rate tinggi padahal terus gagal pada jalur pembayaran atau autentikasi yang krusial. Tentukan cakupan critical-path berdasarkan perilaku, lalu wajibkan pengecekan tersebut lolos secara deterministik.

Buat bypass terlihat jelas

Konfigurasikan branch protection agar pengecekan blocking yang gagal mencegah merge. Konfigurasikan environment protection rules agar promosi memerlukan approval dan artifact yang diharapkan. Human override mungkin diperlukan saat insiden, tetapi harus menyertakan alasan eksplisit, nama approver, timestamp, dan tiket tindak lanjut.

Karantina bukan izin untuk mengabaikan kegagalan. Ini cara terkendali agar pengiriman tetap berjalan sambil mempertahankan bukti. Jika test yang dikarantina mencakup jalur rilis yang dilindungi, kebijakan harus mengembalikannya ke status blocking atau mensyaratkan keputusan risiko sebelum promosi.

Checklist Adopsi dan Observability untuk Kepercayaan Jangka Panjang

Tim biasanya gagal dalam integration testing dengan salah satu dari dua cara. Mereka memulai dengan suite raksasa yang memperlambat setiap merge, atau membuat suite cepat dengan mock yang terlalu luas sehingga tidak pernah menguji kegagalan yang muncul di produksi. Rencana adopsi bertahap menghindari kedua jebakan ini.

Tahap satu, buat sinyal yang ada bisa dipercaya

Mulai dengan pipeline yang sudah Anda miliki:

• Atur gate pertama: Identifikasi kontrak layanan kritis dan buat hanya pengecekan stabil yang bersifat blocking.
• Tentukan perilaku retry: Izinkan rerun terarah untuk diagnosis, jangan pernah gunakan silent retries yang mengubah kegagalan menjadi sukses.
• Aktifkan parallelization: Pisahkan suite berdasarkan domain, dependency, atau shard, dengan data terisolasi per job.
• Publikasikan hasil test: Simpan laporan JUnit, logs, status container, dan klasifikasi kegagalan untuk setiap run.

Pada tahap ini, jangan mengejar coverage maksimal. Hilangkan sumber noise yang paling mahal dulu, lalu gunakan kepercayaan developer yang kembali untuk memperluas coverage dependency yang nyata.

Tahap dua, tingkatkan kemiripan lingkungan

Tambahkan Testcontainers untuk dependensi yang mudah direproduksi. Gunakan contract tests jika kepemilikan service terdistribusi. Gunakan ephemeral environments jika routing, konfigurasi deployment, atau perilaku antar-service tidak bisa direpresentasikan secara akurat dalam job yang ringkas.

Keputusan pemilihan harus berbasis bukti. Jika insiden produksi mengungkap ketidakcocokan migrasi, tambahkan path database asli. Jika API bergeser di antara service yang di-deploy secara independen, tambahkan consumer-provider contract. Jika kegagalan bergantung pada konfigurasi Kubernetes, jalankan pengecekan terkait pada ephemeral namespace daripada mengandalkan mock.

Tahap tiga, hubungkan observabilitas ke triage

Tangkap persentil durasi test, perbedaan konfigurasi environment, versi dependensi yang terkunci, rasio retry-to-pass, serta korelasi application logs dan traces melalui OpenTelemetry. Dashboard yang berguna harus menampilkan:

• Laju kegagalan flake: Suite dan test mana yang menjadi kurang deterministik.
• Waktu rata-rata menuju status green: Di mana pipeline yang gagal menghabiskan waktu sebelum pulih.
• Klaster mode kegagalan: Apakah kegagalan mengelompok di sekitar code, environment, dependensi, atau desain test.
• Inventaris karantina: Tes mana yang dikarantina, siapa pemiliknya, dan kapan harus ditinjau.
• Bukti promosi: Gate mana saja yang lolos sebelum setiap perubahan environment.

Ini adalah makna operasional dari observability aplikasi. Dashboard bukanlah arsip retrospektif. Ia harus bisa mengubah keputusan hari ini tentang apakah sebuah tes harus memblokir, menunggu secara asinkron, atau kembali ke karantina.

Buat kebijakan tim satu halaman berisi subset pemblokiran, aturan karantina, kepemilikan environment, batas retry, persyaratan artefak, dan proses override. Tinjau saat data kegagalan berubah, bukan hanya saat insiden besar memaksa diskusi.

Capgo menyediakan integrasi CI/CD untuk otomatisasi upload bundle signed live-update setelah web build, dengan channel yang mendukung workflow feature-branch, staging, dan production. Jika tim CapacitorJS atau Electron Anda perlu menghubungkan bukti integration-test ke pengiriman mobile yang terkontrol, kunjungi Capgo untuk mengevaluasi API dan workflow rollout.