Управление тогглами

Управлять доступностью функции, а не только выпуском кода

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

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

Состояние тоггла и доступность функции

Feature Toggle / Feature Flag здесь означает функциональный переключатель. Значение переключателя и доступность функции описываются раздельно.

Переключение меняет значение существующего тоггла. Удаление из кода исключает сам механизм управления функцией. Деактивация не означает, что тоггл удален.

Состояния по окружениям

Целевые состояния тогглов хранятся в управляемой конфигурации в Git. Фактическое состояние фиксируется отдельно для каждого окружения. Во время тестирования допускается переключение состояний по тестовым сценариям с последующим восстановлением целевой конфигурации.

Связь с типами задач RELHUB

User Story

Пользовательский или клиентский результат, проходящий полный производственный цикл.

Technical Task

Самостоятельный технический результат для развития системы, с разработкой и контролем качества.

Job Task

Короткая техническая или организационная работа с упрощенным маршрутом.

Подробные определения и маршруты приведены в WorkFlow для релизных проектов. Заявка на изменение состояния тоггла не подменяет задачу разработки и не становится автоматически Job Task: у нее собственный маршрут согласования.

Релизные и продуктовые тогглы

Привязка к одному или двум релизам и другие сроки на этой странице являются параметрами описываемой модели, а не общеотраслевыми нормативами.

Участники, входы и результаты

Системный аналитик

Фиксирует требования, влияние на интеграции и производительность; участвует в заполнении реестра.

Разработчик и технический лидер

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

Специалист и менеджер тестирования

Проверяют оба состояния, готовят протоколы и набор проверок после внедрения.

Релиз-менеджер и представитель бизнес-заказчика

Участвуют в подготовке внедрения и подтверждении корректности открытой или закрытой функции.

Специалист по информационной безопасности

Участвует в согласовании при необходимости, определенной в реестре, и при выявленном влиянии исключительного случая на ИБ.

Сопровождение и DevOps

Участвуют в изменении состояния на production и в аварийных работах. DevOps выполняет согласованную заявку и закрывает ее.

От скрытой функции до удаления переключателя

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

1. 01

   Принять решение о создании или удалении

   Участники: Разработчик, технический лидер, системный аналитик

   • От планирования до завершения функционального тестирования команда определяет необходимость релизного тоггла: функциональность вводится поэтапно в нескольких релизах либо изменение затрагивает одну или несколько смежных систем.
   • Отдельное решение об исключении кода и удалении тоггла принимают разработчик и технический лидер в том же интервале. Деактивация значения и удаление из кода не заменяют друг друга.
   • Если функциональность невозможно откатить или протестировать, реализация релизного тоггла рассматривается как исключительный случай. Нужна договоренность с релиз-менеджером и менеджером тестирования, а при выявленном влиянии на информационную безопасность также со специалистом по ИБ.

   Результат: Определены необходимость тоггла, применимость исключения и план его удаления.

2. 02

   Зафиксировать требования

   Участники: Системный аналитик

   • Требование о реализации или удалении тоггла обязательно фиксируется в техническом задании для User Story или Technical Task. Для Job Task оно фиксируется в описании задачи.
   • В техническом задании описывается возможное влияние активации и деактивации на интеграции.

   Результат: Решение отражено в задаче разработки и соответствующей документации.

3. 03

   Зарегистрировать реализованный тоггл

   Участники: Системный аналитик, разработчик

   • После технической реализации наименование и состояние добавляются в реестр; наименование также указывается в поле «Тоггл» связанной User Story, Technical Task или Job Task.
   • Имя не должно раскрывать детали скрываемой функции или ошибки. Каждая функциональность покрывается отдельным тогглом. При расширении существующей функциональности сведения о покрытии обновляются в реестре и родительской задаче.
   • При исключении тоггла после реализации скрывавшейся функциональности обновляется запись о реализации этой функциональности в реестре.
   • Целевые состояния тогглов хранятся в управляемой конфигурации в Git. Изменения фиксируются в релизной ветке тогглов по принципу «инфраструктура как код» и применяются к контурам через CI/CD. Фактическое состояние фиксируется отдельно для каждого окружения.

   Результат: Тоггл прослеживается от задачи и целевой конфигурации до записи реестра.

4. 04

   Проверить оба состояния на тестовых средах

   Участники: Специалист по тестированию, менеджер тестирования; разработчик для переключений

   • Функциональное и интеграционное тестирование проверяют работу требований при активации и деактивации. Протокол явно называет тоггл, фиксирует отсутствие ошибок API и консоли разработчика и проверяет доступность функции на уровне API.
   • Ссылка на протокол прикладывается к User Story или Technical Task. В реестре фиксируются фактическое состояние тестовой среды и задача на удаление, если тоггл удаляется.
   • Регрессионные и нагрузочные проверки изменения выполняются в рамках соответствующего тестирования релиза.
   • Переключения выполняются по тестовым сценариям, состояния записываются в реестр. В OpenAPI актуализируются имя тоггла и покрываемые им методы. На тестовых и командных dev-стендах тестировщик может менять состояние из административной панели с последующим восстановлением целевой конфигурации через CI/CD.

   Результат: Протоколы подтверждают поведение обоих состояний; документация и тестовое состояние актуальны.

5. 05

   Внедрить и подтвердить состояние

   Участники: Релиз-менеджер, менеджер тестирования, представитель бизнес-заказчика

   • До внедрения в план релиза включаются проверки состояния на production и необходимые операции активации, деактивации или удаления. Это касается как самого тоггла, так и скрываемой им функциональности.
   • Специалист по тестированию заранее готовит набор проверок открытой или закрытой функции для представителя бизнес-заказчика. Набор прикладывается к плану внедрения.
   • План содержит работы по возврату значения в исходное состояние при нештатной ситуации. После внедрения фактическое состояние production фиксируется в реестре.
   • Если система не предоставляет прямую проверку состояния, в плане внедрения предусматривается подходящий способ его подтверждения.

   Результат: Доступность функции подтверждена, состояние записано, порядок возврата подготовлен.

6. 06

   Зафиксировать аварийное изменение

   Участники: Сопровождение, DevOps, ответственный за фиксацию технического сбоя

   • При техническом сбое сопровождение или DevOps меняет состояние релизного тоггла по согласованию с руководством. Сопровождение организует согласование в рамках запроса на аварийный релиз.
   • После устранения сбоя ответственный за его фиксацию заносит сведения о выполненных работах в карточку технического сбоя.

   Результат: Аварийные действия согласованы и отражены в записи о техническом сбое.

Управлять условиями доступности после внедрения

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

1. 01

   Определить основание для продуктового тоггла

   Участники: Разработчик, технический лидер, системный аналитик

   • Основания: подготовка A/B-тестирования; открытие или закрытие функции для пользователей или групп; быстрое отключение проблемной функции; разграничение доступности по группам или уровням доступа.

   Результат: Определены управляемая функция и условия изменения ее доступности.

2. 02

   Описать реализацию и влияние

   Участники: Системный аналитик

   • Реализация обязательно описывается в техническом задании связанной User Story или Technical Task.
   • В ТЗ фиксируются возможное влияние переключения на интеграции и влияние функциональности под тогглом на производительность системы, если оно есть.

   Результат: Условия работы, интеграционные эффекты и влияние на производительность отражены в ТЗ.

3. 03

   Добавить тоггл в реестр и конфигурацию

   Участники: Системный аналитик, разработчик

   • После реализации наименование и состояние добавляются в реестр, а имя указывается в поле «Тоггл» связанной User Story или Technical Task.
   • Имя не раскрывает детали функции или ошибки. Для каждой функциональности используется отдельный тоггл; расширение покрытия отражается в реестре и родительской задаче.
   • Целевые состояния тогглов хранятся в управляемой конфигурации в Git. Изменения фиксируются в релизной ветке тогглов и применяются к контурам через CI/CD. Фактическое состояние фиксируется отдельно для каждого окружения.

   Результат: Задача, конфигурация и реестр связаны между собой.

4. 04

   Провести тестирование с учетом срока ожидания

   Участники: Специалист по тестированию, менеджер тестирования; разработчик для переключений

   • Функциональные и интеграционные проверки охватывают оба состояния. Протокол называет тоггл, подтверждает требования, отсутствие ошибок API и консоли и корректность доступа к функции через API. Ссылка прикладывается к User Story или Technical Task; фактическое состояние теста записывается в реестр.
   • Регрессионное тестирование проводится в релизе доработки или внедрения продуктового тоггла.
   • Если переключение ожидается через два и более плановых релиза либо прошло два и более месяца после внедрения, регрессионная модель обязательно дополняется кейсом активации и деактивации. К заявке на деактивацию на production прикладывается протокол регрессионного тестирования с проверками обоих состояний.
   • Если переключение увеличивает нагрузку, например при расширении аудитории, к заявке на активацию или деактивацию обязательно прикладывается протокол нагрузочного тестирования с проверками обоих состояний. Если влияние на производительность отмечено в ТЗ, такие проверки предусматриваются и в нагрузочном тестировании релиза доработки или внедрения.
   • На тесте переключения следуют сценариям и фиксируются в реестре; покрытие методов поддерживается в OpenAPI. На тестовых и командных dev-стендах допускается управление тестировщиком из административной панели с последующим восстановлением целевой конфигурации через CI/CD.

   Результат: Подготовлены протоколы, в том числе обязательные при длительном ожидании или росте нагрузки.

5. 05

   Подготовить внедрение и проверку на production

   Участники: Релиз-менеджер, менеджер тестирования, представитель бизнес-заказчика

   • План внедрения включает проверку корректности состояния тоггла на production и работы по возврату в исходное состояние при нештатной ситуации.
   • Специалист по тестированию готовит проверки открытой и закрытой функции для представителя бизнес-заказчика. Инициатор прикладывает набор к заявке на согласование изменения состояния.
   • Фактическое состояние production фиксируется в реестре. При отсутствии прямой верификации способ подтверждения предусматривается в плане работ или заявке.

   Результат: Есть план, подтверждающие проверки и подготовленный возврат состояния.

6. 06

   Согласовать и выполнить переключение

   Участники: Инициатор, сопровождение, согласующие участники, DevOps

   • Для активации или деактивации продуктового тоггла на production создается отдельная заявка, а изменение тоггла фиксируется коммитом в релизной ветке.
   • Работы выполняются в рамках заявки: сопровождение участвует в процессе, DevOps берет согласованную заявку в работу и закрывает ее по маршруту ниже.
   • В этой модели согласование занимает не более двух рабочих дней с момента отправки заявки на согласование.
   • Планируемые начало и окончание работ фиксируются в заявке.

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

7. 07

   Отразить действия при техническом сбое

   Участники: Сопровождение, DevOps, ответственный за фиксацию технического сбоя

   • Аварийное переключение продуктового тоггла выполняет сопровождение или DevOps по согласованию с руководством. Сопровождение организует согласование в запросе на аварийный релиз.
   • После устранения сбоя выполненные действия фиксируются в его карточке ответственным участником.

   Результат: Сохранены согласование аварийного изменения и история выполненных действий.

Согласование, выполнение и исключения

Инициатор создает заявку на изменение состояния продуктового тоггла. Описание должно позволять выполнить работы; подтверждающие артефакты прикладываются до направления на согласование.

Адаптируемая модель согласования по функциям

Продуктовая или техническая ответственность

Владелец продукта либо технический лидер.

Качество

Назначенный представитель тестирования.

Эксплуатация

Сопровождение и DevOps.

Информационная безопасность

При необходимости согласования, зафиксированной в реестре.

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

Условия переходов

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

15 полей для подготовки работ

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

01 ТемаОбязательное поле

Краткое описание заявки.

02 ОписаниеОбязательное поле

Сведения, необходимые для выполнения работ.

03 СистемаОбязательное поле

Наименование системы, в которой планируются работы с тогглом.

04 ИсполнительОбязательное поле

Исполнитель по заявке.

05 ТогглОбязательное поле

Наименование тоггла, который нужно активировать или деактивировать.

06 Реестр тоггловОбязательное поле

Ссылка на актуальный реестр.

07 Вид работыОбязательное поле

Активировать или деактивировать тоггл.

08 Планируемые дата и время начала работОбязательное поле

Начало интервала проведения работ.

09 Планируемые дата и время окончания работОбязательное поле

Конец интервала проведения работ.

10 Обоснование необходимости работОбязательное поле

Причина изменения состояния.

11 Увеличение нагрузки на системуОбязательное поле

Да или нет; сведения об увеличении нагрузки.

12 Версия релизаНеобязательное поле

Версия, в которой реализована функциональность для последующей деактивации тоггла.

13 ВложениеНеобязательное поле

Материалы для пояснения или выполнения заявки. Обязательные по условиям процесса протоколы прикладываются независимо от общей необязательности этого поля.

14 Связанные задачиНеобязательное поле

Связи заявки с другими задачами и артефактами.

15 Действия в случае нештатной ситуацииНеобязательное поле

Работы по возврату тоггла в исходное состояние. Необязательность поля не отменяет подготовку возврата в плане внедрения.

Прослеживаемость тоггла и его состояния

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

01 Связанная задача

Ссылка на User Story, Technical Task или Job Task, функциональность которой управляется тогглом.

02 Планируемая версия релиза

Версия релиза, в которой планируется внедрение.

03 Наименование функциональности

Функция, покрываемая тогглом.

04 Наименование тоггла

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

05 Интеграционный тоггл

Признак того, что тоггл связан с интеграционной доработкой.

06 Причина появления

Основание для создания тоггла.

07 Тип тоггла

Релизный или продуктовый.

08 Необходимость согласования ИБ

Нужно ли участие специалиста по информационной безопасности.

09 Платформа

Frontend, backend, iOS, Android или другая платформа.

10 Изменение состояния для групп пользователей

Сведения об изменении состояния для отдельных групп пользователей.

11 Состояние на тестовой среде

Фактическое значение true или false на тесте. Доступность функции трактуется по семантике этой методологии.

12 Задача на удаление

Связанная задача, в которой запланировано удаление тоггла.

13 Условия включения и выключения

Условия активации и деактивации переключателя с явным указанием ожидаемой доступности функции.

Ручное ведение и автоматизация

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

Что подтверждать при переключениях

Тогглы дополняют, а не заменяют управление задачами и качеством релиза. Связанные материалы: WorkFlow для релизных проектов и Quality Gates: пороги качества релиза.