Feature freeze та code freeze у розробці додатків: суть, відмінності та роль

Що таке feature freeze?

Feature freeze — це тимчасова заборона на додавання нового функціоналу в кодову базу, що вводиться перед запланованим релізом. Команда перестає merge-ити фічі та перемикається на виправлення багів, оптимізацію та полірування існуючого коду. Розробники доопрацьовують незавершені фічі тільки в рамках багфіксів, не розширюючи scope.

Feature freeze вирішує проблему незавершених фіч (work-in-progress), які не встигають до релізу, але вже частково змержені в основну гілку. Якщо продовжувати вливати нові фічі, зростає ризик регресії: кожна нова інтеграція потребує перетестування вже готових модулів. Feature freeze фіксує scope релізу, перетворюючи його з рухомої мішені на стабільний набір функціоналу.

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

Що таке code freeze та чим відрізняється від feature freeze

Code freeze — більш жорстка практика, при якій будь-які зміни в коді заборонені повністю. Навіть виправлення багів не допускаються, якщо вони не є критичними. Code freeze вводиться на короткий термін (зазвичай 24-48 годин) і гарантує, що релізний білд зібраний з фіксованого набору комітів.

Різниця між feature freeze та code freeze — у рівні контролю. Feature freeze керує scope: що саме увійде в реліз. Code freeze керує quality: виключається ризик внесення нової помилки за день до релізу. На практиці багато команд використовують двоетапну модель: за 1-2 тижні до релізу — feature freeze, за 24-48 годин — code freeze. Code freeze особливо актуальний для мобільних додатків, де білд потрібно завантажувати в стор за кілька днів до planned release date.

Виняток з code freeze — security-фікси критичних вразливостей (CVE з оцінкою 9+). Такі зміни проходять через emergency process з обов'язковим fast-track code review та notification команди. Всі інші зміни відкладаються до наступного релізного циклу.

Feature freeze vs code freeze: порівняння

Вибір між feature freeze та code freeze залежить від maturity команди та частоти релізів. Команди з CI/CD та feature flags можуть обходитися тільки code freeze на 24 години, тоді як команди з monthly releases частіше використовують обидва фризи послідовно.

Типи фризів: повний, частковий та BAU-freeze

Крім повного feature freeze та code freeze існують більш гнучкі варіанти. Partial feature freeze (частковий фриз) блокує новий функціонал тільки в певних модулях — наприклад, у платіжному модулі або модулі авторизації, залишаючи інші компоненти відкритими для змін.

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

Також існує поняття deployment freeze (деплой-фриз) — повна зупинка деплоїв на продакшен, характерна для holiday season (різдвяні канікули, Black Friday). У цей період навіть хотфікси блокуються, якщо вони не пов'язані з security. Deployment freeze зазвичай триває 1-2 тижні та узгоджується на рівні компанії.

Коли вводити фриз і скільки він триває

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

Тривалість фризу має бути мінімально достатньою для стабілізації коду. Занадто довгий фриз (більше 2 тижнів) демотивує команду та створює накопичення незамержених фіч, кожна з яких після зняття фризу збільшує ризик конфліктів. Занадто короткий фриз (менше 24 годин для feature freeze) не дає часу на повноцінне тестування та фікси.

Рекомендована практика — встановлювати фриз не за календарною датою, а за станом кодової бази. Feature freeze вводиться, коли кількість open bugs на реліз перевищує threshold (наприклад, 10 критичних багів). Code freeze — коли білд успішно проходить smoke tests та regression suite. Time-based freeze (фіксована дата) залишається стандартом для регульованих індустрій (фінтех, медтех), де дата релізу затверджена регулятором.

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

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

CI/CD пайплайн перевіряє статус фризу перед збіркою білда. У Jenkins, GitLab CI або GitHub Actions додається step, який читає конфігураційний файл з розкладом фризів та відхиляє білди, якщо поточна дата потрапляє в період фризу. Альтернатива — 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 is active. PR blocked." && exit 1

Приклад скрипта freeze-check.js читає JSON з розкладом фризів з кореня репозиторію. Якщо поточна дата потрапляє в інтервал між start_date та end_date для вказаної гілки — пайплайн фейлиться з повідомленням про статус фризу. Git branch protection додає другий бар'єр: навіть якщо пайплайн не спрацював, правило не дозволить злити PR без approval.

Типові помилки при впровадженні фризів

Перша помилка — фриз без чіткого критерію зняття. Команда заморожує код, але не визначає, які умови мають виконатися для розморожування: zero critical bugs, пройдений regression suite, approved від продакт-менеджера. Без критеріїв фриз може затягнутися на тижні. Definition of done для фризу має бути задокументований та відомий кожному розробнику.

Друга помилка — занадто багато винятків із фризу. Кожен exception («цей PR — не фіча, а технічний борг») розмиває межу фризу. Якщо exceptions перевищують 20% від звичайного потоку PR — фриз не працює. Команда просто перейменовує фічі в багфікси, щоб обійти блокування.

Третя помилка — ігнорування release candidates. Якщо команда не збирає release candidate білди та одразу деплоїть на продакшен після code freeze, сенс фризу втрачається: баги виявляються вже у користувачів. Release candidate має збиратися до code freeze, тестуватися QA та на стейджингу, і тільки після підтвердження якості вводиться code freeze.

Четверта помилка — людський фактор при ручному контролі. Розробник може забути перевірити статус фризу перед мержем, реліз-менеджер — пропустити сповіщення. Єдине надійне рішення — автоматичне блокування на рівні Git provider або CI/CD, що виключає людську помилку.