Build asset Elm 0.19.1 yang lambat bisa langsung memblokir pipeline deployment backend. Dalam kasus ini, timeout CI muncul sebelum rollout ke staging API karena proses frontend build menahan seluruh pipeline; setelah profiling, terlihat bahwa compiler lama dan cache yang tidak dipakai efektif membuat setiap build penuh berjalan selama lima menit lebih, menumpuk antrean deploy. Langkah pertama adalah memastikan bahwa gejala dapat langsung dijelaskan: CI timeout, antrian deploy di API staging, dan log build menunjukkan recompile setiap perubahan.

Artikel ini membahas langkah-langkah debugging sampai solusi dengan mengacu pada konteks teknis Elm 0.19.2 yang membawa build lebih cepat (Elm news: faster builds), langkah optimasi cache, serta mitigasi sementara bila build masih naik.

1. Gejala & Dampak terhadap Pipeline Deployment

Build asset yang lambat terlihat jelas dari timeout pada job CI utama. Ketika job frontend:build menunggu selama 6–8 menit, job backend yang tergantung padanya ikut timeout atau digagalkan karena dependency graph tidak selesai. API staging tetap dijaga dalam versi lama, dan tim QA mengalami blokir karena tidak ada build terbaru untuk diuji.

Profilling log build menampilkan dua indikator utama:

  • Inisialisasi ulang compiler setiap commit: Elm compiler mengompilasi ulang seluruh proyek tanpa cache sehingga tidak ada incremental build.
  • Waktu build dominan di fase elm make: sekitar 4-5 menit per run, menunjukkan bahwa compiler mengulang seluruh modul dari awal.

Kondisi ini membuat staging API tertunda dan blokir CI berdampak langsung ke release cycle.

2. Diagnosis Penyebab Build Asset Lambat

2.1 Cache tidak efektif

Pipeline sebelumnya hanya menyimpan folder node_modules dan langsung menjalankan elm make tanpa mempertimbangkan hasil build Elm. Elm compiler menghasilkan cache di elm-stuff dan direktori build, tetapi jika pipeline membersihkan folder tersebut setiap run, maka tidak ada manfaat caching.

Solusi observasi: pada job build, perhatikan apakah folder elm-stuff dibersihkan secara agresif. Jika ya, pipeline tidak memiliki informasi terakhir, sehingga setiap commit akan memicu kompilasi penuh.

2.2 Compiler Elm 0.19.1

Elm 0.19.1 tidak menawarkan optimasi build incremental yang dihadirkan Elm 0.19.2, sehingga proyek besar dengan banyak modul akan mengalami build penuh. Berita resmi Elm menyebutkan bahwa Elm 0.19.2 membawa build lebih cepat dengan cache yang lebih pintar dan pengelolaan dependency yang lebih baik.

Jadi, meski cache lokal ada, compiler versi lama tetap membebani waktu build karena tidak memanfaatkan pengoptimalan ini.

3. Langkah Perbaikan Praktis

3.1 Upgrade ke Elm 0.19.2

Upgrade pertama adalah memastikan elm.json menyebut versi 0.19.2 dan runtime Elm pada CI mencapai versi tersebut. Proses upgrade dilakukan dengan mengganti:

"elm-version": "0.19.2"

Setelah update, jalankan elm make lokal untuk memastikan perubahan struktur artifact diterima. Elm 0.19.2 mempercepat build karena backend compiler menyimpan cache per modul, sehingga setiap perubahan terbatas tidak memicu kompilasi ulang semua modul.

3.2 Optimasi Cache CI

Pastikan pipeline menyimpan directory berikut antar job:

  • elm-stuff – menyimpan cache dependency package.
  • build – jika ada artefak hasil bundel yang dapat dipakai ulang.

Contoh konfigurasi caching di GitLab CI:

cache:
  key: elm-cache
  paths:
    - elm-stuff
    - node_modules

Tujuan: ketika elm make dijalankan ulang dengan perubahan kecil, compiler mempertahankan hasil parsing dependency dan tidak melakukan kompilasi ulang seluruh modul. Pastikan cache tidak selalu dihapus dengan rm -rf elm-stuff sebelum build.

3.3 Mitigasi fallback saat build masih lambat

Jika build tetap tidak selesai dalam waktu yang diinginkan setelah tindak lanjut perbaikan, pertimbangkan strategi berikut:

  • Split asset build: jalankan build Elm hanya ketika file .elm berubah dengan deteksi perubahan, sedangkan job lain tetap berjalan.
  • Fallback incremental staging: deploy backend terlebih dahulu, lalu jalankan build asset secara paralel tanpa menahan pipeline utama. Jika build gagal, revert dapat dilakukan tanpa mengganggu backend.
  • Monitor timeout: tambahkan alert berdasarkan log CI yang menunjukkan job tinggal 30 detik dari timeout sehingga bisa segera intervensi manual.

Mitigasi ini mencegah API staging terhambat saat build asset mengalami lonjakan waktu.

4. Kesimpulan

Pipeline deployment yang terhambat akibat build asset Elm 0.19.1 lambat dapat diselesaikan dengan kombinasi upgrade ke Elm 0.19.2, optimasi cache CI, dan fallback mitigasi. Sabagai tambahan, pastikan CI memantau waktu build dan cache untuk mendeteksi regresi lebih awal. Dengan langkah-langkah tersebut, staging API kembali dapat menerima build terbaru tanpa mengorbankan kecepatan deployment.