15-1 · Bab 15 · 6 menit baca

Mengapa CI/CD Frontend Web Berbeda dengan CI/CD Backend

Pelajari perbedaan fundamental antara pipeline CI/CD frontend web dan backend, termasuk caching, dependensi API, pengujian, dan strategi deployment yang tepat.

Mengapa CI/CD Frontend Web Berbeda dengan CI/CD Backend

Ketika sebuah tim mulai membangun pipeline CI/CD, hal pertama yang terlintas biasanya adalah backend. Ada server yang perlu di-restart, migrasi database yang harus dijalankan, dan API yang perlu diperiksa responsnya. Backend berjalan di atas infrastruktur yang dikendalikan tim. Anda tahu OS-nya, versi runtime-nya, memori yang tersedia, dan kapan server terakhir di-restart. Jika ada yang rusak, Anda bisa SSH masuk, memeriksa log, dan me-restart prosesnya.

Frontend web tidak bekerja seperti itu. Setelah aplikasi di-deploy, JavaScript, HTML, dan CSS dikirim ke browser pengguna. Browser itu bisa Chrome, Firefox, Safari, atau yang lainnya. Pengguna mungkin menggunakan laptop Windows, Mac, atau ponsel Android. Koneksi internet mereka bisa cepat atau sangat lambat. Tim tidak memiliki kendali atas variabel-variabel ini. Satu-satunya hal yang bisa Anda kendalikan adalah kode yang Anda kirim: bahwa kode tersebut benar, ringan, dan kompatibel dengan sebanyak mungkin lingkungan.

Perbedaan ini mengubah segalanya tentang cara Anda mendesain pipeline frontend. Strategi yang berhasil untuk deployment backend seringkali gagal atau menimbulkan masalah baru ketika diterapkan pada kode frontend.

Aset Statis vs. Server-Side Rendering

Deployment frontend web biasanya melibatkan dua jenis aset. Aset statis adalah file yang tidak berubah berdasarkan siapa yang memintanya: HTML, CSS, JavaScript, gambar, font. File-file ini dapat disimpan di CDN, di-cache oleh browser, dan disajikan dari server terdekat dengan pengguna. Deployment-nya sederhana: unggah ke bucket penyimpanan atau CDN, dan pengguna mendapatkan versi terbaru saat me-refresh halaman.

Komplikasinya muncul dari caching. Bahkan setelah Anda men-deploy versi baru, browser atau CDN mungkin masih menyajikan file lama. Pengguna yang mengunjungi situs Anda satu jam yang lalu mungkin melihat UI lama selama berjam-jam atau berhari-hari, tergantung pada header cache dan perilaku service worker. Ini adalah masalah spesifik frontend yang jarang dihadapi tim backend. Perubahan API backend berlaku segera di server. Perubahan frontend bisa tidak terlihat oleh pengguna karena browser mereka memutuskan untuk menyimpan file lama.

Jenis aset frontend lainnya adalah konten yang di-render di sisi server (SSR). Dalam SSR, halaman dibangun di server dan dikirim ke browser sebagai HTML siap pakai. Pendekatan ini umum untuk aplikasi yang membutuhkan pemuatan halaman awal yang cepat, SEO yang baik, atau konten dinamis yang berubah per pengguna. SSR berarti kode frontend Anda berjalan di server yang Anda kendalikan, setidaknya untuk render awal. Namun, JavaScript yang menghidrasi halaman tetap berjalan di browser pengguna, jadi Anda masih memiliki masalah kompatibilitas. SSR menambahkan target deployment lain: Anda sekarang perlu mengelola proses server yang menghasilkan HTML, menangani scaling, dan memantau error.

Untuk memaksa CDN mengambil file terbaru setelah deployment, Anda dapat melakukan invalidasi cache. Misalnya, dengan AWS CloudFront:

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/*"

Perintah ini memberi tahu CDN untuk membuang semua file yang di-cache dan meminta salinan baru dari origin. Tanpa langkah ini, pengguna mungkin melihat aset basi selama berjam-jam meskipun deployment berhasil.

Masalah Ketergantungan API

Aplikasi frontend jarang berdiri sendiri. Hampir setiap aplikasi web modern mengambil data dari API, mengirim input pengguna, atau menangani autentikasi. Ini menciptakan penggabungan erat antara frontend dan backend yang membuat desain pipeline lebih sulit dari yang terlihat.

Ketika Anda merilis versi frontend baru, Anda harus memastikan API backend masih cocok. Jika backend mengubah struktur respons tanpa memberi tahu tim frontend, pengguna akan melihat halaman rusak atau data hilang. Jika frontend mulai memanggil endpoint yang belum ada di backend, aplikasi akan error.

Ini berarti pipeline frontend tidak bisa berhenti di "build berhasil." Pipeline juga harus memverifikasi bahwa versi frontend yang akan dirilis kompatibel dengan API yang sedang berjalan di produksi. Tim perlu tahu versi API mana yang aktif, apakah ada perubahan yang memutuskan kompatibilitas, dan bagaimana menangani masa transisi ketika frontend dan backend dirilis pada waktu yang berbeda.

Dalam praktiknya, ini sering mengarah pada API dengan versi, feature flags, atau koordinasi yang cermat antara siklus rilis frontend dan backend. Beberapa tim mengadopsi pendekatan contract-testing di mana pipeline frontend menjalankan tes terhadap spesifikasi API yang diketahui sebelum mengizinkan deployment. Yang lain menggunakan canary releases atau blue-green deployments di frontend untuk menangkap ketidakcocokan lebih awal.

Pengujian Berbeda untuk Frontend

Unit testing di frontend memiliki bentuk yang berbeda dibandingkan backend. Tes unit backend biasanya memanggil fungsi atau endpoint dan memeriksa responsnya. Tes unit frontend perlu memperhitungkan interaksi pengguna, perilaku browser, dan output visual.

Kebiasaan industri yang menyamakan unit test dengan menguji fungsi atau kelas individual menyesatkan untuk frontend. Sebuah unit test harus memverifikasi satu perilaku bermakna dari titik masuk yang relevan. Untuk frontend, titik masuk itu seringkali adalah aksi pengguna: klik, pengiriman formulir, navigasi, atau perubahan status yang terlihat. Tes harus membuktikan bahwa sistem merespons dengan benar terhadap interaksi tersebut, bukan bahwa metode internal dipanggil dengan argumen yang tepat.

Ini berarti rangkaian tes Anda tidak boleh rusak hanya karena Anda melakukan refaktor kode internal. Jika Anda mengubah cara komponen mengelola status internalnya tetapi pengguna masih melihat hasil yang sama, tes harus tetap lulus. Tes yang terikat erat dengan detail implementasi menjadi beban pemeliharaan dan memperlambat pipeline tanpa menambah keamanan nyata.

Untuk frontend, lingkungan tes yang relevan mungkin mencakup runtime browser. Emulator atau simulator bisa menjadi lingkungan eksekusi yang valid untuk unit test jika perilaku yang diuji memerlukan API browser, kalkulasi tata letak, atau fitur runtime. Perangkat fisik masih diperlukan untuk skenario yang bergantung pada perangkat keras: kamera, sensor, variasi jaringan, dan kinerja dunia nyata.

Langkah Build Bukan Sekadar Kompilasi

Di CI/CD backend, langkah build biasanya berarti mengompilasi kode dan mengemasnya menjadi artefak yang dapat di-deploy. Untuk frontend, langkah build melakukan lebih banyak hal. Ia menggabungkan modul JavaScript, meminifikasi kode, mengoptimalkan gambar, menghasilkan source map, menyuntikkan variabel lingkungan, dan memproduksi beberapa versi file untuk browser atau perangkat yang berbeda.

Output build bukanlah satu artefak. Ia adalah kumpulan file dengan hash pembatal cache di nama filenya. Hash ini sangat penting untuk manajemen cache. Ketika Anda men-deploy versi baru, hanya file yang berubah yang mendapatkan hash baru. File yang tidak berubah mempertahankan hash lamanya, sehingga cache browser terus menyajikannya. Ini mengurangi ukuran unduhan bagi pengguna yang sudah mengunjungi situs Anda.

Namun, pembatalan cache hanya berfungsi jika pipeline Anda menanganinya dengan benar. Jika proses build Anda tidak menghasilkan hash unik untuk file yang berubah, atau jika proses deployment Anda tidak memperbarui referensi HTML untuk menunjuk ke hash baru, pengguna akan mendapatkan campuran file lama dan baru. Hasilnya adalah UI yang rusak dan sulit di-debug karena hanya terjadi di beberapa browser atau setelah pola navigasi tertentu.

Daftar Periksa Praktis untuk CI/CD Frontend

Verifikasi bahwa langkah build Anda menghasilkan hash pembatal cache yang unik untuk file yang berubah.
Uji frontend Anda terhadap versi API yang tepat yang berjalan di produksi, bukan hanya mock atau staging API.
Sertakan tes berbasis browser yang mensimulasikan interaksi pengguna nyata, bukan hanya unit test pada fungsi internal.
Tetapkan kebijakan header cache yang menyeimbangkan kesegaran dengan kinerja. Waktu cache pendek untuk HTML, waktu cache panjang untuk aset yang di-hash.
Jalankan pemeriksaan regresi visual cepat untuk menangkap perubahan UI yang tidak diinginkan sebelum rilis.
Pastikan proses deployment Anda memperbarui semua referensi ke hash aset baru, termasuk file service worker jika Anda menggunakannya.

Kesimpulan Konkret

CI/CD frontend bukanlah versi sederhana dari CI/CD backend. Ia memiliki kendalanya sendiri: lingkungan pengguna yang tidak terkendali, perilaku caching yang bisa menyembunyikan atau merusak rilis Anda, penggabungan erat ke API backend, dan langkah build yang melakukan lebih dari sekadar mengompilasi kode. Memperlakukan deployment frontend sebagai "cukup unggah beberapa file" akan menyebabkan pengalaman pengguna yang rusak dan sulit didiagnosis. Bangun pipeline frontend Anda di sekitar kenyataan bahwa kode berjalan di browser orang lain, di jaringan orang lain, dan Anda hanya punya satu kesempatan untuk membuat kesan pertama yang baik.