Feature flags: как включать новую функцию не для всех сразу

Ты только что сделал новую фичу в своём приложении: пусть это будет умная подсказка от ИИ, новый экран статистики или изменённая логика начисления очков в «Змейке». Код написан, протестирован у тебя на компьютере, и руки чешутся выложить всё на продакшен. Но в голове звучит знакомый страх: «А вдруг что-то сломается у реальных пользователей? А вдруг ИИ начнёт выдавать чушь? А вдруг интерфейс запутает людей?» Обычный деплой по кнопке в GitHub Actions выкатывает код сразу для всех, и откат требует нового деплоя. Feature flags решают эту проблему: ты публикуешь код, но включаешь новую функцию только тогда и только для тех, кому хочешь. Ниже — как это работает, почему это полезно новичку, который делает приложение с ИИ, и какие ошибки чаще всего встречаются на старте.

Что такое feature flag простыми словами

Feature flag — это обычный переключатель внутри кода. Если по-русски, то «фича-флаг» или «функциональный флаг». Представь его как выключатель света: сама лампочка уже висит в люстре и подключена к проводке, но горит только тогда, когда ты щёлкаешь выключатель. В программировании это выглядит примерно так:

if (featureFlags.showNewProfile) {
  showNewProfileScreen();
} else {
  showOldProfileScreen();
}

Сама новая функция уже лежит в коде приложения. Она прошла через GitHub Actions, попала на сервер, попала в браузер пользователя. Но пока флаг showNewProfile выключен, пользователь видит старую версию. Как только флаг включается — с того же кода, без нового деплоя — у нужных людей появляется новая функция.

Главное отличие от обычного релиза: деплой отвечает за то, чтобы код оказался в продакшене, а флаг отвечает за то, кому этот код показывать. Код и видимость развязываются друг от друга. Это даёт огромную гибкость: можно выпускать код часто и спокойно, а активацию новых возможностей контролировать отдельно.

Feature flags бывают разных видов. Самый простой — булевый флаг: включено или выключено. Более продвинутые — процентные: флаг включён, например, только для 10 % пользователей. Есть пользовательские флаги: включён для конкретного email, группы тестировщиков или подписки. Есть временные флаги: автоматически выключить через неделю после старта. Но для первого знакомства важно понять одно: флаг — это не магия, а всего лишь условие в коде, которым можно управлять извне.

flowchart TB
    A["Пользователь открывает приложение"] --> B["Код проверяет feature flag"]
    B -->|"флаг включён"| C["Показывает новую функцию"]
    B -->|"флаг выключен"| D["Показывает старую версию"]

Зачем нужны feature flags новичку, который делает приложение с ИИ

Когда ты создаёшь приложение с помощью ИИ-ассистента, темпы разработки очень высокие. За один вечер можно собрать новый экран, за ночь — прикрутить генерацию текста, за выходные — добавить голосовое управление. Но вместе со скоростью растёт и риск: ИИ может написать код, который работает в 90 % случаев, а в оставшихся 10 % ведёт себя непредсказуемо. Или новая функция выглядит красиво, но путает пользователей. Или сервис ИИ временно лагает, и твоя фича отваливается.

Feature flags позволяют выкатывать такие рискованные обновления без страха. Алгоритм простой:

1. Деплоишь код с новой функцией, но флаг выключен.
2. Включаешь флаг только для себя или для небольшой группы тестировщиков.
3. Проверяешь, что всё работает в реальном продакшене.
4. Постепенно увеличиваешь аудиторию: 5 %, 25 %, 50 %, все пользователи.
5. Если что-то пошло не так — выключаешь флаг одной кнопкой, не делая новый деплой.

Этот подход особенно важен для ИИ-функций. Например, ты добавил в «Змейку» подсказку, которая предлагает лучший следующий ход на основе нейросети. Ты не можешь заранее проверить все возможные состояния игрового поля. Зато можешь включить подсказку сначала только себе, потом десяти друзьям, потом сотне случайных игроков и посмотреть: не падает ли игра, не тормозит ли браузер, не жалуются ли люди.

Ещё один плюс — возможность спокойно деплоить в пятницу вечером. Без флагов выпускать код перед выходными пугает: если сломается, придётся разбираться в субботу. С флагом ты выкладываешь код, но оставляешь функцию выключенной до понедельника. В понедельник включаешь — и сразу рядом с компьютером.

Наконец, флаги помогают учиться. Новичок часто боится продакшена, потому что кажется, что одна ошибка сломает всё приложение. Feature flags снижают ставки: ты можешь экспериментировать, видеть реакцию реальных пользователей и быстро откатывать, если эксперимент не удался.

Чем feature flags отличаются от обычного деплоя через GitHub Actions

Чтобы не путать понятия, важно разграничить два процесса: деплой и активацию.

Деплой через GitHub Actions — это процесс публикации кода. Когда ты делаешь git push и срабатывает CI/CD-пайплайн, собирается новая версия приложения и заменяет старую на сервере. С этого момента код доступен всем пользователям. Если в коде есть ошибка, она сразу видна всем. Чтобы откатиться, нужно сделать новый коммит или отменить старый и прогнать деплой заново. Подробнее про автотесты и CI/CD мы разбирали в статье «npm test и CI/CD для новичка».

Feature flag не заменяет деплой, а живёт поверх него. После деплоя код уже на сервере, но функция скрыта. Включение флага — это не новый деплой, а изменение настройки. Отключается так же быстро.

Новая функция — как новая сцена в пьесе. Обычный деплой заменяет весь спектакль: зрители сегодня увидят новую версию, нравится им или нет. Feature flag — это занавес, который можно приподнять для одного зала и оставить опущенным для другого. Если сцена не зайдёт, опускаешь занавес, не переписывая пьесу.

Флаг не отменяет необходимость тестов и код-ревью, он лишь добавляет ещё один уровень безопасности между «код опубликован» и «код видят все».

Feature flags и A/B-тестирование

A/B-тест — это когда одной группе пользователей показываешь вариант A, другой — вариант B, и сравниваешь метрики. Feature flag — самый простой способ организовать такой тест без отдельных инструментов.

Нужно узнать, увеличит ли новый экран «Итоги игры» количество повторных заходов в «Змейку». Без A/B-теста ты просто поменяешь экран для всех и будешь гадать по общей статистике, повлияло ли это на удержание. С флагом можно поступить иначе:

• 50 % игроков видят старый экран (флаг выключен).
• 50 % игроков видят новый экран (флаг включен).
• Сравниваешь, какая группа чаще возвращается в игру.

Это не полноценная A/B-платформа с математической значимостью, но это первый и очень важный шаг. Он помогает перестать действовать наугад и начать принимать решения на основе данных.

Если метрики нового варианта лучше, ты раскатываешь флаг на 100 % пользователей. Если хуже — оставляешь старый вариант и идёшь думать дальше. При этом тебе не нужно срочно деплоить откат: достаточно выключить флаг.

Конечно, для серьёзных экспериментов нужна аналитика. Нужно понимать, какие события фиксировать, как разбивать аудиторию случайно и как считать результат. Но даже простое включение флага для половины пользователей уже даёт больше информации, чем интуиция.

Готовые сервисы: зачем изобретать велосипед, если есть PostHog

Для маленького проекта можно сделать флаг самому. Но когда приложение растёт, удобнее использовать готовый сервис. Многие системы аналитики имеют встроенные feature flags: ты создаёшь флаг в веб-панели, подключаешь небольшую библиотеку в код и управляешь видимостью функций без правки кода.

PostHog — один из таких сервисов. Мы уже разбирали его в статье «PostHog для новичка». Помимо аналитики событий, он обычно предлагает механизм feature flags. Смысл простой: вместо того чтобы писать свою таблицу флагов и админку, ты используешь готовую панель. Заходишь, создаёшь флаг с именем new-ai-hint, выбираешь аудиторию — себя, 10 % пользователей, всех — и сохраняешь. Клиентская библиотека PostHog в твоём приложении узнаёт о новом значении и передаёт его в код.

Преимущества такого подхода очевидны:

• не нужно писать админку для управления флагами;
• не нужно делать отдельный бэкенд, который отдаёт значения флагов;
• можно на лету менять процент включения и целевые аудитории;
• история изменений и логи обычно доступны в панели сервиса.

Недостатки тоже есть: ты зависишь от внешнего сервиса, его доступности и условий использования. Если сервис недоступен из твоего региона или лимитирует количество флагов, придётся искать альтернативу. Для старта и обучения такие сервисы обычно предоставляют бесплатный тариф с достаточным запасом, но актуальные лимиты стоит смотреть на сайте провайдера.

Кроме PostHog, существуют и другие платформы: LaunchDarkly, Unleash, Flagsmith, GrowthBook и встроенные решения в облачных хостингах. Принцип везде похожий. Для новичка важно не запоминать названия, а понимать: если приложение выходит за рамки одного-двух самодельных флагов, имеет смысл рассмотреть готовый инструмент.

Самый простой самодельный вариант для маленького проекта

Не всем проектам нужен отдельный сервис. Если у тебя небольшое приложение на JavaScript или PWA-игра с подключённой базой Supabase, можно обойтись обычной переменной или одной таблицей.

Самый примитивный вариант — булевое значение в базе данных. Представь таблицу feature_flags в Supabase:

Код приложения при старте или перед рендером запрашивает эту таблицу и проверяет нужное значение:

async function isEnabled(flagName) {
  const { data } = await supabase
    .from('feature_flags')
    .select('enabled')
    .eq('name', flagName)
    .single();
  return data?.enabled ?? false;
}

if (await isEnabled('new_ai_hint')) {
  showAiHint();
}

Чтобы флаг работал не просто как вкл/выкл, а для конкретных людей или долей аудитории, добавь логику по полю audience. Например, можно хранить список тестировщиков, разбивать пользователей на «корзины» по хешу их идентификатора или отдавать флаг только при определённой подписке:

function isInBucket(userId, percent) {
  // простейший пример: берём остаток от деления хеша на 100
  const hash = userId.split('').reduce((a, b) => a + b.charCodeAt(0), 0);
  return (hash % 100) < percent;
}

async function isEnabled(flagName, userId) {
  const { data } = await supabase
    .from('feature_flags')
    .select('enabled, audience, allowed_users')
    .eq('name', flagName)
    .single();
  if (!data?.enabled) return false;
  if (data.audience === 'everyone') return true;
  if (data.audience === 'only_me' && userId === MY_USER_ID) return true;
  if (data.audience === '10_percent') return isInBucket(userId, 10);
  if (Array.isArray(data.allowed_users)) return data.allowed_users.includes(userId);
  return false;
}

Для статичного сайта без бэкенда можно хранить флаг в localStorage во время разработки, но для продакшена это плохая идея: пользователь легко подменит значение. Для реального приложения лучше хранить флаг на сервере или в защищённой базе.

Если приложение деплоится через Amvera для новичка, можно завести переменную окружения или конфигурационный файл на сервере. В простейшем случае это текстовый JSON, который читает приложение при старте:

{
  "featureFlags": {
    "new_ai_hint": false,
    "redesigned_menu": true
  }
}

Но у переменных окружения и JSON-конфигов есть важный минус: чтобы изменить флаг, обычно нужно перезапустить приложение или сделать redeploy. Поэтому для продакшена удобнее именно база данных или внешний сервис флагов, где значение меняется мгновенно.

Главное правило самодельного решения: не усложняй раньше времени. Если у тебя один-два флага, таблица с двумя колонками — нормальный выбор. Когда флагов становится много, переходи на специализированный сервис.

Как не наступить на типичную ошибку: убирай старые флаги

Самая распространённая болезнь новичков — забывать удалять флаги после того, как функция либо полностью выкатена, либо отменена. Со временем код превращается в лабиринт:

if (flagA && !flagB && (flagC || user.isBeta)) {
  // что-то
} else if (flagB && !flagD) {
  // что-то другое
} else {
  // старая версия
}

Такие флаги называют «зомби-флагами». Они мертвы, но продолжают ползти по кодовой базе. Каждый новый if усложняет тестирование, отладку и чтение кода. Через полгода ты сам не помнишь, за что отвечает experimental_bonus, и боишься его трогать.

Чтобы этого избежать, заведи простое правило: у каждого флага должна быть дата смерти. Когда создаёшь флаг, сразу решаешь, когда он будет удалён. Например:

• флаг для своих тестов — удалить через 3 дня после успешного деплоя;
• флаг для постепенного rollout — удалить через 2 недели после включения на 100 %;
• флаг для эксперимента — удалить после принятия решения по A/B-тесту.

После полного включения функции нужно убрать проверку флага и оставить только новый код. Если функцию решили не запускать, удали и код, и флаг. Не храни «на всякий случай» — Git помнит всё, что было.

Ещё один полезный приём — реестр флагов. Это простой документ или таблица, где написано: название флага, зачем нужен, кто ответственный, дата создания, дата удаления. Даже в маленьком проекте такая табличка спасает от хаоса.

Какие бывают типы feature flags

Не все флаги решают одну и ту же задачу. В больших продуктах их обычно делят на несколько типов, и новичку полезно хотя бы примерно понимать разницу, чтобы не путать временный rollout с постоянной настройкой.

Release flags

Это самый частый случай. Флаг создан для того, чтобы выпустить код, но пока не показывать его пользователям. Как только функция стабильно работает у 100 % аудитории, флаг удаляется. Пример: новый экран профиля, который ты хочешь сначала проверить сам.

Experiment flags

Флаги для A/B-тестов и проверки гипотез. В документации часто встречается пометка feature flags experimental — это просто флаги, которые управляют экспериментальными функциями. Они существуют ровно столько, сколько длится эксперимент. После получения ответа флаг убирается, а победивший вариант становится основным.

Operational flags

Это переключатели, которые помогают справляться с нагрузкой или авариями. Например, ты можешь отключить тяжёлую ИИ-генерацию картинок, если сервер начинает тормозить, или временно выключить чат-бота, если внешний API лежит. Такой флаг может жить долго, потому что он не связан с новой функцией, а защищает стабильность.

Permission flags

Это флаги, которые зависят от прав пользователя. Например, доступ к бета-версии только у подписчиков Pro, или новая фича показывается только администраторам. Они похожи на обычные проверки прав, но отличаются тем, что правила можно менять без деплоя.

Kill switches

Kill switch — это экстренный выключатель. Если новая функция начинает ломать приложение, kill switch мгновенно отключает её для всех. Хороший kill switch должен быть простым и хорошо заметным в коде, чтобы в стрессовой ситуации не пришлось долго искать, что отключать.

Понимание типов помогает не превращать release flag в вечный костыль и не путать эксперимент с постоянной защитой от сбоев.

Мониторинг и отладка: что смотреть после включения флага

Включить флаг — это только полдела: дальше нужно следить, что происходит после. Иначе ты узнаёшь о проблеме из негативных отзывов, а это не самый приятный способ.

После включения флага для первой группы пользователей смотри на три вещи:

• Ошибки. Если в консоли браузера или в логах сервера появились новые ошибки, флаг нужно срочно выключить. Даже одна ошибка у 5 % пользователей при масштабировании до 100 % превратится в много ошибок.
• Производительность. Новая функция может замедлять загрузку страницы или увеличивать нагрузку на сервер. Сравни время отклика у группы с включённым флагом и у группы без него.
• Метрики продукта. Если ты включил новый экран или новый поток, смотри, не упала ли конверсия, не снизилось ли удержание, не увеличился ли отток. Иногда технически всё работает, но пользователям не нравится.

Кроме цифр, полезно собирать качественную обратную связь. Для небольшой группы тестировщиков достаточно личных сообщений. Для широкой аудитории можно добавить небольшую форму обратной связи или чат-бота. Главное — не игнорировать сигналы.

Если метрики после включения на 10 % пользователей стабильны, переходи к 25 % и снова смотри на показатели. Такой поэтапный рост даёт время заметить проблему до того, как она коснётся всех.

Если у тебя пока нет инструментов аналитики, начни с простого: заведи табличку, в которой будешь записывать дату включения флага, долю аудитории и заметные наблюдения. Даже такой ручной журнал лучше, чем действовать вслепую.

Когда feature flag не нужен

Флаги — хороший инструмент, но не универсальный. Бывают ситуации, когда они только усложняют жизнь.

Не нужен флаг, если:

• изменение безопасно и должны увидеть все пользователи, например, исправление опечатки или обновление логотипа;
• новая функция блокирует старую, и без неё приложение не имеет смысла;
• проект ещё не в продакшене, и нет реальных пользователей;
• добавление флага требует больше работы, чем сама функция.

Не превращай флаги в повод не думать о качестве. Они защищают от неожиданностей, но не заменяют тесты, ревью и здравый смысл. Если ты уверен, что изменение нужно всем и оно безопасно — просто включи его для всех и не усложняй код лишними условиями.

Как применить feature flags на практике: пошаговый план

Чтобы не утонуть в теории, вот простой план для первого feature flag в твоём приложении.

Шаг 1. Выбери функцию, которую страшно включать сразу для всех

Это может быть новая кнопка, новый экран, новый способ авторизации, новая интеграция с ИИ или изменение игровой механики. Хороший кандидат — то, что работает у тебя локально, но ты не уверен в продакшене.

Шаг 2. Оберни новую функцию в условие

В самом простом виде это выглядит так:

if (await isEnabled('new_ai_hint')) {
  renderNewAiHint();
} else {
  renderOldHint();
}

Старайся, чтобы старая и новая ветки были максимально изолированы. Чем меньше разбросанных проверок по коду, тем проще будет удалить флаг позже.

Шаг 3. Реши, где хранить флаг

Для старта подойдёт таблица в Supabase, конфиг на сервере или внешний сервис вроде PostHog. Главное — чтобы ты мог изменить значение без нового деплоя.

Шаг 4. Задеплой код с выключенным флагом

Сделай обычный деплой через GitHub Actions. Новая функция уже на сервере, но никто её не видит. Это безопасная точка: код проверен, приложение работает, пользователи не замечают изменений.

Шаг 5. Включи флаг для себя

Проверь, что функция действительно появляется у тебя в браузере, на телефоне, в приватном окне. Посмотри на ошибки в консоли, на скорость работы, на поведение ИИ.

Шаг 6. Собери первые метрики

Даже на себе можно заметить многое: сколько времени загружается новый экран, не падает ли игра при особых действиях, корректно ли работает откат. Зафиксируй наблюдения — они пригодятся, когда будешь раскатывать флаг на других.

Шаг 7. Дай доступ небольшой группе

Включи флаг для 5–10 % пользователей или для пары друзей. Собери обратную связь и посмотри метрики: не упала ли конверсия, не выросло ли количество ошибок.

Шаг 8. Увеличивай аудиторию постепенно

Если всё хорошо, увеличивай долю: 25 %, 50 %, 100 %. Делай паузы между шагами, чтобы успеть заметить проблемы.

Шаг 9. После полного rollout удали флаг

Когда функция работает у всех, убери проверку из кода. Оставь только новый путь. Это самый важный шаг, который новички часто пропускают.

Шаг 10. Если что-то пошло не так — выключи флаг

Не паникуй. Просто переведи флаг в false и разбирайся спокойно. Пользователи снова увидят старую версию, а у тебя будет время на исправление.

Частые вопросы

Можно ли обойтись без feature flags в маленьком проекте?

Можно. Если приложение только у тебя на компьютере или у десяти знакомых, флаги часто избыточны. Но стоит начать использовать их, как только появляются реальные пользователи, платежи или важные ИИ-функции, которые могут работать нестабильно. Это дешёвый способ снизить риск.

Не замедляют ли флаги работу приложения?

Если реализованы разумно — практически нет. Проверка булевого значения занимает доли миллисекунды. Проблемы могут появиться, если приложение на каждый клик лезет в базу за значением флага. Решение — кешировать флаги на несколько минут или запрашивать их один раз при старте. Внешние сервисы флагов обычно сами кешируют значения на клиенте.

В чём разница между feature flag и конфигом в .env?

Переменные окружения в файле .env задаются до запуска приложения и меняются редко — для этого нужен redeploy. Feature flag можно менять на лету, без деплоя. .env хорош для секретов и долгоживущих настроек, а флаг — для временного управления видимостью функций.

Как выбрать между самодельным флагом и сервисом вроде PostHog?

Если флагов один-два и приложение уже использует Supabase, начни с таблицы в базе. Это быстро, бесплатно и не требует новых зависимостей. Если флагов много, нужны процентные rollout, A/B-тесты или разные аудитории — смотри в сторону готовых сервисов. Они экономят время на админке и логировании.

Сколько флагов можно держать одновременно?

Технически — сколько угодно. Но с точки зрения здравого смысла — как можно меньше. Каждый активный флаг увеличивает сложность кода и количество комбинаций, которые нужно проверять. Старайся одновременно не держать больше нескольких флагов, а выкатив функцию — удаляй флаг.

Что делать, если флаг включился не у тех пользователей?

Прежде всего выключи флаг, чтобы остановить распространение. Затем проверь логику аудитории: правильно ли работает разбиение по процентам, не конфликтуют ли несколько флагов, корректно ли определяется пользователь. Для процентных rollout важно, чтобы один и тот же пользователь всегда попадал в одну и ту же группу, иначе опыт будет скакать.

Заключение + чек-лист

Feature flags — это простой, но мощный способ сделать релизы менее страшными. Особенно он полезен новичку, который создаёт приложение с ИИ: позволяет быстро экспериментировать, проверять новые функции на реальных пользователях и откатывать изменения одной кнопкой, не устраивая срочный деплой в три часа ночи.

Главное — не превращать флаги в бесконечный временный костыль. Создаёшь флаг — сразу ставь дату, когда он должен исчезнуть. После полного включения функции убирай проверку из кода. Так проект останется чистым, а ты сохранишь гибкость.

Если хочешь освоить весь путь от идеи до приложения, которым пользуются люди — присоединяйся к практикуму skillmake. Там ты научишься не только писать код с ИИ, но и деплоить, тестировать и улучшать продукт по-настоящему.

Чек-лист «Первый feature flag готов»

• Выбрал функцию, которую страшно включать сразу для всех.
• Обернул новую функцию в условие с проверкой флага.
• Выбрал место хранения флага: Supabase, сервис вроде PostHog или собственная таблица.
• Задеплоил код с выключенным флагом.
• Включил флаг для себя и проверил работу в продакшене.
• Раскатил функцию на небольшую группу пользователей и собрал обратную связь.
• Постепенно увеличил аудиторию до 100 %.
• Удалил флаг из кода после полного rollout.
• Завёл реестр флагов с датами создания и удаления.
• Понял, что делать при проблеме: выключить флаг, а не деплоить откат.