Continuous Deployment untuk Frontend: Panduan Praktis

Continuous deployment artinya: setiap perubahan yang lolos pemeriksaan otomatis langsung terbit ke produksi, tanpa ada orang yang menekan tombol.

Buat sebagian orang itu kedengaran menakutkan. Padahal justru sebaliknya — merilis sering dalam potongan kecil jauh lebih aman daripada menumpuk perubahan sebulan lalu merilisnya sekaligus.

CI, CD, dan continuous delivery

Tiga istilah ini sering dipakai bergantian, padahal berbeda. Bedanya ada di mana campur tangan manusia berhenti.

Istilah	Artinya	Rilis ke produksi
Continuous integration	Tiap push otomatis di-build dan diuji	Manual
Continuous delivery	Tiap perubahan yang lolos siap dirilis kapan saja	Sekali klik
Continuous deployment	Tiap perubahan yang lolos langsung terbit	Otomatis

Untuk situs statis dan Jamstack, continuous deployment adalah bawaan. Kamu menghubungkan repositori ke Netlify, Vercel, atau Cloudflare — dan sejak itu setiap push ke branch utama jadi rilis. Kamu sudah memakainya bahkan kalau belum pernah menyebut namanya.

Kenapa merilis sering justru lebih aman

Ini bagian yang paling berlawanan dengan intuisi.

Kalau kamu merilis sebulan sekali, tiap rilis membawa ratusan perubahan. Begitu ada yang rusak, kamu harus mencari penyebabnya di antara semua itu. Rilisnya jadi peristiwa besar yang menegangkan, jadi orang menundanya, jadi tumpukannya makin besar. Lingkaran yang memburuk sendiri.

Kalau kamu merilis lima kali sehari, tiap rilis membawa satu perubahan kecil. Begitu ada yang rusak, penyebabnya jelas — yang barusan. Rollback-nya sekali klik. Rilis jadi hal biasa yang tidak dipikirkan.

Ukuran yang benar

Yang menentukan keamanan bukan seberapa jarang kamu merilis, tapi seberapa cepat kamu bisa memperbaiki kalau ada yang salah. Rollback sekali klik membuat rilis sering jadi strategi yang aman.

Anatomi pipeline

Pipeline untuk situs modern biasanya begini:

Push ke sebuah branch.
Install dependensi — npm ci, bukan npm install.
Pemeriksaan — lint, pengecekan tipe, tes.
Build — hasilkan berkas produksi.
Deploy preview kalau ini pull request.
Deploy produksi kalau ini branch utama.

Di Netlify, Vercel, dan Cloudflare, langkah 4 sampai 6 sudah ditangani platform. Yang perlu kamu tambahkan biasanya cuma langkah 3.

Kenapa npm ci, bukan npm install

npm install boleh memperbarui package-lock.json kalau ada versi baru yang cocok. Artinya build hari ini bisa memakai versi dependensi yang berbeda dari build kemarin — walau kodemu tidak berubah sama sekali.

npm ci memasang persis apa yang tertulis di lockfile, dan gagal kalau lockfile-nya tidak sinkron. Build jadi bisa diulang dengan hasil sama. Untuk pipeline, selalu pakai ini.

Menambahkan pemeriksaan otomatis

Inilah bagian yang membedakan "deploy otomatis" dari "continuous deployment yang sesungguhnya". Tanpa pemeriksaan, kamu cuma mengotomatiskan penerbitan kode yang rusak.

Contoh workflow GitHub Actions yang berjalan di tiap pull request:

# .github/workflows/periksa.yml
name: Periksa

on:
  pull_request:
  push:
    branches: [main]

jobs:
  periksa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci

      - name: Lint
        run: npm run lint

      - name: Cek tipe
        run: npx tsc --noEmit

      - name: Tes
        run: npm test

      - name: Build
        run: npm run build

Lalu di GitHub, buka Settings lalu Branches, dan jadikan pemeriksaan ini wajib lolos sebelum pull request bisa di-merge. Tanpa langkah itu, workflow-nya cuma memberi tanda merah yang bisa diabaikan.

Mulai dari satu pemeriksaan

Kalau project-mu belum punya apa-apa, jangan langsung menambahkan lima langkah sekaligus. Mulai dengan npm run build saja — itu sudah menangkap sebagian besar kerusakan. Tambahkan lint, tipe, dan tes belakangan.

Empat pengaman yang wajib ada

Deploy otomatis tanpa pengaman itu bukan kepercayaan diri, itu kelalaian.

1. Rollback sekali klik

Semua platform modern menyimpan riwayat deploy dan bisa mengembalikan versi lama seketika. Di Netlify: Deploys, pilih versi lama, Publish deploy. Di Vercel: Deployments, pilih, Promote to Production.

Coba sekali sekarang, saat tidak sedang panik. Kamu perlu tahu di mana tombolnya sebelum kamu benar-benar membutuhkannya.

2. Branch utama yang dilindungi

Wajibkan pull request, dan wajibkan pemeriksaan lolos sebelum merge. Ini mencegah push langsung yang melewati semua pengaman.

3. Preview yang benar-benar dilihat

Deploy preview cuma berguna kalau ada yang membukanya. Jadikan kebiasaan: sebelum menyetujui pull request, buka preview-nya. Penjelasan lengkapnya ada di apa itu deploy preview.

4. Environment variable terpisah

Preview jangan pernah menulis ke database produksi. Pisahkan nilainya per lingkungan sejak awal.

Kapan continuous deployment tidak cocok

Bukan untuk semua situasi. Kalau salah satu ini berlaku, pakai continuous delivery — otomatis sampai siap rilis, lalu rilisnya manual:

Rilis harus diselaraskan dengan pengumuman, kampanye, atau tim lain.
Ada kewajiban kepatuhan yang mengharuskan persetujuan manusia tercatat.
Cakupan pengujianmu masih tipis, jadi lolos pemeriksaan belum berarti aman.

Untuk yang ketiga, solusinya bukan menghindari otomatisasi — melainkan menambah pengujian sampai kamu percaya padanya.

Ringkasan

Hal	Praktik yang benar
Install dependensi	`npm ci`, dengan lockfile ter-commit
Pemeriksaan minimum	Build harus lolos sebelum merge
Branch utama	Dilindungi, wajib lewat pull request
Rollback	Dicoba sekali sebelum dibutuhkan
Env variable	Terpisah antara preview dan produksi
Ukuran rilis	Kecil dan sering, bukan besar dan jarang

Kalau kamu belum menyiapkan alur deploy-nya sama sekali, mulai dari panduan lengkap deploy website. Untuk memahami arsitektur yang membuat semua ini mungkin, lihat apa itu Jamstack.