Feature freeze и code freeze в разработката на приложения: същност, разлики и работа

Какво е feature freeze?

Feature freeze — временна забрана за добавяне на нова функционалност към кодовата база, въвеждана преди планирано пускане. Екипът спира да merge-ва функции и преминава към поправка на грешки, оптимизация и полиране на съществуващия код. Разработчиците довършват незавършени функции само в рамките на поправки на грешки, без да разширяват обхвата.

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

Важно уточнение: feature freeze ≠ code freeze. При feature freeze са позволени поправки на грешки, рефакторинг, обновяване на зависимости и документация. Забранени са само нови user-facing функции, т.е. всеки код, който променя поведението на приложението от гледна точка на потребителя. Проверка при code review: ако PR добавя нов екран, бутон или API метод — той се отхвърля до сваляне на замразяването.

Какво е code freeze и как се различава от feature freeze

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

Разликата между feature freeze и code freeze е в нивото на контрол. Feature freeze управлява обхвата: какво точно ще влезе в пускането. Code freeze управлява качеството: изключва се рискът от внасяне на нова грешка ден преди пускането. На практика много екипи използват двуетапен модел: 1-2 седмици преди пускането — feature freeze, 24-48 часа — code freeze. Code freeze е особено важен за мобилни приложения, където билдът трябва да се качи в магазина няколко дни преди планираната дата на пускане.

Изключение от code freeze — поправки за сигурност на критични уязвимости (CVE с оценка 9+). Такива промени преминават през авариен процес с бърз code review и уведомяване на екипа. Всички други промени се отлагат до следващия цикъл на пускане.

Feature freeze vs code freeze: сравнение

Изборът между feature freeze и code freeze зависи от зрелостта на екипа и честотата на пускания. Екипи с CI/CD и feature flags могат да се ограничат само до code freeze за 24 часа, докато екипи с месечни пускания обикновено използват и двете замразявания последователно.

Видове замразявания: пълно, частично и BAU-замразяване

Освен пълното feature freeze и code freeze съществуват по-гъвкави варианти. Partial feature freeze (частично замразяване) блокира нова функционалност само в определени модули — например в платежния модул или модула за удостоверяване, оставяйки останалите компоненти отворени за промени.

BAU-freeze (business as usual freeze) — компромисен вариант, при който са забранени само големите функции с обем на промени над определен праг (например 500 реда код). Малки подобрения, UI-корекции и поправки на грешки продължават. BAU-freeze е удобен за проекти с continuous delivery, където пълното спиране на разработката за седмица е икономически неизгодно.

Съществува и понятието deployment freeze (замразяване на пускане) — пълно спиране на пусканията в продукция, характерно за празничния сезон (коледни празници, Black Friday). През този период дори hotfix-овете се блокират, ако не са свързани със сигурността. Deployment freeze обикновено трае 1-2 седмици и се координира на ниво компания.

Кога да се въведе замразяване и колко дълго трае

Оптималният момент за въвеждане на feature freeze — след code complete, когато всички планирани функции са merge-нати и преминават QA. Конкретният срок зависи от цикъла на пускане: за двуседмичен sprint feature freeze се въвежда 3-4 дни преди датата на пускане, за месечно пускане — 7-10 дни предварително. Code freeze се въвежда 24-48 часа преди планираното време за изграждане на версията за пускане.

Продължителността на замразяване трябва да бъде минимално достатъчна за стабилизиране на кода. Твърде дългото замразяване (повече от 2 седмици) демотивира екипа и създава натрупване на немержирани функции, всяка от които след сваляне на замразяването увеличава риска от конфликти. Твърде краткото замразяване (по-малко от 24 часа за feature freeze) не дава достатъчно време за щателно тестване и поправки.

Препоръчителна практика — определяйте замразяването не по календарна дата, а по състоянието на кодовата база. Feature freeze се въвежда, когато броят на отворените грешки за пускането надвиши праг (например 10 критични грешки). Code freeze — когато билдът успешно премине smoke tests и regression suite. Time-based freeze (фиксирана дата) остава стандарт за регулирани индустрии (финтех, медтех), където датата на пускане е одобрена от регулатора.

Автоматизация на замразяванията чрез CI/CD и Git

Ръчният контрол на замразяванията е източник на грешки: разработчик може случайно да merge-не PR, който трябва да чака сваляне на замразяването. Автоматизацията решава проблема чрез Git branch protection правила и CI/CD pipeline-и. В Git доставчика (GitHub, GitLab, Bitbucket) се настройват правила, блокиращи merge-ване в клона за пускане без специален таг или одобрение от release manager.

CI/CD pipeline проверява статуса на замразяване преди изграждане на билда. В 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 "Feature freeze е активен. PR е блокиран." && exit 1

Примерният скрипт freeze-check.js чете JSON с графика на замразяванията от корена на хранилището. Ако текущата дата попада в интервала между start_date и end_date за посочения клон — pipeline-ът се проваля със съобщение за статуса на замразяване. Git branch protection добавя втора бариера: дори ако pipeline-ът не работи, правилото не позволява сливане на PR без одобрение.

Типични грешки при въвеждане на замразявания

Първата грешка — замразяване без ясен критерий за сваляне. Екипът замразява кода, но не определя какви условия трябва да се изпълнят за размразяване: нула критични грешки, преминат regression suite, одобрение от продукт мениджъра. Без критерии замразяването може да продължи седмици. Definition of done за замразяването трябва да бъде документирано и известно на всеки разработчик.

Втората грешка — твърде много изключения от замразяването. Всяко exception ("този PR не е функция, а технически дълг") размива границата на замразяването. Ако exceptions надвишават 20% от нормалния поток PR — замразяването не работи. Екипът просто преименува функциите на поправки на грешки, за да заобиколи блокирането.

Третата грешка — игнориране на release candidate. Ако екипът не изгражда release candidate билдове и веднага след code freeze пуска в продукция, смисълът на замразяването се губи: грешките се откриват от потребителите. Release candidate трябва да се изгради преди code freeze, да се тества от QA и на staging, и само след потвърждение на качеството да се въведе code freeze.

Четвъртата грешка — човешкият фактор при ръчен контрол. Разработчик може да забрави да провери статуса на замразяване преди merge, release manager може да пропусне уведомлението. Единственото надеждно решение — автоматично блокиране на ниво Git provider или CI/CD, което изключва човешката грешка.