Фриз функција и фриз кода у развоју апликација: суштина, разлике и рад

Шта је фриз функција?

Feature freeze — привремена је забрана додавања нове функционалности у базу кода, која се уводи пре планираног издања. Тим престаје да међује функције и прелази на исправљање грешака, оптимизацију и полирање постојећег кода. Програмери довршавају незавршене функције само у оквиру исправки грешака, не ширећи обим.

Фриз функција решава проблем незавршених функција (work-in-progress) које не стижу за издање, али су већ делимично спојене у главну грану. Ако се настави са убацивањем нових функција, расте ризик од регресије: свака нова интеграција захтева поновно тестирање већ готових модула. Feature freeze фиксира обим издања, претварајући га из покретне мете у стабилан скуп функционалности.

Важно појашњење: feature freeze ≠ code freeze. При фризу функција дозвољене су исправке грешака, рефакторисање, ажурирање зависности и документације. Забрањене су само нове функције видљиве кориснику, односно било који код који мења понашање апликације из перспективе корисника. Провера на code review: ако PR додаје нови екран, дугме или API метод — одбија се до укидања фриза.

Шта је фриз кода и чему се разликује од фриза функција

Code freeze (фриз кода) — строжа је пракса, у којој су било какве промене у коду потпуно забрањене. Чак ни исправке грешака нису дозвољене, осим ако су критичне. Code freeze се уводи на кратак рок (обично 24-48 сати) и гарантује да је издашни билд направљен из фиксног скупа комитова.

Разлика између фриза функција и фриза кода је у нивоу контроле. Фриз функција управља обимом: шта тачно улази у издање. Фриз кода управља квалитетом: елиминише ризик уношења нове грешке дан пре издања. У пракси многи тимови користе двоетапни модел: 1-2 недеље пре издања — feature freeze, 24-48 сати — code freeze. Code freeze је посебно актуелан за мобилне апликације, где билд треба отпремити у продавницу неколико дана пре планираног датума издања.

Изузетак из code freeze — безбедносне исправке критичних рањивости (CVE са оценом 9+). Такве промене пролазе кроз хитни процес са обавезним убрзаним code review и обавештавањем тима. Све остале промене се одлажу до следећег издашног циклуса.

Feature freeze vs code freeze: поређење

Избор између фриза функција и фриза кода зависи од зрелости тима и учесталости издања. Тимови са CI/CD и feature flags могу се снаћи само са code freeze од 24 сата, док тимови са месечним издањима чешће користе оба фриза секвенцијално.

Типови фризова: потпуни, делимични и BAU-freeze

Поред потпуног фриза функција и фриза кода постоје флексибилније варијанте. Partial feature freeze (делимични фриз) блокира нову функционалност само у одређеним модулима — на пример, у модулу плаћања или модулу ауторизације, остављајући остале компоненте отвореним за промене.

BAU-freeze (business as usual freeze) — компромисна варијанта, у којој су забрањене само велике функције са обимом промена већим од одређеног прага (нпр. 500 линија кода). Мала побољшања, UI подешавања и исправке грешака настављају да се убацују. BAU-freeze је погодан за пројекте са continuous delivery, где је потпуно заустављање развоја на недељу дана економски неисплативо.

Такође постоји концепт deployment freeze (деплој-фриз) — потпуно заустављање деплоја на продукцију, карактеристично за празничну сезону (Божић, Black Friday). У овом периоду чак се и хотфикси блокирају, ако нису везани за безбедност. Deployment freeze обично траје 1-2 недеље и усклађује се на нивоу компаније.

Када увести фриз и колико траје

Оптималан тренутак увођења фриза функција — након code complete, када су све планиране функције спојене и пролазе QA. Конкретан рок зависи од циклуса издања: за двонедељни спринт фриз функција се уводи 3-4 дана пре датума издања, за месечно издање — 7-10 дана пре. Code freeze се уводи 24-48 сати пре планираног времена компилације издашног билда.

Трајање фриза треба да буде минимално довољно за стабилизацију кода. Предугачак фриз (више од 2 недеље) демотивише тим и ствара нагомилавање неспојених функција, од којих свака након укидања фриза повећава ризик од конфликата. Прекратак фриз (мање од 24 сата за фриз функција) не даје времена за потпуно тестирање и исправке.

Препоручена пракса — постављати фриз не по календарском датуму, већ по стању базе кода. Фриз функција се уводи када број отворених грешака у издању премаши праг (нпр. 10 критичних грешака). Code freeze — када билд успешно прође smoke tests и регресиони скуп. Time-based freeze (фиксни датум) остаје стандард за регулисане индустрије (финтек, медтек), где је датум издања одобрен од регулатора.

Аутоматизација фризова кроз CI/CD и Git

Ручна контрола фризова — извор грешака: програмер може случајно да споји PR који треба да чека укидање фриза. Аутоматизација решава проблем кроз Git branch protection правила и CI/CD пајплајнове. У Git провајдеру (GitHub, GitLab, Bitbucket) подешавају се правила која блокирају спајање у издашну грану без посебног тага или одобрења release manager-а.

CI/CD пајплајн проверава статус фриза пре компилације билда. У Jenkins, GitLab CI или GitHub Actions додаје се корак који чита конфигурациони фајл са распоредом фризова и одбија билдове ако тренутни датум пада у период фриза. Алтернатива — feature flag у админ панелу који блокира деплој на продукцију.

# .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 "Фриз функција је активан. PR блокиран." && exit 1

Пример скрипте freeze-check.js чита JSON са распоредом фризова из корена репозиторијума. Ако тренутни датум пада у интервал између start_date и end_date за наведену грану — пајплајн не успева са поруком о статусу фриза. Git branch protection додаје другу баријеру: чак и ако пајплајн није радио, правило неће дозволити спајање PR-а без одобрења.

Типичне грешке при увођењу фризова

Прва грешка — фриз без јасног критеријума укидања. Тим замрзава код, али не одређује који услови морају бити испуњени за одмрзавање: нула критичних грешака, пролазак регресионог скупа, одобрење product manager-а. Без критеријума фриз се може одужити на недеље. Definition of done за фриз мора бити документован и познат сваком програмеру.

Друга грешка — превише изузетака из фриза. Сваки изузетак („овај PR није функција, већ технички дуг”) замагљује границу фриза. Ако изузеци премашују 20% нормалног тока PR-ова — фриз не ради. Тим једноставно преименује функције у исправке грешака да би заобишао блокаду.

Трећа грешка — игнорисање release candidate-а. Ако тим не прави release candidate билдове и одмах деплојује на продукцију након code freeze, смисао фриза се губи: грешке се откривају тек код корисника. Release candidate треба направити пре code freeze, тестирати га од стране QA и на стејџингу, и тек након потврде квалитета увести code freeze.

Четврта грешка — људски фактор при ручној контроли. Програмер може заборавити да провери статус фриза пре спајања, release manager — да пропусти обавештење. Једино поуздано решење — аутоматско блокирање на нивоу Git провајдера или CI/CD, које елиминише људску грешку.