Freeza funkcji i freeza kodu w tworzeniu aplikacji: istota, różnice i działanie

Czym jest freeza funkcji?

Feature freeze — to tymczasowy zakaz dodawania nowej funkcjonalności do bazy kodu, wprowadzany przed planowanym wydaniem. Zespół przestaje mergować funkcje i przełącza się na poprawianie błędów, optymalizację i polerowanie istniejącego kodu. Programiści dopracowują niezakończone funkcje tylko w ramach poprawek błędów, nie rozszerzając zakresu.

Freeza funkcji rozwiązuje problem niezakończonych funkcji (work-in-progress), które nie zdążą na wydanie, ale są już częściowo scalone z główną gałęzią. Jeśli kontynuować włączanie nowych funkcji, rośnie ryzyko regresji: każda nowa integracja wymaga ponownego testowania już gotowych modułów. Feature freeze ustala zakres wydania, przekształcając go z ruchomego celu w stabilny zestaw funkcjonalności.

Ważne uściślenie: feature freeze ≠ code freeze. Przy freezie funkcji dozwolone są poprawki błędów, refaktoryzacja, aktualizacja zależności i dokumentacji. Zakazane są tylko nowe funkcje widoczne dla użytkownika, czyli każdy kod zmieniający zachowanie aplikacji z perspektywy użytkownika. Sprawdzenie przy code review: jeśli PR dodaje nowy ekran, przycisk lub metodę API — jest odrzucany do czasu zdjęcia freezy.

Czym jest freeza kodu i czym różni się od freezy funkcji

Code freeze (freeza kodu) — bardziej rygorystyczna praktyka, w której wszelkie zmiany w kodzie są całkowicie zabronione. Nawet poprawki błędów są niedozwolone, chyba że są krytyczne. Code freeze jest wprowadzany na krótki okres (zwykle 24-48 godzin) i gwarantuje, że wersja wydaniowa jest zbudowana z ustalonego zestawu commitów.

Różnica między freezą funkcji a freezą kodu polega na poziomie kontroli. Freeza funkcji zarządza zakresem: co dokładnie wejdzie do wydania. Freeza kodu zarządza jakością: eliminuje ryzyko wprowadzenia nowego błędu na dzień przed wydaniem. W praktyce wiele zespołów stosuje dwuetapowy model: na 1-2 tygodnie przed wydaniem — feature freeze, na 24-48 godzin — code freeze. Code freeze jest szczególnie istotny dla aplikacji mobilnych, gdzie wersję trzeba przesłać do sklepu na kilka dni przed planowaną datą wydania.

Wyjątek z code freeze — poprawki bezpieczeństwa krytycznych podatności (CVE z oceną 9+). Takie zmiany przechodzą przez proces awaryjny z obowiązkowym przyspieszonym code review i powiadomieniem zespołu. Wszystkie inne zmiany są odkładane do następnego cyklu wydań.

Feature freeze vs code freeze: porównanie

Wybór między freezą funkcji a freezą kodu zależy od dojrzałości zespołu i częstotliwości wydań. Zespoły z CI/CD i feature flags mogą obejść się tylko code freeze na 24 godziny, podczas gdy zespoły z miesięcznymi wydaniami częściej stosują obie freezy sekwencyjnie.

Rodzaje freez: pełna, częściowa i BAU-freeze

Oprócz pełnej freezy funkcji i freezy kodu istnieją bardziej elastyczne warianty. Partial feature freeze (częściowa freeza) blokuje nową funkcjonalność tylko w określonych modułach — na przykład w module płatności lub module autoryzacji, pozostawiając pozostałe komponenty otwarte na zmiany.

BAU-freeze (business as usual freeze) — wariant kompromisowy, w którym zakazane są tylko duże funkcje z objętością zmian przekraczającą określony próg (np. 500 linii kodu). Drobne ulepszenia, poprawki UI i poprawki błędów nadal są włączane. BAU-freeze jest wygodny dla projektów z continuous delivery, gdzie całkowite zatrzymanie rozwoju na tydzień jest ekonomicznie nieopłacalne.

Istnieje również pojęcie deployment freeze (freeza wdrożeń) — całkowite zatrzymanie wdrożeń na produkcję, charakterystyczne dla sezonu świątecznego (wakacje bożonarodzeniowe, Black Friday). W tym okresie nawet hotfixy są blokowane, jeśli nie są związane z bezpieczeństwem. Deployment freeze zwykle trwa 1-2 tygodnie i jest uzgadniany na poziomie firmy.

Kiedy wprowadzić freezę i jak długo trwa

Optymalny moment wprowadzenia freezy funkcji — po code complete, gdy wszystkie zaplanowane funkcje są scalone i przechodzą QA. Konkretny termin zależy od cyklu wydania: dla dwutygodniowego sprintu freeza funkcji jest wprowadzana na 3-4 dni przed datą wydania, dla miesięcznego wydania — na 7-10 dni. Code freeze jest wprowadzany na 24-48 godzin przed planowanym czasem kompilacji wersji wydaniowej.

Czas trwania freezy powinien być minimalnie wystarczający do stabilizacji kodu. Zbyt długa freeza (ponad 2 tygodnie) demotywuje zespół i powoduje nagromadzenie niescalonych funkcji, z których każda po zdjęciu freezy zwiększa ryzyko konfliktów. Zbyt krótka freeza (poniżej 24 godzin dla freezy funkcji) nie daje czasu na pełne testowanie i poprawki.

Zalecana praktyka — ustawiać freezę nie według daty kalendarzowej, ale według stanu bazy kodu. Freeza funkcji jest wprowadzana, gdy liczba otwartych błędów w wydaniu przekracza próg (np. 10 krytycznych błędów). Code freeze — gdy wersja pomyślnie przechodzi testy dymne i zestaw regresyjny. Time-based freeze (stała data) pozostaje standardem dla regulowanych branż (fintech, medtech), gdzie data wydania jest zatwierdzona przez regulatora.

Automatyzacja freez przez CI/CD i Git

Ręczna kontrola freez — źródło błędów: programista może przypadkowo scalic PR, który powinien czekać na zdjęcie freezy. Automatyzacja rozwiązuje problem poprzez reguły ochrony gałęzi Git i pipeline'y CI/CD. W dostawcy Git (GitHub, GitLab, Bitbucket) konfiguruje się reguły blokujące scalanie do gałęzi wydań bez specjalnego tagu lub zgody release managera.

Pipeline CI/CD sprawdza status freezy przed kompilacją wersji. W Jenkins, GitLab CI lub GitHub Actions dodaje się krok, który odczytuje plik konfiguracyjny z harmonogramem freez i odrzuca kompilacje, jeśli bieżąca data przypada w okresie freezy. Alternatywa — feature flag w panelu administracyjnym, który blokuje wdrożenie na produkcję.

# .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 "Freeza funkcji jest aktywna. PR zablokowany." && exit 1

Przykładowy skrypt freeze-check.js odczytuje JSON z harmonogramem freez z katalogu głównego repozytorium. Jeśli bieżąca data przypada w interwał między start_date a end_date dla określonej gałęzi — pipeline kończy się niepowodzeniem z komunikatem o statusie freezy. Git branch protection dodaje drugą barierę: nawet jeśli pipeline nie zadziałał, reguła nie pozwoli na scalenie PR bez zgody.

Typowe błędy przy wdrażaniu freez

Pierwszy błąd — freeza bez jasnego kryterium zdjęcia. Zespół zamraża kod, ale nie określa, jakie warunki muszą być spełnione do odmrożenia: zero krytycznych błędów, pomyślnie przejdziony zestaw regresyjny, zgoda product managera. Bez kryteriów freeza może przeciągnąć się na tygodnie. Definition of done dla freezy powinien być udokumentowany i znany każdemu programiście.

Drugi błąd — zbyt wiele wyjątków z freezy. Każdy wyjątek („ten PR to nie funkcja, a dług techniczny“) rozmywa granicę freezy. Jeśli wyjątki przekraczają 20% normalnego przepływu PR — freeza nie działa. Zespół po prostu zmienia nazwy funkcji na poprawki błędów, aby obejść blokadę.

Trzeci błąd — ignorowanie kandydatów do wydania. Jeśli zespół nie buduje wersji release candidate i od razu wdraża na produkcję po code freeze, sens freezy ginie: błędy są wykrywane dopiero u użytkowników. Release candidate powinien być zbudowany przed code freeze, testowany przez QA i na stagingu, i dopiero po potwierdzeniu jakości wprowadzana jest code freeze.

Czwarty błąd — czynnik ludzki przy ręcznej kontroli. Programista może zapomnieć sprawdzić status freezy przed scaleniem, release manager — przeoczyć powiadomienie. Jedynym niezawodnym rozwiązaniem jest automatyczna blokada na poziomie dostawcy Git lub CI/CD, eliminująca błąd ludzki.