Feature freeze és code freeze az alkalmazásfejlesztésben: lényeg, különbségek és működés

Mi az a feature freeze?

Feature freeze — a kódbázisba történő új funkcionalitás hozzáadásának ideiglenes tiltása, amelyet a tervezett kiadás előtt vezetnek be. A csapat abbahagyja a funkciók merge-elését, átvált a hibajavításra, optimalizálásra és a meglévő kód csiszolására. A fejlesztők a befejezetlen funkciókat csak a hibajavítások keretein belül fejezik be, a hatókör kiterjesztése nélkül.

A feature freeze megoldja a befejezetlen funkciók (work-in-progress) problémáját, amelyek nem készülnek el időben a kiadásra, de már részben be vannak merge-elődve a fő ágba. Ha további új funkciókat adnak hozzá, nő a regresszió kockázata: minden új integráció a már kész modulok újratesztelését igényli. Feature freeze rögzíti a kiadás hatókörét, mozgó céltáblól stabil funkcionalitáskészletté változtatva azt.

Fontos pontosítás: feature freeze ≠ code freeze. A feature freeze alatt a hibajavítások, refaktorálás, függőségek frissítése és dokumentáció engedélyezett. Csak az új user-facing funkciók tiltottak, azaz minden olyan kód, amely megváltoztatja az alkalmazás viselkedését a felhasználó szempontjából. Ellenőrzés code review-nál: ha egy PR új képernyőt, gombot vagy API metódust ad hozzá — elutasításra kerül a fagyasztás feloldásáig.

Mi az a code freeze és miben különbözik a feature freezetől

Code freeze (kódfagyasztás) — szigorúbb gyakorlat, amelyben a kódban végrehajtott bármilyen változtatás teljesen tiltott. Még a hibajavítások sem engedélyezettek, hacsak nem kritikusak. A code freeze rövid időtartamra (általában 24-48 óra) érvényes, és garantálja, hogy a kiadási build rögzített commitkészletből készül.

A különbség a feature freeze és a code freeze között az ellenőrzés szintjében rejlik. A feature freeze a hatókört kezeli: hogy pontosan mi kerül be a kiadásba. A code freeze a minőséget kezeli: kizárja annak kockázatát, hogy egy nappal a kiadás előtt új hiba kerüljön be. A gyakorlatban sok csapat kétlépcsős modellt használ: 1-2 héttel a kiadás előtt — feature freeze, 24-48 órával — code freeze. Code freeze különösen fontos a mobilalkalmazásoknál, ahol a buildet néhány nappal a tervezett kiadási dátum előtt fel kell tölteni az áruházba.

Kivétel a code freeze alól — a kritikus biztonsági rések (CVE 9+ pontszámmal) javítása. Az ilyen változtatások sürgősségi eljáráson mennek keresztül gyorsított code review-val és csapatértesítéssel. Minden egyéb változtatás a következő kiadási ciklusra halasztódik.

Feature freeze vs code freeze: összehasonlítás

A választás a feature freeze és a code freeze között a csapat érettségétől és a kiadások gyakoriságától függ. A CI/CD-t és feature flageket használó csapatok megelégedhetnek csak 24 órás code freeze-zel, míg a havi kiadású csapatok általában mindkét fagyasztást egymás után alkalmazzák.

A fagyasztások típusai: teljes, részleges és BAU-fagyasztás

A teljes feature freeze és code freeze mellett léteznek rugalmasabb változatok is. Partial feature freeze (részleges fagyasztás) csak bizonyos modulokban blokkolja az új funkcionalitást — például a fizetési modulban vagy a hitelesítési modulban, a többi komponenst nyitva hagyva a változtatások számára.

BAU-freeze (business as usual freeze) — kompromisszumos változat, amelyben csak a nagyobb funkciók tiltottak, amelyek változtatási terjedelme meghalad egy bizonyos küszöbértéket (például 500 kódsort). A kisebb fejlesztések, UI-módosítások és hibajavítások továbbra is bekerülhetnek. BAU-freeze hasznos a folyamatos szállítással (continuous delivery) működő projektek számára, ahol a fejlesztés egy hétre történő teljes leállítása gazdaságtalan.

Létezik továbbá a deployment freeze (telepítési fagyasztás) fogalma — az élesörbe történő telepítések teljes leállítása, amely az ünnepi időszakra (karácsonyi szünidő, Black Friday) jellemző. Ebben az időszakban még a hotfixek is blokkolva vannak, hacsak nem biztonsági jellegűek. A deployment freeze általában 1-2 hétig tart és vállalati szinten egyeztetik.

Mikor vezessünk be fagyasztást és meddig tartson

A feature freeze bevezetésének optimális időpontja — a code complete után, amikor az összes tervezett funkció be van merge-elődve és QA-n megy keresztül. A konkrét határidő a kiadási ciklustól függ: két hetes sprintnél a feature freeze 3-4 nappal a kiadási dátum előtt, havi kiadásnál 7-10 nappal korábban kerül bevezetésre. Code freeze 24-48 órával a kiadási build tervezett összeállítási ideje előtt kerül bevezetésre.

A fagyasztás időtartamának minimálisan elegendőnek kell lennie a kód stabilizálásához. A túl hosszú fagyasztás (több mint 2 hét) demotiválja a csapatot, és a nem merge-elt funkciók felhalmozódásához vezet, amelyek mindegyike a fagyasztás feloldása után növeli a konfliktusok kockázatát. A túl rövid fagyasztás (kevesebb mint 24 óra a feature freeze esetében) nem ad elegendő időt az alapos teszteléshez és javításokhoz.

Ajánlott gyakorlat — a fagyasztást ne naptári dátum, hanem a kódbázis állapota alapján határozzuk meg. A feature freeze akkor kerül bevezetésre, amikor a kiadáshoz tartozó nyitott hibák száma meghalad egy küszöbértéket (például 10 kritikus hiba). Code freeze — amikor a build sikeresen átmegy a smoke teszteken és a regression suite-on. Time-based freeze (rögzített dátum) továbbra is szabvány a szabályozott iparágakban (fintech, medtech), ahol a kiadás dátumát a szabályozó hagyta jóvá.

Fagyasztások automatizálása CI/CD-n és Git-en keresztül

A fagyasztások kézi ellenőrzése hibaforrás: a fejlesztő véletlenül merge-elhet egy olyan PR-t, amelynek a fagyasztás feloldására kellene várnia. Az automatizálás megoldja a problémát a Git branch protection szabályok és CI/CD pipeline-ok segítségével. A Git-szolgáltatónál (GitHub, GitLab, Bitbucket) olyan szabályok állíthatók be, amelyek blokkolják a kiadási ágba történő merge-elést különleges címke vagy a release manager jóváhagyása nélkül.

CI/CD pipeline ellenőrzi a fagyasztás állapotát a build összeállítása előtt. Jenkinsben, GitLab CI-ben vagy GitHub Actionsban hozzáadható egy lépés, amely beolvassa a fagyasztások ütemezését tartalmazó konfigurációs fájlt, és elutasítja a buildeket, ha az aktuális dátum a fagyasztás időszakába esik. Alternatíva — feature flag az admin panelben, amely blokkolja az élesörbe történő telepítést.

# .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 aktív. PR blokkolva." && exit 1

A freeze-check.js példaszkript beolvassa a JSON-t a fagyasztások ütemezésével a tár gyökeréből. Ha az aktuális dátum a megadott ág start_date és end_date közötti intervallumába esik — a pipeline meghiúsul a fagyasztás állapotáról szóló üzenettel. Git branch protection második gátként szolgál: ha a pipeline nem is működik, a szabályok nem engedik a PR merge-elését jóváhagyás nélkül.

Tipikus hibák a fagyasztások bevezetésénél

Az első hiba — a fagyasztás egyértelmű feloldási kritériumok nélkül. A csapat befagyasztja a kódot, de nem határozza meg, hogy milyen feltételeknek kell teljesülniük a felolvasztáshoz: nulla kritikus hiba, sikeres regression suite, product manager jóváhagyása. Kritériumok nélkül a fagyasztás hetekig elhúzódhat. Definition of done a fagyasztáshoz dokumentálva kell legyen és minden fejlesztő számára ismert.

A második hiba — túl sok kivétel a fagyasztás alól. Minden exception („ez a PR nem funkció, hanem technikai adósság”) elmosá a fagyasztás határát. Ha az exceptions meghaladja a normális PR-forgalom 20%-át — a fagyasztás nem működik. A csapat egyszerűen átnevezi a funkciókat hibajavításoknak, hogy megkerülje a blokkolást.

A harmadik hiba — a release candidate-k figyelmen kívül hagyása. Ha a csapat nem állít össze release candidate buildeket, és a code freeze után azonnal élesörbe telepít, a fagyasztás értelme elvész: a hibákat a felhasználók fedezik fel. Release candidate-t a code freeze előtt kell összeállítani, QA-n és stagingen tesztelni, és csak a minőség megerősítése után bevezetni a code freeze-t.

A negyedik hiba — emberi tényező a kézi ellenőrzésben. A fejlesztő elfelejtheti ellenőrizni a fagyasztás állapotát merge-elés előtt, a release manager át nézheti az értesítést. Az egyetlen megbízható megoldás — automatikus blokkolás a Git provider vagy CI/CD szintjén, amely kizárja az emberi hibát.