Automasi linting lintas stack dengan preview release terbatas menjawab kebutuhan proyek monorepo yang menyatukan backend, frontend, dan infrastruktur. Dalam pembukaan ini, kita langsung melihat cara menggabungkan lint untuk setiap bahasa dan memanfaatkan preview release terbatas sebagai lapisan validasi tambahan sebelum merge ke main.

Tantangan linting multi-stack dalam satu repo

Satu repositori yang menaungi layanan Go, TypeScript, dan konfigurasi Terraform menghadirkan beberapa tantangan:

  • Dependency lint berbeda: Ekosistem lint seperti golangci-lint, eslint, dan tflint membutuhkan runtime dan config tersendiri.
  • Waktu eksekusi: Menjalankan semua lint sekaligus bisa memperpanjang waktu CI, sehingga perlu paralelisasi dan caching.
  • Gating PR: Jika lint hanya dijalankan di stage akhir, merge bisa membelah log history ketika ditemukan error di commit terakhir.
  • Preview release terbatas: Tanpa env preview otomatis, sulit memverifikasi bahwa seluruh stack lint dengan baik dan konsisten.

Pendekatan yang efektif harus mempermudah pengerjaan lint per bahasa, otomatis memblok merge jika ada error, dan memicu preview release yang hanya tersedia untuk branch yang lolos lint.

Desain pipeline automasi linting lintas stack dan preview release

Desain pipeline berada pada prinsip fail fast untuk lint tiap bahasa, disusul gating PR dan preview release terbatas untuk validasi akhir sebelum merge.

Struktur lint job

  • Lint service per bahasa: Gunakan job terpisah seperti lint-backend, lint-frontend, dan lint-infra. Konfigurasi masing-masing job memperhatikan cache dependencies agar tidak mengulang unduhan lengket.
  • Lint matrix: Jika backend memiliki beberapa package, jalankan golangci-lint run ./... dengan subset per job. Untuk frontend, gunakan npm run lint dengan konfigurasi ESLint yang mendukung monorepo.
  • Artifact lint report: Simpan log lint dalam format {@code .sarif} atau plain text agar bisa diunggah ke sistem lint aggregation atau komentar otomatis di PR.

Gating merge request

Setiap job lint harus dihubungkan sebagai required status check di GitHub atau sebagai Merge Request requirement di GitLab. Jika lint gagal, merge tidak bisa dilanjutkan, sehingga pengembang segera memperbaiki kesalahan di branch yang sama.

Untuk menjaga performa PR, jalankan lint dengan caching dependency dan gunakan mode incremental bila tersedia (misal ESLint dengan --cache).

Preview release terbatas

Begitu semua lint berhasil, pipeline masuk ke tahap pembuatan preview release terbatas yang dijalankan pada branch PR tertentu (misal branch yang bernama preview/* atau PR dengan label preview).

Preview release bisa berupa deployment ke namespace staging temporer, dengan feature flag agar hanya pengguna internal dapat mengaksesnya. Penamaan resource mengikuti pola PR agar mudah diidentifikasi.

Integrasikan juga mekanisme otomatisasi pembersihan (teardown) setelah preview selesai agar tidak menumpuk resource.

Contoh konfigurasi CI/CD

Berikut contoh konfigurasi GitHub Actions yang menjalankan lint lintas stack, gating PR, dan membuat preview release terbatas setelah lint berhasil.

name: Lint & Preview Release Automasi

on:
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        stack: [backend, frontend, infra]
    steps:
      - uses: actions/checkout@v4
      - name: Setup environment
        run: |
          if [ "${{ matrix.stack }}" = "backend" ]; then
            curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin latest
          fi
      - name: Run lint
        run: |
          if [ "${{ matrix.stack }}" = "backend" ]; then
            golangci-lint run ./...
          elif [ "${{ matrix.stack }}" = "frontend" ]; then
            npm ci && npm run lint -- --cache
          else
            tflint
          fi
    outputs:
      lint-status: success

  preview-release:
    needs: lint
    runs-on: ubuntu-latest
    if: github.event.pull_request.head.ref == 'preview'
    steps:
      - uses: actions/checkout@v4
      - name: Deploy preview
        run: |
          ./scripts/deploy-preview.sh --env preview-${{ github.event.pull_request.number }}
      - name: Annotate release
        run: echo "Preview release ready on staging namespace"

Konfigurasi di atas menghindari trigger preview release untuk branch yang tidak berlabel preview. Job lint menggunakan matrix per stack dan mencatat status sebagai required check.

Diagram job yang menggambarkan alur:

PR dibuat --> job lint {backend, frontend, infra} berjalan paralel
                        --> jika semua sukses --> job preview release terbatas
                        --> jika lint gagal --> tidak lanjut ke preview release

Praktik monitoring hasil lint dan rollback preview release

Monitoring lint membantu memastikan perubahan tidak mengurangi kualitas kode. Beberapa praktik yang bisa diterapkan:

  • Integrasi lint report ke dashboard: Upload hasil lint dalam format SARIF ke GitHub Code Scanning atau gunakan Grafana untuk melacak jumlah warning per job.
  • Notifikasi kegagalan: Kirim notifikasi ke kanal Slack/Teams dengan log ringkas sehingga tim bisa cepat memperbaiki masalah.
  • Lint trend: Catat metrik jumlah lint warning dan rata-rata waktu lint untuk menghindari degradasi performa linting.

Untuk preview release, pastikan otomatisasi juga menangani rollback ketika masalah baru ditemukan:

  • Rollback otomatis trigger failed smoke test: Setelah preview release, jalankan smoke test sederhana. Jika gagal, job rollback segera membersihkan namespace dan memberi tahu tim.
  • Audit log deployment: Simpan manifest deployment dan konfigurasi preview untuk memastikan rollback bisa kembali ke state sebelumnya.
  • Timeout preview: Preview release hanya aktif untuk waktu tertentu (misal satu jam), kemudian sistem otomatis teardown untuk menghindari biaya berlebih.

Kesimpulan

Automasi linting lintas stack dengan preview release terbatas membantu menjaga kualitas kode di monorepo sekaligus memberikan validasi lingkungan nyata sebelum merge. Dengan struktur lint job yang paralel, gating PR yang ketat, preview release terbatas, serta monitoring dan rollback yang terencana, tim bisa mendeteksi error lebih awal dan menjaga stabilitas pipeline.