Feature freeze a code freeze ve vývoji aplikací: podstata, rozdíly a fungování

Co je feature freeze?

Feature freeze — dočasný zákaz přidávání nové funkcionality do kódové báze, zavedený před plánovaným vydáním. Tým přestává mergeovat funkce a přechází na opravy chyb, optimalizaci a leštění stávajícího kódu. Vývojáři dokončují nedokončené funkce pouze v rámci oprav chyb, bez rozšiřování rozsahu.

Feature freeze řeší problém nedokončených funkcí (work-in-progress), které nestíhají vydání, ale jsou již částečně mergenuty do hlavní větve. Pokud se budou přidávat nové funkce, roste riziko regrese: každá nová integrace vyžaduje přetestování již hotových modulů. Feature freeze fixuje rozsah vydání a mění ho z pohyblivého cíle na stabilní sadu funkcionalit.

Důležité upřesnění: feature freeze ≠ code freeze. Při feature freeze jsou povoleny opravy chyb, refaktorování, aktualizace závislostí a dokumentace. Zakázány jsou pouze nové user-facing funkce, tedy jakýkoli kód, který mění chování aplikace z pohledu uživatele. Kontrola při code review: pokud PR přidává novou obrazovku, tlačítko nebo API metodu — je zamítnut až do zrušení zmrazení.

Co je code freeze a jak se liší od feature freeze

Code freeze — přísnější praktika, při které jsou jakékoli změny v kódu zcela zakázány. Dokonce ani opravy chyb nejsou povoleny, pokud nejsou kritické. Code freeze se zavádí na krátkou dobu (obvykle 24-48 hodin) a garantuje, že release build je sestaven z fixní sady commitů.

Rozdíl mezi feature freeze a code freeze je v úrovni kontroly. Feature freeze řídí rozsah: co přesně vstoupí do vydání. Code freeze řídí kvalitu: vylučuje riziko vnesení nové chyby den před vydáním. V praxi mnoho týmů používá dvoufázový model: 1-2 týdny před vydáním — feature freeze, 24-48 hodin — code freeze. Code freeze je zvláště důležitý pro mobilní aplikace, kde je třeba build nahrát do obchodu několik dní před plánovaným datem vydání.

Výjimka z code freeze — bezpečnostní opravy kritických zranitelností (CVE s hodnocením 9+). Takové změny procházejí nouzovým procesem s rychlým code review a oznámením týmu. Všechny ostatní změny se odkládají do dalšího release cyklu.

Feature freeze vs code freeze: srovnání

Výběr mezi feature freeze a code freeze závisí na vyspělosti týmu a frekvenci vydání. Týmy s CI/CD a feature flags se mohou omezit pouze na code freeze na 24 hodin, zatímco týmy s měsíčními vydáními obvykle používají obě zmrazení postupně.

Typy zmrazení: úplné, částečné a BAU-zmrazení

Kromě úplného feature freeze a code freeze existují flexibilnější varianty. Partial feature freeze (částečné zmrazení) blokuje novou funkcionalitu pouze v určitých modulech — například v platebním modulu nebo modulu autentizace, zatímco ostatní komponenty zůstávají otevřené pro změny.

BAU-freeze (business as usual freeze) — kompromisní varianta, při které jsou zakázány pouze velké funkce s objemem změn přes určitý práh (např. 500 řádků kódu). Malá vylepšení, UI úpravy a opravy chyb pokračují. BAU-freeze je vhodný pro projekty s continuous delivery, kde je úplné zastavení vývoje na týden ekonomicky nevýhodné.

Existuje také pojem deployment freeze (deploy zmrazení) — úplné zastavení deployů na produkci, typické pro sváteční období (vánoční svátky, Black Friday). V tomto období jsou blokovány i hotfixy, pokud nesouvisí s bezpečností. Deployment freeze obvykle trvá 1-2 týdny a je koordinován na úrovni společnosti.

Kdy zavést zmrazení a jak dlouho trvá

Optimální okamžik pro zavedení feature freeze — po code complete, kdy jsou všechny plánované funkce mergenuty a procházejí QA. Konkrétní lhůta závisí na release cyklu: pro dvoutýdenní sprint se feature freeze zavádí 3-4 dny před datem vydání, pro měsíční release — 7-10 dní předem. Code freeze se zavádí 24-48 hodin před plánovaným časem sestavení release build.

Doba trvání zmrazení by měla být minimálně dostatečná pro stabilizaci kódu. Příliš dlouhé zmrazení (více než 2 týdny) demotivuje tým a vytváří hromadění nemergenutých funkcí, z nichž každá po zrušení zmrazení zvyšuje riziko konfliktů. Příliš krátké zmrazení (méně než 24 hodin pro feature freeze) neposkytuje dostatek času pro důkladné testování a opravy.

Doporučená praxe — stanovovat zmrazení ne podle kalendářního data, ale podle stavu kódové báze. Feature freeze se zavádí, když počet otevřených bugů pro vydání překročí práh (např. 10 kritických bugů). Code freeze — když build úspěšně projde smoke tests a regression suite. Time-based freeze (pevné datum) zůstává standardem pro regulovaná odvětví (fintech, medtech), kde je datum vydání schváleno regulátorem.

Automatizace zmrazení přes CI/CD a Git

Ruční kontrola zmrazení je zdrojem chyb: vývojář může omylem mergenout PR, který by měl čekat na zrušení zmrazení. Automatizace řeší problém přes Git branch protection pravidla a CI/CD pipeline. U poskytovatele Git (GitHub, GitLab, Bitbucket) se nastavují pravidla blokující merge do release větve bez speciálního tagu nebo schválení od release managera.

CI/CD pipeline kontroluje stav zmrazení před sestavením buildu. V Jenkins, GitLab CI nebo GitHub Actions se přidá krok, který čte konfigurační soubor s rozvrhem zmrazení a odmítá buildy, pokud aktuální datum spadá do období zmrazení. Alternativa — feature flag v admin panelu, který blokuje deploy na produkci.

# .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 je aktivní. PR zablokován." && exit 1

Příklad skriptu freeze-check.js čte JSON s rozvrhem zmrazení z kořene repozitáře. Pokud aktuální datum spadá do intervalu mezi start_date a end_date pro zadanou větev — pipeline selže se zprávou o stavu zmrazení. Git branch protection přidává druhou bariéru: i když pipeline nefunguje, pravidlo nedovolí sloučit PR bez schválení.

Typické chyby při zavádění zmrazení

První chyba — zmrazení bez jasného kritéria zrušení. Tým zmrazí kód, ale neurčí, jaké podmínky musí být splněny pro rozmrazení: nula kritických bugů, úspěšný regression suite, schválení product manažerem. Bez kritérií může zmrazení trvat týdny. Definition of done pro zmrazení musí být zdokumentováno a známé každému vývojáři.

Druhá chyba — příliš mnoho výjimek ze zmrazení. Každá exception ("tento PR není funkce, ale technický dluh") rozmazává hranici zmrazení. Pokud exceptions přesahují 20% běžného toku PR — zmrazení nefunguje. Tým jednoduše přejmenovává funkce na opravy chyb, aby obešel blokování.

Třetí chyba — ignorování release candidate. Pokud tým nesestavuje release candidate buildy a ihned po code freeze deployuje na produkci, smysl zmrazení se ztrácí: chyby objevují uživatelé. Release candidate by měl být sestaven před code freeze, testován QA a na stagingu, a teprve po potvrzení kvality zaveden code freeze.

Čtvrtá chyba — lidský faktor při ruční kontrole. Vývojář může zapomenout zkontrolovat stav zmrazení před mergem, release manager může přehlédnout oznámení. Jediné spolehlivé řešení — automatické blokování na úrovni Git provider nebo CI/CD, které vylučuje lidskou chybu.