Freeză funcții și freeză cod în dezvoltarea aplicațiilor: esență, diferențe și funcționare

Ce este freeza de funcții?

Feature freeze — este o interdicție temporară de a adăuga funcționalități noi în baza de cod, introdusă înainte de lansarea planificată. Echipa încetează să mai facă merge la funcții și trece la corectarea erorilor, optimizare și lustruirea codului existent. Dezvoltatorii finalizează funcțiile neterminate doar în cadrul remedierilor de erori, fără a extinde domeniul.

Freeza de funcții rezolvă problema funcțiilor neterminate (work-in-progress) care nu apucă lansarea, dar sunt deja parțial îmbinate în ramura principală. Dacă se continuă integrarea de funcții noi, crește riscul de regresie: fiecare integrare nouă necesită retestarea modulelor deja gata. Feature freeze fixează domeniul lansării, transformându-l dintr-o țintă în mișcare într-un set stabil de funcționalități.

Precizare importantă: feature freeze ≠ code freeze. În timpul freezării de funcții sunt permise remedierile de erori, refactorizarea, actualizarea dependențelor și documentației. Sunt interzise doar funcțiile noi vizibile pentru utilizator, adică orice cod care modifică comportamentul aplicației din perspectiva utilizatorului. Verificare la code review: dacă PR adaugă un ecran nou, un buton sau o metodă API — este respins până la ridicarea freezării.

Ce este freeza de cod și cu ce se deosebește de freeza de funcții

Code freeze (freeza de cod) — o practică mai strictă, în care orice modificare în cod este complet interzisă. Nici măcar remedierile de erori nu sunt permise, dacă nu sunt critice. Code freeze se introduce pe termen scurt (de obicei 24-48 de ore) și garantează că build-ul de lansare este compilat dintr-un set fix de commit-uri.

Diferența dintre freeza de funcții și freeza de cod constă în nivelul de control. Freeza de funcții gestionează domeniul: ce anume intră în lansare. Freeza de cod gestionează calitatea: elimină riscul introducerii unei noi erori cu o zi înainte de lansare. În practică, multe echipe folosesc un model în două etape: cu 1-2 săptămâni înainte de lansare — feature freeze, cu 24-48 de ore — code freeze. Code freeze este deosebit de relevant pentru aplicațiile mobile, unde build-ul trebuie încărcat în magazin cu câteva zile înainte de data planificată a lansării.

Excepție de la code freeze — remedierile de securitate pentru vulnerabilitățile critice (CVE cu punctaj 9+). Astfel de modificări trec printr-un proces de urgență cu code review accelerat obligatoriu și notificarea echipei. Toate celelalte modificări sunt amânate până la următorul ciclu de lansare.

Feature freeze vs code freeze: comparație

Alegerea între freeza de funcții și freeza de cod depinde de maturitatea echipei și frecvența lansărilor. Echipele cu CI/CD și feature flags pot folosi doar code freeze de 24 de ore, în timp ce echipele cu lansări lunare folosesc mai des ambele freezări secvențial.

Tipuri de freezări: totală, parțială și BAU-freeze

Pe lângă freeza totală de funcții și freeza de cod, există variante mai flexibile. Partial feature freeze (freeza parțială) blochează funcționalitățile noi doar în anumite module — de exemplu, în modulul de plată sau modulul de autorizare, lăsând celelalte componente deschise pentru modificări.

BAU-freeze (business as usual freeze) — o variantă de compromis, în care sunt interzise doar funcțiile mari cu volum de modificări care depășește un anumit prag (de exemplu, 500 de linii de cod). Îmbunătățirile mici, ajustările UI și remedierile de erori continuă să fie integrate. BAU-freeze este convenabil pentru proiectele cu continuous delivery, unde oprirea completă a dezvoltării pentru o săptămână este neeconomică.

Există, de asemenea, conceptul de deployment freeze (freeza de implementare) — oprirea completă a implementărilor în producție, caracteristică sezonului de sărbători (vacanța de Crăciun, Black Friday). În această perioadă, chiar și hotfix-urile sunt blocate, dacă nu sunt legate de securitate. Deployment freeze durează de obicei 1-2 săptămâni și se coordonează la nivel de companie.

Când să introducem freeza și cât durează

Momentul optim pentru introducerea freezării de funcții — după code complete, când toate funcțiile planificate sunt îmbinate și trec de QA. Termenul concret depinde de ciclul de lansare: pentru un sprint de două săptămâni, freeza de funcții se introduce cu 3-4 zile înainte de data lansării, pentru lansarea lunară — cu 7-10 zile înainte. Code freeze se introduce cu 24-48 de ore înainte de momentul planificat al compilării build-ului de lansare.

Durata freezării trebuie să fie minim suficientă pentru stabilizarea codului. O freeză prea lungă (mai mult de 2 săptămâni) demotivează echipa și creează acumularea de funcții neintegrate, fiecare dintre acestea crescând riscul de conflicte după ridicarea freezării. O freeză prea scurtă (mai puțin de 24 de ore pentru freeza de funcții) nu oferă timp pentru testare completă și remedieri.

Practica recomandată — stabilirea freezării nu după data calendaristică, ci după starea bazei de cod. Freeza de funcții se introduce când numărul de erori deschise în lansare depășește un prag (de exemplu, 10 erori critice). Code freeze — când build-ul trece cu succes testele fum și setul de regresie. Time-based freeze (dată fixă) rămâne standardul pentru industriile reglementate (fintech, medtech), unde data lansării este aprobată de autoritatea de reglementare.

Automatizarea freezărilor prin CI/CD și Git

Controlul manual al freezărilor — o sursă de erori: un dezvoltator poate îmbina accidental un PR care ar trebui să aștepte ridicarea freezării. Automatizarea rezolvă problema prin reguli de protecție a ramurilor Git și pipeline-uri CI/CD. În furnizorul Git (GitHub, GitLab, Bitbucket) se configurează reguli care blochează îmbinările în ramura de lansare fără un tag special sau aprobarea release manager-ului.

Pipeline-ul CI/CD verifică statusul freezării înainte de compilarea build-ului. În Jenkins, GitLab CI sau GitHub Actions se adaugă un pas care citește un fișier de configurare cu programul freezărilor și respinge build-urile dacă data curentă se încadrează în perioada de freeză. Alternativă — un feature flag în panoul de administrare care blochează implementarea în producție.

# .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 de funcții este activă. PR blocat." && exit 1

Scriptul exemplu freeze-check.js citește JSON-ul cu programul freezărilor din rădăcina depozitului. Dacă data curentă se încadrează în intervalul dintre start_date și end_date pentru ramura specificată — pipeline-ul eșuează cu un mesaj despre statusul freezării. Git branch protection adaugă o a doua barieră: chiar dacă pipeline-ul nu a funcționat, regula nu va permite îmbinarea PR-ului fără aprobare.

Greșeli tipice la implementarea freezărilor

Prima greșeală — freeza fără un criteriu clar de ridicare. Echipa îngheață codul, dar nu stabilește ce condiții trebuie îndeplinite pentru dezghețare: zero erori critice, setul de regresie trecut, aprobarea product manager-ului. Fără criterii, freeza se poate prelungi săptămâni întregi. Definition of done pentru freeză trebuie documentată și cunoscută de fiecare dezvoltator.

A doua greșeală — prea multe excepții de la freeză. Fiecare excepție („acest PR nu este o funcție, ci o datorie ”) estompează granița freezării. Dacă excepțiile depășesc 20% din fluxul normal de PR-uri — freeza nu funcționează. Echipa pur și simplu redenumește funcțiile în remedieri de erori pentru a ocoli blocajul.

A treia greșeală — ignorarea candidaților de lansare. Dacă echipa nu construiește build-uri release candidate și implementează direct în producție după code freeze, sensul freezării se pierde: erorile sunt descoperite abia la utilizatori. Release candidate trebuie construit înainte de code freeze, testat de QA și pe staging, și abia după confirmarea calității se introduce code freeze.

A patra greșeală — factorul uman în controlul manual. Dezvoltatorul poate uita să verifice statusul freezării înainte de îmbinare, release manager-ul — să rateze notificarea. Singura soluție fiabilă — blocarea automată la nivelul furnizorului Git sau CI/CD, care elimină eroarea umană.