Feature freeze dan code freeze dalam pengembangan aplikasi: esensi, perbedaan, dan cara kerja

Apa itu feature freeze?

Feature freeze adalah larangan sementara penambahan fungsionalitas baru ke basis kode, diterapkan sebelum rilis yang direncanakan. Tim berhenti melakukan merge fitur dan beralih ke perbaikan bug, optimasi, dan pemolesan kode yang ada. Pengembang menyelesaikan fitur yang belum selesai hanya dalam kerangka perbaikan bug, tanpa memperluas lingkup.

Feature freeze memecahkan masalah fitur yang belum selesai (work-in-progress) yang tidak siap tepat waktu untuk rilis tetapi sudah sebagian di-merge ke cabang utama. Jika fitur baru terus ditambahkan, risiko regresi meningkat: setiap integrasi baru memerlukan pengujian ulang modul yang sudah jadi. Feature freeze menetapkan lingkup rilis, mengubahnya dari target bergerak menjadi kumpulan fungsionalitas yang stabil.

Catatan penting: feature freeze ≠ code freeze. Pada feature freeze, perbaikan bug, refactoring, pembaruan dependensi, dan dokumentasi diizinkan. Hanya fitur baru yang menghadap pengguna (user-facing features) yang dilarang, yaitu kode apa pun yang mengubah perilaku aplikasi dari sudut pandang pengguna. Pemeriksaan di code review: jika PR menambahkan layar, tombol, atau metode API baru — PR ditolak hingga freeze dicabut.

Apa itu code freeze dan perbedaannya dengan feature freeze

Code freeze adalah praktik yang lebih ketat di mana semua perubahan kode dilarang sepenuhnya. Bahkan perbaikan bug tidak diizinkan kecuali bersifat kritis. Code freeze diterapkan untuk waktu singkat (biasanya 24-48 jam) dan menjamin bahwa build rilis dibuat dari kumpulan commit yang tetap.

Perbedaan antara feature freeze dan code freeze terletak pada tingkat kontrol. Feature freeze mengelola lingkup: apa yang masuk ke dalam rilis. Code freeze mengelola kualitas: risiko masuknya bug baru sehari sebelum rilis dihilangkan. Dalam praktiknya, banyak tim menggunakan model dua tahap: 1-2 minggu sebelum rilis — feature freeze, 24-48 jam — code freeze. Code freeze sangat penting untuk aplikasi mobile, di mana build harus diunggah ke toko beberapa hari sebelum tanggal rilis yang direncanakan.

Pengecualian dari code freeze — perbaikan keamanan untuk kerentanan kritis (CVE dengan skor 9+). Perubahan semacam itu melalui proses darurat dengan code review cepat dan pemberitahuan tim. Semua perubahan lain ditunda hingga siklus rilis berikutnya.

Feature freeze vs code freeze: perbandingan

Pemilihan antara feature freeze dan code freeze tergantung pada kematangan tim dan frekuensi rilis. Tim dengan CI/CD dan feature flags dapat membatasi diri hanya pada code freeze selama 24 jam, sementara tim dengan rilis bulanan biasanya menggunakan kedua freeze secara berurutan.

Jenis freeze: penuh, parsial, dan BAU-freeze

Selain feature freeze penuh dan code freeze, ada varian yang lebih fleksibel. Partial feature freeze (freeze parsial) memblokir fungsionalitas baru hanya di modul tertentu — misalnya, di modul pembayaran atau modul otentikasi, membiarkan komponen lain terbuka untuk perubahan.

BAU-freeze (business as usual freeze) — varian kompromi di mana hanya fitur besar dengan volume perubahan di atas ambang tertentu (misalnya, 500 baris kode) yang dilarang. Peningkatan kecil, penyesuaian UI, dan perbaikan bug terus berlanjut. BAU-freeze cocok untuk proyek dengan continuous delivery, di mana penghentian pengembangan total selama seminggu tidak ekonomis.

Juga ada konsep deployment freeze (freeze deploy) — penghentian total deploy ke produksi, khas untuk musim liburan (liburan Natal, Black Friday). Dalam periode ini, bahkan hotfix diblokir jika tidak terkait dengan keamanan. Deployment freeze biasanya berlangsung 1-2 minggu dan dikoordinasikan di tingkat perusahaan.

Kapan menerapkan freeze dan berapa lama berlangsung

Waktu optimal untuk menerapkan feature freeze — setelah code complete, ketika semua fitur yang direncanakan telah di-merge dan menjalani QA. Jangka waktu pastinya tergantung pada siklus rilis: untuk sprint dua minggu, feature freeze diterapkan 3-4 hari sebelum tanggal rilis, untuk rilis bulanan — 7-10 hari sebelumnya. Code freeze diterapkan 24-48 jam sebelum waktu build rilis yang direncanakan.

Durasi freeze harus minimal cukup untuk stabilisasi kode. Freeze yang terlalu panjang (lebih dari 2 minggu) mendemotivasi tim dan menyebabkan penumpukan fitur yang belum di-merge, yang masing-masing meningkatkan risiko konflik setelah freeze dicabut. Freeze yang terlalu pendek (kurang dari 24 jam untuk feature freeze) tidak memberikan waktu yang cukup untuk pengujian dan perbaikan yang memadai.

Praktik yang direkomendasikan — menetapkan freeze bukan berdasarkan tanggal kalender, tetapi berdasarkan kondisi basis kode. Feature freeze diterapkan ketika jumlah bug terbuka untuk rilis melebihi ambang batas (misalnya, 10 bug kritis). Code freeze — ketika build berhasil melewati smoke tests dan regression suite. Time-based freeze (tanggal tetap) tetap menjadi standar untuk industri yang diatur (fintech, medtech), di mana tanggal rilis disetujui oleh regulator.

Otomatisasi freeze melalui CI/CD dan Git

Kontrol freeze secara manual adalah sumber kesalahan: pengembang mungkin secara tidak sengaja melakukan merge PR yang seharusnya menunggu freeze dicabut. Otomatisasi memecahkan masalah ini melalui aturan perlindungan cabang Git dan pipeline CI/CD. Di penyedia Git (GitHub, GitLab, Bitbucket), aturan diatur untuk memblokir merge ke cabang rilis tanpa tag khusus atau persetujuan dari release manager.

Pipeline CI/CD memeriksa status freeze sebelum membangun build. Di Jenkins, GitLab CI, atau GitHub Actions, ditambahkan langkah yang membaca file konfigurasi dengan jadwal freeze dan menolak build jika tanggal saat ini jatuh dalam periode freeze. Alternatif — feature flag di panel admin yang memblokir deploy ke produksi.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze aktif. PR diblokir." && exit 1

Contoh skrip freeze-check.js membaca JSON dengan jadwal freeze dari root repositori. Jika tanggal saat ini berada dalam interval antara start_date dan end_date untuk cabang yang ditentukan — pipeline gagal dengan pesan tentang status freeze. Perlindungan cabang Git menambahkan penghalang kedua: bahkan jika pipeline tidak berfungsi, aturan tidak mengizinkan merge PR tanpa persetujuan.

Kesalahan umum dalam penerapan freeze

Kesalahan pertama — freeze tanpa kriteria pencabutan yang jelas. Tim membekukan kode tetapi tidak menentukan kondisi apa yang harus dipenuhi untuk pencairan: zero critical bugs, lulus regression suite, persetujuan product manager. Tanpa kriteria, freeze bisa berlangsung berminggu-minggu. Definition of done untuk freeze harus didokumentasikan dan diketahui setiap pengembang.

Kesalahan kedua — terlalu banyak pengecualian dari freeze. Setiap exception ("PR ini bukan fitur, tetapi utang teknis") mengaburkan batas freeze. Jika exceptions melebihi 20% dari aliran PR normal — freeze tidak berfungsi. Tim hanya mengganti nama fitur menjadi perbaikan bug untuk menghindari pemblokiran.

Kesalahan ketiga — mengabaikan release candidate. Jika tim tidak membuat build release candidate dan langsung deploy ke produksi setelah code freeze, makna freeze hilang: bug ditemukan oleh pengguna. Release candidate harus dibuat sebelum code freeze, diuji oleh QA dan di staging, dan hanya setelah konfirmasi kualitas, code freeze diterapkan.

Kesalahan keempat — faktor manusia dalam kontrol manual. Pengembang mungkin lupa memeriksa status freeze sebelum merge, release manager mungkin melewatkan notifikasi. Satu-satunya solusi yang dapat diandalkan — pemblokiran otomatis di tingkat Git provider atau CI/CD yang menghilangkan kesalahan manusia.