Menjawab Tantangan Validasi Dependency dan Smoke Test Laravel di CI/CD

Pertanyaan yang ingin dijawab adalah bagaimana tim Laravel bisa memastikan dependency aman, linting valid, dan endpoint utama masih berfungsi sebelum merge di CI/CD. Jawabannya adalah menaruh pemeriksaan ini ke dalam pipeline otomatis yang berjalan di GitHub Actions sehingga setiap PR mengunci kualitas sebelum diterima.

Artikel ini memandu Anda membangun workflow yang menjalankan validasi dependency (komando seperti composer audit dan pemeriksaan keamanan), linting via Pint/PHPStan, serta smoke test API kritis, dengan perhatian khusus pada caching dan handling kegagalan agar release flow tetap dapat diandalkan.

Struktur Pipeline yang Dibutuhkan

Satu workflow CI/CD ideal untuk Laravel memiliki tiga fase utama:

  1. Validasi dependency untuk mendeteksi kerentanan, versi tak kompatibel, atau paket yang obsolete.
  2. Linting & analisis statis guna menjaga konsistensi kode dan mencegah bug sejak dini.
  3. Smoke test endpoint utama (misalnya endpoint health check) guna memastikan aplikasi siap sebelum merge.

Setiap fase harus bersifat deterministik agar kegagalan bisa langsung ditelusuri. Selain itu, agar pipeline tetap cepat, optimalkan caching dependency serta buat langkah failure handling yang sensitif terhadap false positive.

Contoh Workflow GitHub Actions

Berikut struktur workflow YAML yang mencakup semua pha tersebut.

name: CI Laravel Validation

on:
  pull_request:
    paths:
      - '**/*.php'
      - 'composer.lock'
      - 'routes/**'
      - '.github/workflows/*'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kode
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup PHP
        uses: shivammathur/setup-php@v3
        with:
          php-version: '8.2'
          extensions: mbstring, json
          coverage: none

      - name: Cache Composer dependencies
        uses: actions/cache@v4
        with:
          path: vendor
          key: ${{ runner.os }}-composer-${{ hashFiles('composer.lock') }}
          restore-keys: ${{ runner.os }}-composer-

      - name: Install Composer dependency
        run: composer install --prefer-dist --no-progress --no-suggest

      - name: Security check (composer audit)
        run: composer audit --format=json

      - name: Linting Pint
        run: ./vendor/bin/pint --test

      - name: Analisis PHPStan
        run: ./vendor/bin/phpstan analyse --no-interaction

      - name: Smoke test endpoint utama
        env:
          APP_ENV: testing
        run: |
          php artisan serve --env=testing --port=8080 >/tmp/server.log 2>&1 &
          sleep 5
          curl --fail http://127.0.0.1:8080/health
          pkill -f 'artisan serve'

Contoh ini memanfaatkan composer audit untuk mendeteksi kerentanan, Pint untuk standardisasi kode, PHPStan untuk analisis tipe, dan sebuah smoke test sederhana terhadap endpoint /health. Pastikan endpoint tersebut ada di aplikasi Anda atau ganti dengan route yang sesuai.

Optimasi Caching Dependency

Dependensi Composer adalah bagian paling berat dari job CI. Gunakan actions/cache dengan composer.lock sebagai key utama supaya cache invalid hanya saat lockfile berubah. Simpan cache vendor agar composer install bisa lebih cepat; kalau dependency berubah, Composer tetap akan mengunduh versi baru karena hash lockfile berbeda.

Selain vendor, Anda bisa men-cache directory Composer cache (biasanya ~/.composer/cache) untuk mempercepat install lebih jauh. Tetap amankan cache dengan membatasi size dan menghindari file yang mudah corrupt.

Handling Failure untuk Release Flow Andal

Kegagalan pada workflow harus transparan dan mudah di-troubleshoot:

  • Gabungkan log dan output pada setiap langkah, sehingga bila linting gagal, output error sudah tersedia di log GitHub Actions.
  • Kombinasikan status linting dengan severity—misalnya PHPStan level rendah untuk PR awal, level lebih tinggi untuk merge ke main.
  • Non-Blocking Smoke Test dapat dijadikan optional jika waktu build terbatas, namun idealnya tetap wajib pada branch release.

Untuk menjaga release cepat, pisahkan job yang membutuhkan waktu lama (PHPStan level tinggi, analisis statis berat) ke workflow terpisah yang hanya berjalan untuk branch tertentu atau manual trigger. Namun, dependencies dan smoke test utama harus tetap dijalankan setiap PR agar kualitas dasar terjaga.

Debugging dan Perhatian Tambahan

Beberapa hal yang sering menjadi sumber masalah:

  • Environment variables: Pastikan .env.testing tersedia di repo atau Anda menyediakan fallback dalam workflow.
  • Artisan serve pada smoke test: selalu hentikan proses setelah selesai agar tidak menumpuk.
  • Composer audit membutuhkan Composer >=2.4; ketika tidak tersedia, pilih tooling alternatif seperti sensiolabs/security-checker atau roave/security-advisories.

Jika smoke test gagal karena timeout, tambahkan langkah sleep lebih lama atau tingkatkan readiness endpoint. Untuk kesalahan linting, buat ruleset khusus di Pint/PHPCS agar selaras dengan tim dan sesuaikan PHPStan level sesuai phase dev agar tidak membebani QA.

Kesimpulan

Mengotomasi validasi dependency, linting, dan smoke testing di CI/CD memberikan jaminan kualitas sebelum merge. Gunakan workflow GitHub Actions dengan caching yang tepat, log yang jelas, dan handling failure yang proporsional agar release tetap cepat sekaligus dapat diandalkan.