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

Флаг функциональности (англ. 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].

См. также

Примечания

  1. ↑ 1 2 ALM Rangers - Software Development with Feature Toggles. msdn.microsoft.com (июль 2015).
  2. ↑ 1 2 Martin Fowler 29 October 2010. FeatureToggle. Martinfowler.com (29 октября 2010). Дата обращения: 27 сентября 2013.
  3. ↑ How GitHub Leverages Feature Flags to Ship Quickly and Safely, infoq, 2021-05-09.
  4. ↑ Programming JavaScript Applications.
  5. ↑ Echagüe, Pato. Managing Feature Flags. — O'Reilly Media, 2014. — ISBN 9781492028598.
  6. ↑ Elliot, Eric. Programming JavaScript Applications. — O'Reilly Media, 2018.
  7. ↑ How to do Canary Release / Progressive Delivery with ConfigCat | ConfigCat Blog (англ.). configcat.com (9 февраля 2022). Дата обращения: 22 декабря 2022.
  8. ↑ Canary Testing - Using Blue-Green Deployments and Feature Flags. unlaunch.io (26 февраля 2021). Дата обращения: 14 августа 2021.
  9. ↑ Canary launches – how and why to canary release. launchdarkly.com (7 апреля 2015). Дата обращения: 9 января 2017.
  10. ↑ Harmes, Ross. Flipping Out - code.flickr.com. flickr.net. Дата обращения: 9 января 2017.
  11. ↑ dcramer. Partial Deployment with Feature Switches (9 июля 2010). Дата обращения: 10 октября 2013. Архивировано из оригинала 5 ноября 2013 года.
  12. ↑ How does Etsy manage development and operations? codeascraft.com (4 февраля 2011). Дата обращения: 9 января 2017.
  13. ↑ reddit/reddit. github.com. Дата обращения: 9 января 2017.
  14. ↑ Developing Gmail's new look. googleblog.com. Дата обращения: 9 января 2017.
  15. ↑ Preparing the Netflix API for Deployment. netflix.com. Дата обращения: 9 января 2017.
  16. ↑ Wolfe, Mike. Office FeatureGates: How Microsoft Can Break and Fix Their Applications in Under 24 Hours. nolongerset.com (30 мая 2022). Дата обращения: 27 августа 2024.
Эта статья взята у (из) Википедия. Текст лицензируется по Creative Commons Attribution-Share Alike 4.0. К медиа файлам могут применятся дополнительные условия.