Untuk game web harian, masalah utamanya biasanya bukan skala infrastruktur, melainkan ritme rilis: setiap hari ada perubahan kecil, konten baru, atau penyesuaian gameplay yang harus naik tanpa bikin build rusak, aset cache salah, atau preview susah dicek. Karena itu, CI untuk game web harian sebaiknya dibuat ringan, cepat, dan cukup ketat untuk mencegah error dasar sebelum kode masuk ke produksi.

Pendekatan yang paling praktis untuk tim kecil adalah memisahkan alur menjadi beberapa lapis: validasi cepat saat pull request, preview deployment per PR untuk review, build produksi yang reproducible, lalu rilis otomatis dari branch utama dengan rollback yang sederhana. Tujuannya bukan membuat pipeline paling lengkap, tetapi membuat rilis harian tetap aman tanpa menambah beban operasional.

Tujuan pipeline untuk game web harian

Game web kecil biasanya punya karakteristik yang berbeda dari aplikasi enterprise:

  • Perubahan sering, tetapi lingkupnya relatif sempit.
  • Frontend menjadi pusat utama: HTML, CSS, JavaScript/TypeScript, aset statis, dan kadang data level atau puzzle.
  • Waktu review singkat, sehingga preview yang mudah diakses sangat membantu.
  • Bug yang sering muncul justru bug sederhana: typo import, lint error, build gagal, aset lama tercache, atau env yang berbeda antara lokal dan CI.

Karena itu, pipeline yang baik perlu memenuhi beberapa sasaran berikut:

  • Cepat: feedback PR idealnya keluar dalam hitungan menit, bukan puluhan menit.
  • Konsisten: hasil build di CI harus sedekat mungkin dengan hasil build rilis.
  • Mudah di-debug: saat gagal, penyebabnya harus terlihat dari log.
  • Mendukung review visual: setiap PR punya preview deployment sendiri.
  • Aman untuk rilis harian: ada cara rollback tanpa prosedur panjang.

Struktur branch yang sederhana dan efektif

Untuk tim kecil, struktur branch tidak perlu rumit. Hindari model yang terlalu banyak branch permanen jika ritme rilis terjadi setiap hari.

Rekomendasi alur branch

  • main: selalu siap rilis. Setiap merge ke branch ini akan memicu build produksi dan deploy.
  • feature/* atau fix/*: branch kerja untuk fitur, puzzle harian, balancing, atau perbaikan bug.
  • release branch terpisah biasanya tidak perlu, kecuali Anda punya proses QA manual yang lebih lama.

Alur kerjanya sederhana:

  1. Developer membuat branch dari main.
  2. Push perubahan dan buka pull request.
  3. CI menjalankan lint, type check, test cepat, dan build verifikasi.
  4. PR membuat preview deployment agar game bisa diuji langsung.
  5. Setelah lolos review, merge ke main.
  6. Deploy produksi berjalan otomatis dari commit merge tersebut.

Kelebihan pendekatan ini adalah friksi rendah. Kekurangannya, disiplin review dan kualitas CI harus cukup baik karena branch utama menjadi titik rilis harian.

Tahapan CI yang benar-benar berguna

Jangan masukkan semua hal ke pipeline hanya karena bisa. Untuk game frontend ringan, urutan validasi yang masuk akal biasanya seperti ini.

1. Install dependency secara konsisten

Gunakan lockfile dan perintah instalasi yang bersifat deterministik, misalnya npm ci jika proyek memakai npm. Ini membantu membuat build lebih reproducible dan mengurangi kasus “jalan di lokal, gagal di CI”.

Yang perlu diperhatikan:

  • Commit lockfile ke repository.
  • Samakan versi runtime antara lokal dan CI sejauh memungkinkan.
  • Jangan biarkan pipeline memakai instalasi dependency yang mengubah lockfile secara diam-diam.

2. Lint

Linting menangkap error yang murah tapi sering lolos, seperti variabel tidak terpakai, import salah, atau pola kode yang rawan bug. Untuk game harian, lint sangat bernilai karena perubahan kecil sering terjadi cepat.

Contoh perintah:

npm run lint

Jika proyek memakai formatter terpisah, Anda bisa menambahkan pengecekan format:

npm run format:check

Jangan paksa aturan lint yang terlalu berat jika tim kecil sering harus bergerak cepat. Lebih baik sedikit aturan tetapi benar-benar dipatuhi daripada banyak aturan yang akhirnya sering di-bypass.

3. Type check

Jika proyek memakai TypeScript, type check sangat layak dijalankan di PR. Banyak bug UI sederhana, salah bentuk data level, atau kontrak fungsi yang berubah bisa terdeteksi sebelum runtime.

npm run typecheck

Jika Anda memakai JavaScript murni, tahap ini bisa dilewati. Jangan menambahkan TypeScript ke pipeline hanya demi terlihat lengkap jika proyek belum menggunakannya.

4. Test cepat

Untuk game web kecil, fokuskan CI pada test yang cepat dan deterministik. Hindari test end-to-end berat pada setiap push jika waktu feedback jadi terlalu lambat.

Yang umum berguna:

  • Unit test untuk helper logika skor, validasi input, generator puzzle, atau utility waktu.
  • Smoke test untuk memastikan aplikasi dapat dirender atau entry point utama tidak crash.
npm test -- --runInBand

Jika ada test browser yang lebih berat, pertimbangkan menjalankannya hanya saat merge ke main atau secara terjadwal.

5. Build verifikasi

Banyak masalah frontend baru muncul saat build produksi: path aset salah, import dinamis gagal, atau bundler tidak menemukan file. Karena itu, build harus dijalankan di PR, bukan hanya setelah merge.

npm run build

Ini penting walaupun Anda sudah punya preview deployment, karena preview biasanya juga bergantung pada build. Jika build verifikasi gagal lebih awal, feedback untuk developer jadi lebih cepat.

Contoh workflow GitHub Actions untuk proyek frontend ringan

Berikut contoh pipeline yang relevan untuk game web kecil. Contoh ini sengaja dibuat generik agar mudah diadaptasi ke bundler atau framework frontend yang berbeda.

Workflow CI untuk pull request

name: ci

on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main

jobs:
  validate:
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npm run typecheck

      - name: Run tests
        run: npm test -- --runInBand

      - name: Build
        run: npm run build

      - name: Upload build artifact
        if: success()
        uses: actions/upload-artifact@v4
        with:
          name: web-build
          path: dist

Kenapa urutannya seperti ini?

  • Lint dan type check biasanya paling cepat memberi sinyal error dasar.
  • Test dijalankan sebelum build jika test tidak membutuhkan output build.
  • Build tetap wajib agar path, bundling, dan aset diverifikasi.
  • Artifact diunggah untuk inspeksi atau dipakai ulang oleh job deploy.

Jika proyek Anda tidak memakai TypeScript atau test otomatis belum ada, jangan memalsukan tahap tersebut. Lebih baik pipeline sederhana yang benar-benar dipakai daripada pipeline panjang yang sering dinonaktifkan.

Workflow deploy produksi dari main

Untuk deploy produksi, idealnya gunakan artifact dari build yang sudah lulus, bukan membangun ulang secara berbeda di lingkungan lain tanpa kontrol. Namun pada setup sederhana, membangun ulang di job deploy masih bisa diterima selama environment dan dependency terkunci.

name: deploy-production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Build production
        run: npm run build

      - name: Deploy static site
        run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Script deploy.sh sebaiknya menjadi tempat utama logika deploy, bukan ditulis penuh di YAML. Ini membantu debugging dan memungkinkan script yang sama dijalankan secara lokal atau di lingkungan lain.

Preview deployment per pull request

Untuk game web, preview deployment per PR sangat membantu karena reviewer bisa langsung mencoba gameplay, layout mobile, audio, atau interaksi pointer tanpa harus checkout branch secara lokal.

Pola implementasi

Secara umum ada dua pendekatan:

  • Platform yang menyediakan preview otomatis: cocok jika hosting frontend Anda memang mendukung deployment per PR secara native.
  • Deploy preview manual dari GitHub Actions: cocok jika Anda meng-host aset statis sendiri, misalnya ke object storage atau server sederhana.

Jika menggunakan deploy preview manual, pola paling umum adalah:

  1. Build output PR disimpan ke path terisolasi, misalnya berdasarkan nomor PR atau SHA commit.
  2. URL preview dikembalikan ke PR sebagai komentar atau status check.
  3. Preview lama dibersihkan saat PR ditutup atau diganti dengan deploy terbaru.

Hal yang perlu dijaga:

  • Jangan gunakan path yang sama untuk semua PR.
  • Pastikan asset base path sesuai dengan lokasi preview.
  • Jangan bocorkan secret produksi ke workflow PR dari fork publik.

Kesalahan umum di sini adalah build berhasil, tetapi aset statis 404 di preview karena aplikasi mengasumsikan root path produksi.

Build reproducible dan versi aset statis

Pada game harian, masalah cache sering lebih mengganggu daripada bug build. Pemain bisa melihat versi lama JavaScript atau sprite sheet walaupun deploy baru sudah selesai. Solusi utamanya adalah versioning aset statis dan build yang konsisten.

Mengapa reproducible build penting

Build reproducible berarti output yang dihasilkan dari source dan dependency yang sama semestinya konsisten. Tujuannya bukan kesempurnaan akademis, melainkan mengurangi perbedaan antara:

  • build lokal vs CI,
  • build validasi vs build rilis,
  • deploy hari ini vs rollback ke commit lama.

Praktik dasarnya:

  • Gunakan lockfile.
  • Pin versi runtime CI bila memungkinkan.
  • Minimalkan ketergantungan pada state eksternal saat build.
  • Jangan sisipkan timestamp acak ke aset jika tidak perlu.

Versioning aset statis

Strategi yang paling aman untuk frontend modern adalah memakai nama file yang sudah mengandung hash konten, misalnya:

  • app.a1b2c3.js
  • styles.9f8e7d.css
  • sprite.123abc.png

Dengan pendekatan ini:

  • File baru akan punya nama baru saat kontennya berubah.
  • Browser boleh meng-cache aset lama sangat lama karena HTML terbaru akan menunjuk nama file baru.
  • Rollback lebih aman karena versi HTML yang berbeda tetap merujuk ke file yang sesuai.

Yang perlu dihindari:

  • Menggunakan nama file tetap tanpa query version yang konsisten.
  • Menghapus semua aset lama terlalu cepat jika masih ada HTML lama yang mungkin diakses.

Untuk deploy statis, simpan beberapa versi build terakhir jika memungkinkan. Ini sangat membantu saat rollback cepat.

Rollback sederhana yang realistis

Tim kecil tidak butuh sistem rollback yang rumit. Untuk game web statis, rollback sederhana biasanya cukup dengan merilis ulang artifact build terakhir yang stabil atau mengarahkan hosting ke folder release sebelumnya.

Pendekatan yang praktis

  • Simpan artifact build produksi per commit atau per release.
  • Deploy ke direktori yang diberi versi, misalnya berdasarkan SHA commit.
  • Simpan pointer aktif, misalnya alias atau symlink, ke release yang sedang melayani traffic.
  • Saat rollback, ubah pointer itu ke release sebelumnya.

Jika hosting Anda tidak mendukung konsep alias atau symlink, pendekatan lainnya adalah menyimpan manifest release dan menjalankan script redeploy dari artifact lama.

Kunci rollback yang baik bukan hanya bisa kembali ke versi lama, tetapi juga yakin bahwa versi lama itu memang lengkap: HTML, JS, CSS, audio, dan aset lain harus berasal dari build yang sama.

Kapan rollback diperlukan

  • Game blank screen setelah deploy.
  • Input utama tidak berfungsi di perangkat tertentu.
  • Aset salah versi karena cache atau base path keliru.
  • Bug gameplay kritis yang lolos review dan harus dihentikan cepat.

Checklist release harian

Checklist ini cocok untuk tim kecil yang merilis game web setiap hari.

  1. Semua perubahan masuk lewat pull request, bukan push langsung ke main.
  2. Lint, type check, test cepat, dan build verifikasi lulus.
  3. Preview deployment dibuka dan gameplay inti dicoba minimal sekali.
  4. Periksa base path dan referensi aset jika ada perubahan struktur file.
  5. Pastikan build memakai dependency dari lockfile.
  6. Deploy produksi hanya dari branch main.
  7. Simpan artifact atau release output untuk rollback.
  8. Verifikasi pasca-deploy: halaman terbuka, aset termuat, input utama berjalan, dan tidak ada error fatal di console.
  9. Jika ada perubahan konten harian, cek tanggal, level data, atau puzzle source tidak tertukar.

Trade-off: pipeline minimal vs pipeline lengkap

Tidak semua tim butuh pipeline yang sama. Untuk game web harian, keputusan terbaik biasanya bergantung pada ukuran tim, risiko bug, dan target waktu feedback.

Pipeline minimal

Isi umumnya:

  • Install dependency
  • Lint
  • Build
  • Deploy dari main

Kapan dipilih:

  • Proyek masih sangat kecil.
  • Tim 1-2 orang.
  • Logika game sederhana.
  • Target utama adalah rilis cepat dengan overhead rendah.

Kelebihan:

  • Sangat cepat.
  • Mudah dirawat.
  • Lebih sedikit false failure.

Kekurangan:

  • Bug kontrak data atau runtime lebih mudah lolos.
  • Review visual saja sering tidak cukup untuk mencegah regresi logika.

Pipeline lebih lengkap

Isi umumnya:

  • Lint
  • Type check
  • Unit test
  • Build verifikasi
  • Preview deployment
  • Artifact retention
  • Rollback berbasis release

Kapan dipilih:

  • Game dirilis harian dan dimainkan publik.
  • Sudah ada logika puzzle, state, atau scoring yang lebih kompleks.
  • Beberapa orang berkontribusi bersamaan.

Kelebihan:

  • Risiko regresi lebih rendah.
  • Review lebih mudah karena ada preview.
  • Rollback lebih aman.

Kekurangan:

  • Setup awal lebih lama.
  • Waktu CI lebih panjang jika tidak dioptimalkan.
  • Perlu disiplin menjaga test tetap cepat dan stabil.

Untuk banyak tim kecil, titik tengah terbaik adalah: lint + type check + test cepat + build + preview deploy. Ini sudah memberi nilai besar tanpa membuat pipeline terasa berat.

Kesalahan umum dan tips debugging

Build lolos lokal, gagal di CI

  • Periksa perbedaan versi runtime.
  • Pastikan lockfile ter-commit.
  • Cek file path yang sensitif terhadap huruf besar-kecil; CI Linux sering lebih ketat daripada lokal.

Preview jalan, produksi rusak

  • Bandingkan base URL dan konfigurasi asset path.
  • Cek apakah preview dan produksi memakai perintah build yang sama.
  • Pastikan env build tidak berbeda secara diam-diam.

Aset lama masih muncul setelah deploy

  • Pastikan nama file aset di-hash berdasarkan konten.
  • Jangan cache HTML utama terlalu agresif.
  • Verifikasi bahwa referensi file di HTML mengarah ke output build terbaru.

Rollback tidak benar-benar memulihkan aplikasi

  • Jangan rollback hanya sebagian file.
  • Simpan satu paket release utuh, bukan kumpulan aset terpisah yang bisa bercampur antarversi.
  • Uji prosedur rollback sebelum benar-benar dibutuhkan.

Penutup

CI untuk game web harian tidak harus rumit. Untuk tim kecil, yang paling penting adalah memastikan setiap perubahan melewati validasi cepat, bisa ditinjau lewat preview, dibangun secara konsisten, dan dapat dirilis atau di-rollback tanpa drama. Jika Anda mulai dari nol, bangun dulu pipeline minimal yang disiplin: lint, type check bila ada, test cepat, dan build. Setelah itu, tambahkan preview deployment dan artifact release sebagai langkah berikutnya.

Dengan pendekatan ini, rilis harian tetap terasa ringan bagi developer, tetapi cukup aman untuk pemain yang mengakses game setiap hari.