Feature freeze at code freeze sa pag-develop ng app: esensya, pagkakaiba, at paano gumagana

Ano ang feature freeze?

Feature freeze ay isang pansamantalang pagbabawal sa pagdadagdag ng bagong functionality sa codebase, na ipinapatupad bago ang nakaplanong release. Ang team ay humihinto sa pag-merge ng mga feature at lumilipat sa pag-aayos ng bug, optimisasyon, at pagpapakintab ng umiiral na code. Kinukumpleto ng mga developer ang hindi natapos na mga feature lamang sa loob ng balangkas ng pag-aayos ng bug, nang hindi pinalalawak ang saklaw.

Nalulutas ng feature freeze ang problema ng hindi natapos na mga feature (work-in-progress) na hindi handa sa oras para sa release ngunit bahagyang na-merge na sa pangunahing branch. Kung patuloy na idaragdag ang mga bagong feature, tumataas ang panganib ng regression: bawat bagong integrasyon ay nangangailangan ng muling pagsubok ng mga module na handa na. Feature freeze ay nagtatakda ng saklaw ng release, ginagawa itong mula sa isang gumagalaw na target patungo sa isang matatag na hanay ng functionality.

Mahalagang tala: feature freeze ≠ code freeze. Sa feature freeze, pinapayagan ang pag-aayos ng bug, refactoring, pag-update ng mga dependency, at dokumentasyon. Tanging ang mga bagong user-facing feature lamang ang ipinagbabawal, ibig sabihin, anumang code na nagbabago sa pag-uugali ng app mula sa pananaw ng user. Pagsusuri sa code review: kung ang PR ay nagdadagdag ng bagong screen, button, o API method — ito ay tatanggihan hanggang sa maalis ang freeze.

Ano ang code freeze at paano ito naiiba sa feature freeze

Code freeze ay isang mas mahigpit na praktika kung saan ang lahat ng pagbabago sa code ay ganap na ipinagbabawal. Kahit ang pag-aayos ng bug ay hindi pinapayagan maliban kung ito ay kritikal. Ang code freeze ay ipinapatupad sa maikling panahon (karaniwang 24-48 oras) at ginagarantiyahan na ang release build ay ginawa mula sa isang nakapirming hanay ng mga commit.

Ang pagkakaiba sa pagitan ng feature freeze at code freeze ay nasa antas ng kontrol. Ang feature freeze ay namamahala ng saklaw: kung ano ang eksaktong papasok sa release. Ang code freeze ay namamahala ng kalidad: ang panganib ng pagpasok ng bagong bug isang araw bago ang release ay inaalis. Sa praktika, maraming team ang gumagamit ng dalawang-hakbang na modelo: 1-2 linggo bago ang release — feature freeze, 24-48 oras — code freeze. Code freeze ay lalong mahalaga para sa mga mobile app, kung saan ang build ay kailangang i-upload sa store ilang araw bago ang nakaplanong petsa ng release.

Pagbubukod sa code freeze — mga pag-aayos ng seguridad para sa mga kritikal na kahinaan (CVE na may markang 9+). Ang mga naturang pagbabago ay dumadaan sa emergency process na may mabilis na code review at notipikasyon ng team. Lahat ng iba pang pagbabago ay ipinagpapaliban hanggang sa susunod na cycle ng release.

Feature freeze vs code freeze: paghahambing

Ang pagpili sa pagitan ng feature freeze at code freeze ay depende sa kapanahunan ng team at dalas ng release. Ang mga team na may CI/CD at feature flags ay maaaring limitahan ang kanilang sarili sa code freeze lamang ng 24 na oras, samantalang ang mga team na may buwanang release ay karaniwang gumagamit ng parehong freeze nang sunud-sunod.

Mga uri ng freeze: buo, bahagya, at BAU-freeze

Bukod sa buong feature freeze at code freeze, mayroong mas nababagong mga variant. Partial feature freeze (bahagyang freeze) ay humaharang ng bagong functionality lamang sa mga tiyak na module — halimbawa, sa module ng pagbabayad o module ng authentication, na iniiwan ang iba pang mga component na bukas para sa mga pagbabago.

BAU-freeze (business as usual freeze) — isang kompromisong variant kung saan ang mga malalaking feature lamang na may dami ng pagbabago na higit sa isang tiyak na threshold (hal., 500 linya ng code) ang ipinagbabawal. Ang maliliit na pagpapabuti, UI tweaks, at pag-aayos ng bug ay patuloy na nami-merge. BAU-freeze ay angkop para sa mga proyekto na may continuous delivery, kung saan ang kumpletong paghinto ng pag-develop sa loob ng isang linggo ay hindi ekonomiko.

Mayroon ding konsepto ng deployment freeze — kumpletong paghinto ng mga deploy sa produksyon, karaniwan para sa panahon ng bakasyon (Pasko, Black Friday). Sa panahong ito, kahit ang mga hotfix ay hinaharangan kung hindi ito nauugnay sa seguridad. Ang deployment freeze ay karaniwang tumatagal ng 1-2 linggo at pinag-uugnay sa antas ng kumpanya.

Kailan magpatupad ng freeze at gaano ito katagal

Ang optimal na oras para magpatupad ng feature freeze — pagkatapos ng code complete, kapag ang lahat ng nakaplanong feature ay na-merge na at sumasailalim sa QA. Ang eksaktong panahon ay depende sa cycle ng release: para sa dalawang-linggong sprint, ang feature freeze ay ipinapatupad 3-4 araw bago ang petsa ng release, para sa buwanang release — 7-10 araw bago. Code freeze ay ipinapatupad 24-48 oras bago ang nakaplanong oras ng pagbuo ng release build.

Ang tagal ng freeze ay dapat minimal na sapat para sa pag-stabilize ng code. Ang masyadong mahabang freeze (higit sa 2 linggo) ay nagde-demotivate sa team at nagdudulot ng akumulasyon ng hindi nami-merge na mga feature, na bawat isa pagkatapos alisin ang freeze ay nagpapataas ng panganib ng mga conflict. Ang masyadong maikling freeze (mas mababa sa 24 oras para sa feature freeze) ay hindi nagbibigay ng sapat na oras para sa masusing pagsubok at pag-aayos.

Inirerekomendang praktika — itakda ang freeze hindi batay sa petsa ng kalendaryo, kundi batay sa kalagayan ng codebase. Ang feature freeze ay ipinapatupad kapag ang bilang ng mga bukas na bug para sa release ay lumampas sa threshold (hal., 10 kritikal na bug). Code freeze — kapag ang build ay matagumpay na pumasa sa smoke tests at regression suite. Time-based freeze (nakapirming petsa) ay nananatiling pamantayan para sa mga regulated na industriya (fintech, medtech), kung saan ang petsa ng release ay naaprubahan ng regulator.

Awtomatisasyon ng freeze sa pamamagitan ng CI/CD at Git

Ang manu-manong kontrol ng freeze ay pinagmumulan ng mga pagkakamali: ang developer ay maaaring aksidenteng mag-merge ng PR na dapat maghintay sa pag-alis ng freeze. Ang awtomatisasyon ay lumulutas sa problemang ito sa pamamagitan ng Git branch protection rules at CI/CD pipelines. Sa Git provider (GitHub, GitLab, Bitbucket), ang mga patakaran ay itinatakda na humaharang sa mga merge sa release branch nang walang espesyal na tag o pag-apruba mula sa release manager.

CI/CD pipeline ay sumusuri ng status ng freeze bago buuin ang build. Sa Jenkins, GitLab CI, o GitHub Actions, nagdaragdag ng step na nagbabasa ng configuration file na may iskedyul ng freeze at tinatanggihan ang mga build kung ang kasalukuyang petsa ay nasa loob ng panahon ng freeze. Alternatibo — feature flag sa admin panel na humaharang sa deploy sa produksyon.

# .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 "Ang feature freeze ay aktibo. Naka-block ang PR." && exit 1

Halimbawang script freeze-check.js ay nagbabasa ng JSON na may iskedyul ng freeze mula sa root ng repository. Kung ang kasalukuyang petsa ay nasa loob ng interval sa pagitan ng start_date at end_date para sa tinukoy na branch — ang pipeline ay nabigo na may mensahe tungkol sa status ng freeze. Git branch protection ay nagdadagdag ng pangalawang hadlang: kahit hindi gumana ang pipeline, hindi pinapayagan ng patakaran na i-merge ang PR nang walang pag-apruba.

Mga karaniwang pagkakamali sa pagpapatupad ng freeze

Unang pagkakamali — freeze nang walang malinaw na pamantayan sa pag-alis. Ang team ay nag-freeze ng code ngunit hindi tinutukoy kung anong mga kondisyon ang dapat matupad para sa pag-thaw: zero critical bugs, nakapasa sa regression suite, pag-apruba ng product manager. Kung walang pamantayan, ang freeze ay maaaring tumagal ng mga linggo. Definition of done para sa freeze ay dapat na dokumentado at alam ng bawat developer.

Pangalawang pagkakamali — masyadong maraming pagbubukod sa freeze. Bawat exception ("ang PR na ito ay hindi feature, kundi technical debt") ay lumalabo sa hangganan ng freeze. Kung ang exceptions ay lumampas sa 20% ng normal na daloy ng PR — hindi gumagana ang freeze. Ang team ay pinapalitan lamang ang pangalan ng mga feature sa pag-aayos ng bug upang laktawan ang pagharang.

Pangatlong pagkakamali — pagbalewala sa mga release candidate. Kung ang team ay hindi gumagawa ng release candidate builds at agad na nagde-deploy sa produksyon pagkatapos ng code freeze, nawawala ang kahulugan ng freeze: ang mga bug ay natutuklasan ng mga user. Release candidate ay dapat buuin bago ang code freeze, subukan ng QA at sa staging, at pagkatapos lamang ng kumpirmasyon ng kalidad ay ipatupad ang code freeze.

Pang-apat na pagkakamali — salik ng tao sa manu-manong kontrol. Ang developer ay maaaring makalimot suriin ang status ng freeze bago mag-merge, ang release manager ay maaaring makaligtaan ang notipikasyon. Ang tanging maaasahang solusyon — awtomatikong pagharang sa antas ng Git provider o CI/CD na nag-aalis ng pagkakamali ng tao.