Фича-фриз и код-фриз в разработке приложений: суть, отличия и работа

Что такое фича-фриз?

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

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

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

Что такое код-фриз и чем отличается от фича-фриза

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

Разница между фича-фризом и код-фризом — в уровне контроля. Фича-фриз управляет scope: что именно войдёт в релиз. Код-фриз управляет quality: исключается риск внесения новой ошибки за день до релиза. На практике многие команды используют двухэтапную модель: за 1-2 недели до релиза — feature freeze, за 24-48 часов — code freeze. Code freeze особенно актуален для мобильных приложений, где билд нужно загружать в стор за несколько дней до planned release date.

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

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

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

Типы фризов: полный, частичный и BAU-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 недели и согласуется на уровне компании.

Когда вводить фриз и сколько он длится

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

Длительность фриза должна быть минимально достаточной для стабилизации кода. Слишком длинный фриз (более 2 недель) демотивирует команду и создаёт накопление незамерженных фич, каждая из которых после снятия фриза увеличивает риск конфликтов. Слишком короткий фриз (менее 24 часов для фича-фриза) не даёт времени на полноценное тестирование и фиксы.

Рекомендуемая практика — устанавливать фриз не по календарной дате, а по состоянию кодовой базы. Фича-фриз вводится, когда количество 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 добавляет второй барьер: даже если пайплайн не сработал, rule не позволит слить 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, исключающая человеческую ошибку.