Setup CI/CD Sederhana Pakai GitHub Actions buat Static Site

Buat situs ini, saya pakai GitHub Actions buat CI/CD, dan setup-nya sengaja saya bikin sesederhana mungkin. Ini bukan situs yang butuh multi-stage pipeline atau approval gate — cukup untuk static site yang nggak punya proses build kompleks.

Alurnya cuma tiga langkah

Build. Setiap push ke branch main, workflow jalanin npm ci && npm run build. Karena situs ini static (Astro), hasil build-nya cuma kumpulan file HTML/CSS/JS — nggak ada server-side rendering yang perlu di-deploy terpisah.

Sync ke server. Hasil build di-sync langsung ke VPS lewat SSH pakai rsync, via GitHub Action easingthemes/ssh-deploy. Nggak ada image Docker yang perlu di-build dan push ke registry — cukup salin file statis ke direktori yang di-serve Nginx.

Selesai. Nggak ada langkah restart service atau migrasi database, karena memang nggak ada keduanya di setup ini.

Dibanding setup lama

Setup lama saya buat versi Laravel situs ini jauh lebih ribet: build Docker image, push ke registry, SSH ke server buat docker compose up, tunggu container-nya sehat. Sekarang dari push ke live cuma butuh puluhan detik, bukan beberapa menit — dan itu bukan cuma soal cepet, tapi juga soal lebih sedikit hal yang bisa gagal di tengah jalan. Docker image yang gagal pull, registry yang lagi down, container yang stuck restart — semua itu udah nggak ada di skenario kegagalan yang perlu saya pikirin lagi.

Yang saya pelajari dari setup ini

Pin versi Action pihak ketiga secara eksplisit — misalnya @v5.1.2, bukan cuma @v5 yang kadang nggak eksis sebagai tag atau bisa berubah behavior-nya tanpa saya sadar kalau maintainer-nya push versi baru ke tag mayor yang sama. Dan selalu test dulu rsync target path-nya bener sebelum nge-rely penuh ke automation — saya sempat kena masalah gara-gara typo satu karakter di path tujuan yang bikin sync “berhasil” tapi file-nya nyasar ke direktori yang salah, dan situsnya nggak keupdate sama sekali padahal GitHub Actions nunjukin centang hijau.

Buat static site personal, CI/CD nggak harus rumit. Makin sedikit moving parts, makin sedikit yang bisa rusak — dan makin gampang juga saya inget cara benerinnya kalau suatu hari ada yang gagal, karena cuma ada tiga langkah buat di-debug, bukan sepuluh.