CI CD Integration Testing: Panduan Praktis Pipeline

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

Itulah masalah operasional dengan testing integrasi CI/CD. Unit test membuktikan logika terisolasi berjalan benar. Integration test memberi bukti bahwa komponen, service, schema, queue, dan dependensi eksternal tetap selaras. Dalam pipeline delivery modern, bukti itu harus memandu keputusan triage, bukan menjadi tembok pengecekan lambat yang lama-lama diabaikan developer.

CI/CD telah menjadi model software delivery yang umum. 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

Mulai dengan mengklasifikasikan integration test berdasarkan keputusan yang didukung test tersebut:

• Test blocking melindungi kontrak kritis dan berjalan secara sinkron sebelum merge atau promosi.
• Test yang dikarantina tetap terlihat dan terus menghasilkan bukti, tetapi tidak memblokir pengiriman sementara tim menyelidiki ketidakstabilan.
• Test asinkron menguji alur kerja yang lebih luas, komposisi staging penuh, atau infrastruktur mahal setelah commit melewati gate cepat.

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

Aturan praktis: Gunakan bukti integration yang stabil sebagai gate, bukan keberadaan suite integration.

Sisa implementasi mengikuti aturan tersebut. Gunakan dependensi yang menyerupai produksi di mana antarmuka bisa gagal, paralelkan pemeriksaan independen, ukur kegagalan palsu, dan definisikan kondisi eksplisit untuk karantina dan promosi. Tim yang ingin menghubungkan pekerjaan ini dengan praktik pengiriman 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 cepat karena mengisolasi fungsi, class, atau module. Kecepatan itu membuatnya ideal untuk feedback instan, tetapi mock bisa menyembunyikan kegagalan yang justru terjadi di system seam, seperti perbedaan serialisasi, constraint 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. Namun, test ini juga melewati batas browser, network, 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 sering kali 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 antar service tanpa memerlukan orkestrasi UI yang lengkap. Layer ini dapat mencakup panggilan HTTP dan gRPC, publish ke queue, migrasi database, interaksi cache, serta kompatibilitas schema.

Tiga pola integrasi yang berguna

In-process component test dengan Testcontainers jalankan komponen aplikasi bersama dependensi seperti PostgreSQL, Redis, atau Kafka. Pola ini sepadan dengan biaya setup saat risiko defect melibatkan persistensi, serialisasi, transaksi, atau semantik broker. Ini memberi test dependensi nyata sambil menjaga batas test tetap sempit.

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

Test tingkat API terhadap staging stack gabungan panggil beberapa service yang sudah dideploy melalui jalur network aslinya. Gunakan pola ini untuk workflow saat routing, autentikasi, service discovery, konfigurasi deployment, atau kebijakan infrastruktur penting. Jaga agar set tetap fokus pada jalur yang kritis bagi bisnis, karena staging stack lengkap lebih mahal untuk di-provision dan lebih sulit diisolasi saat gagal.

Jaga agar synchronous merge suite tetap ramping. 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 pemisahan ini bisa meninjau apa yang termasuk dalam pengujian otomatis, tetapi prinsip dasarnya tetap sederhana: bayar untuk realisme hanya jika itu mengubah keputusan rilis.

Mengelola environment dan data untuk test yang representatif

Pengujian yang dijalankan di lingkungan yang salah dapat menghasilkan keyakinan palsu. Pengujian di lingkungan bersama yang tidak stabil dapat menghasilkan kegagalan palsu. Keandalan testing integrasi CI/CD membutuhkan strategi lingkungan yang membuat batas dependensi eksplisit dan status data dapat direproduksi.

Mulai dengan dependensi yang dapat dijalankan secara akurat. Testcontainers dapat menyediakan instance PostgreSQL, Redis, dan Kafka sekali pakai untuk setiap job. Manfaat utamanya bukan Docker itu sendiri, melainkan kontrol atas versi, konfigurasi, startup, dan teardown.

Urutan job yang dapat direproduksi

Gunakan urutan tetap, jangan biarkan test code berimprovisasi dengan setup-nya:

1. Jalankan dependensi. Jalankan container PostgreSQL, lalu tunggu hasil health check yang valid, bukan sekadar mengasumsikan bahwa proses yang berjalan sudah siap menerima traffic.
2. Terapkan migrasi. Jalankan jalur migrasi yang sama dengan aplikasi. Jangan buat test schema yang dikelola manual dan bisa menyimpang dari produksi.
3. Muat fixtures deterministik. Seed hanya record yang dibutuhkan untuk skenario, dan beri setiap job data terisolasi agar run paralel tidak saling mengubah state.
4. Jalankan assertion kontrak. Verifikasi format request, perilaku response, skema event, transisi status, dan hasil persistensi.
5. Bongkar semuanya. Hancurkan container dan volume sementara meskipun test gagal, agar job berikutnya tidak mewarisi state yang rusak.

Waktu boot PostgreSQL selama 90 detik bisa jadi biaya yang wajar jika itu menangkap cacat migrasi dan transaksi. Klaster staging lengkap adalah keputusan yang berbeda. Ini memakan lebih banyak infrastruktur, memperkenalkan lebih banyak drift konfigurasi, dan menambah jumlah titik asal potensi kegagalan. Mulai dari lingkungan paling sempit yang representatif, lalu perluas saat cakupan kontrak atau insiden produksi menunjukkan bahwa batas yang lebih kecil melewatkan mode kegagalan yang penting.

Gunakan virtualisasi secara terarah

Beberapa sistem pihak ketiga tidak bisa diprovisioning dengan aman di setiap pipeline. WireMock, Mountebank, dan Hoverfly dapat mensimulasikan dependensi tersebut, tetapi simulasi harus diperlakukan sebagai kontrak yang terawat, bukan jalan pintas yang nyaman. Mock yang hanya mengembalikan respons ideal tidak akan mengungkap kedaluwarsa autentikasi, pembatasan laju, payload yang salah format, penanganan timeout, atau evolusi skema.

Lingkungan pratinjau sementara berguna ketika risiko bergantung pada beberapa layanan yang di-deploy bekerja bersama. Docker Compose dapat menyediakan komposisi lokal dan CI yang ringkas, sementara namespace Kubernetes dapat mengisolasi lingkungan pull request ketika perilaku deployment itu sendiri perlu diuji. Apa pun pendekatan yang Anda gunakan, kunci versi dependensi dan catat konfigurasi yang digunakan oleh setiap run.

Secrets membutuhkan disiplin yang sama seperti data. Simpan kredensial di luar fixture pengujian dan putar akses melalui mekanisme terlindungi platform. The panduan Capgo untuk mengelola secrets di pipeline CI/CD memberikan panduan yang relevan untuk menjaga nilai sensitif keluar dari konfigurasi repository.

Walkthrough visual singkat dapat membantu tim menyelaraskan pemahaman tentang siklus hidup lingkungan:

Contoh Pipeline untuk GitHub Actions, GitLab CI, dan Jenkins

Runner kurang penting dibanding bentuk workflow-nya. Build sekali, provision dependensi secara prediktif, pisahkan grup test independen, publikasikan hasil yang bisa dibaca mesin, dan buat batas blocking jelas. Sintaksnya berubah antar platform, tapi aturan operasionalnya tetap konsisten.

Aksi GitHub

Matriks cocok saat tes integrasi bisa dibagi berdasarkan domain atau shard. Kontainer layanan menjaga dependensi tetap dekat dengan runner, sementara output JUnit memberikan format hasil yang stabil untuk 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

Pin versi action dan dependensi mengurangi environment drift. GitHub Actions menyediakan paralelisme terutama lewat matriks dan job terpisah, jadi gunakan matriks hanya jika tiap shard punya data terisolasi dan durasi yang bisa diprediksi.

GitLab CI

GitLab CI dapat memisahkan persiapan, eksekusi tes, dan pelaporan. Child pipeline berguna saat repositori besar mengelola beberapa layanan dengan lingkungan integrasi berbeda. Artifacts menyimpan hasil JUnit bahkan saat job tes 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 child pipeline GitLab saat kepemilikan layanan atau topologi deployment membuat satu file monolitik sulit dipelihara. Biarkan parent pipeline bertanggung jawab atas keputusan promosi; jika tidak, satu child pipeline bisa lolos sementara sinyal rilis keseluruhan tetap ambigu.

Jenkins

Jenkins berguna saat tim membutuhkan agent self-hosted atau akses jaringan yang tidak biasa. Jenkinsfile deklaratif dapat menetapkan agent berbasis Docker dan menjalankan suite secara paralel, tetapi tim bertanggung jawab atas pemeliharaan 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 rilis otomatis dengan GitHub Actions dapat menyediakan pola deployment yang berguna. Pilihan desain penting tetap sama di ketiga runner: jangan jadikan setiap test mahal sebagai blocker merge sinkron.

Taktik Keandalan untuk Flaky Integration Test

Retries berguna untuk diagnosis, tetapi retries menyeluruh adalah strategi keandalan yang buruk. Mereka dapat mengubah cacat nyata menjadi build hijau, menyembunyikan ketidakstabilan lingkungan, dan membuat dashboard pass-rate terlihat lebih sehat daripada pipeline sebenarnya.

Skala masalah ini terlihat dari data engineering yang dipublikasikan. Google melaporkan sekitar 16% dari test 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 satu studi, menurut tinjauan statistik flaky test dari Panto.

Ukur dulu sebelum mengubah kebijakan

Lacak flakiness sebagai:

gagal flaky ÷ total eksekusi × 100

Gunakan Jendela 7 hingga 30 hari, dan hitung per suite, test, runner image, dependency, dan environment. Test yang gagal hanya di satu runner adalah masalah remediasi yang berbeda dari test yang gagal di semua environment.

Gunakan kategori triase berikut:

• Kegagalan produk: blokir gate terkait dan perbaiki code atau kontraknya.
• 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, tetapi tetapkan pemilik dan tanggal kedaluwarsa.

Hilangkan penyebab umum

State mutable bersama menciptakan ketergantungan urutan. Berikan setiap job skema terisolasi, pengidentifikasi unik, atau batas rollback transaksi. Sistem asinkron memerlukan polling berbasis kondisi dengan timeout terbatas, bukan sleep sewenang-wenang. Suntikkan clock ke logika kedaluwarsa, dan tunggu kesehatan container, bukan sekadar startup proses.

Sharding mengurangi waktu wall-clock, tetapi 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 didefinisikan, seperti eksekusi hijau beruntun di lingkungan tempat test tersebut akan dijalankan. Ambang batas yang tepat harus dipilih oleh tim dan dicatat dalam kebijakan. Bagian pentingnya adalah promosi diperoleh melalui stabilitas yang diamati, bukan dengan menghapus label karantina.

Kebijakan Gating dan Aturan Promosi Deployment

Quality gate harus menjawab satu pertanyaan: apakah artifact ini memiliki bukti yang cukup dapat dipercaya untuk pindah ke lingkungan berikutnya? Jangan biarkan 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 dari pipeline yang sudah Anda miliki:

• Tetapkan gate pertama: Identifikasi kontrak layanan kritis dan jadikan hanya pengecekan yang stabil sebagai blocking.
• Tentukan perilaku retry: Izinkan rerun terarah untuk diagnosis, jangan pernah pakai silent retry yang mengubah kegagalan menjadi sukses.
• Aktifkan paralelisasi: Pisahkan suite berdasarkan domain terbatas, dependency, atau shard, dengan data terisolasi per job.
• Publikasikan hasil test: Simpan laporan JUnit, log, status container, dan klasifikasi kegagalan untuk setiap run.

Pada tahap ini, jangan mengejar coverage maksimal. Hilangkan sumber noise paling mahal terlebih dahulu, lalu gunakan kepercayaan developer yang sudah pulih untuk memperluas coverage dependency nyata.

Tahap dua, tingkatkan kemiripan lingkungan

Tambahkan Testcontainers untuk dependensi yang murah direproduksi. Perkenalkan contract tests ketika kepemilikan service terdistribusi. Gunakan environment ephemeral saat routing, konfigurasi deployment, atau perilaku lintas-service tidak bisa direpresentasikan secara akurat dalam job ringkas.

Keputusan pemilihan harus berbasis bukti. Jika insiden produksi mengungkap ketidakcocokan migrasi, tambahkan jalur database nyata. Jika API menyimpang antar service yang dideploy independen, tambahkan contract consumer-provider. Jika kegagalan bergantung pada konfigurasi Kubernetes, jalankan pemeriksaan yang relevan terhadap namespace ephemeral, bukan menganggap mock membuktikan hal yang sama.

Tahap tiga, hubungkan observabilitas ke triage

Rekam persentil durasi test, perbedaan konfigurasi environment, versi dependensi terkunci, rasio retry-to-pass, serta log dan trace aplikasi yang terkorelasi melalui OpenTelemetry. Dashboard yang berguna harus menampilkan:

• Burnup flake-rate: Suite dan test mana yang makin tidak deterministik.
• Rata-rata waktu sampai green: Di mana pipeline yang gagal menghabiskan waktu sebelum recovery.
• Klaster mode kegagalan: Apakah kegagalan mengelompok di sekitar code, environment, dependensi, atau desain test.
• Inventaris karantina: Tes mana saja yang dikarantina, siapa pemiliknya, dan kapan harus ditinjau.
• Bukti promosi: Gate mana saja yang lolos sebelum setiap perubahan environment.

Ini arti 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 yang berisi subset pemblokiran, aturan karantina, kepemilikan environment, batas retry, persyaratan artifact, dan proses override. Tinjau kebijakan ini saat data kegagalan berubah, bukan hanya saat insiden besar memaksa diskusi.

Capgo menyediakan integrasi CI/CD untuk mengotomatiskan upload bundle live-update yang ditandatangani setelah web build, dengan channel yang dapat 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.