Флаг функциональности

Флаг функциональности (англ. feature toggle) в разработке программного обеспечения — альтернатива поддержке нескольких веток функциональности в исходном коде. Условие в коде включает или отключает функциональность во время выполнения программы. В гибких методологиях разработки (agile) флаг используется в рабочей среде (production) для включения функциональности по требованию для некоторых или всех пользователей. Таким образом, флаги функциональности упрощают частые релизы. Это облегчает реализацию продвинутых стратегий развёртывания, таких как «канареечные релизы» и A/B-тестирование^[1][2].

Флаги функциональности поддерживают непрерывную поставку, даже если новые релизы не развёртываются в рабочую среду непрерывно. Функциональность интегрируется в основную ветку ещё до её полного завершения. Версия разворачивается в тестовой среде, где флаг позволяет включить и протестировать новую функциональность. Циклы интеграции программного обеспечения сокращаются, и можно подготовить версию, готовую к выпуску в рабочую среду^[3].

Третий способ использования этой техники — выпуск версии продукта с незавершёнными функциями. Эти незавершённые функции скрыты (отключены флагом), поэтому они не появляются в пользовательском интерфейсе. Это снижает трудозатраты на слияние функциональности с основной веткой и её удаление из неё, что позволяет создавать множество небольших инкрементальных версий программного обеспечения^[4].

Флаг функциональности также называют переключателем функциональности (feature switch), шлюзом функциональности (feature gate), флиппером функциональности (feature flipper) или условной функциональностью (conditional feature).

Реализация

Флаги функциональности, по сути, — переменные, используемые внутри условных операторов. Таким образом, блоки кода внутри этих условных операторов можно «включать» или «выключать» в зависимости от значения флага. Это позволяет разработчикам контролировать поток выполнения своей программы и обходить функции, не готовые к развёртыванию. Блок кода, находящийся под управлением переменной времени выполнения, обычно всё ещё присутствует в коде и может выполняться условно, иногда в течение одного жизненного цикла приложения; в то время как блок кода, управляемый директивой препроцессора или закомментированный, не будет исполняемым. Подход с использованием флагов функциональности может применять любой из этих методов для разделения путей выполнения кода на разных этапах разработки.

Основное применение флагов функциональности — предотвращение конфликтов, способных возникнуть при слиянии изменений в программном обеспечении в последний момент перед релизом, хотя это может привести к так называемому «долгу флагов» (технический долг). Долг флагов возникает из-за мёртвого кода, оставшегося в программе после того, как функциональность была включена на постоянной основе, что создаёт дополнительные накладные расходы. Эту часть кода необходимо аккуратно удалить, чтобы не нарушить работу других частей программы.

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

Флаги функциональности могут использоваться в следующих сценариях^[1]:

• Добавление новой функциональности в приложение.
• Улучшение существующей функциональности в приложении.
• Скрытие или отключение функциональности.
• Расширение интерфейса.

Флаги функциональности могут храниться в виде^[5]:

• Записей в базе данных.
• Свойства в конфигурационном файле.
• Записи во внешнем сервисе управления флагами.

Группы функциональности

Группы функциональности состоят из флагов, работающих вместе. Это позволяет разработчику легко управлять набором связанных флагов^[6].

Канареечный релиз

Канареечный релиз (или канареечный запуск/развёртывание) позволяет разработчикам постепенно тестировать функциональность на небольшой группе пользователей. Флаги функциональности — альтернативный способ проведения канареечных запусков^[7] и позволяют нацеливаться на пользователей по географическому положению или даже по их атрибутам^[8]. Если производительность функциональности неудовлетворительна, её можно откатить без негативных последствий^[9].

Название происходит от использования канареек для предупреждения шахтёров о ядовитых газах (Канарейка в шахте).

Применение

Мартин Фаулер утверждает, что релизный флаг, специфический тип флага функциональности, «должен быть вашим последним выбором при внедрении функциональности в рабочую среду». Вместо этого лучше разбивать функциональность на более мелкие части, каждую из которых можно реализовать и безопасно внедрить в выпущенный продукт, не вызывая других проблем^[2].

Флаги функциональности используются многими крупными веб-сайтами, включая Flickr^[10], Disqus^[11], Etsy^[12], Reddit^[13], Gmail^[14] и Netflix^[15], а также в таких программах, как Google Chrome Canary или Microsoft Office^[16].

См. также

• Управление конфигурацией программного обеспечения
• Линейка программных продуктов
• Сравнение программного обеспечения для управления конфигурацией с открытым исходным кодом