Feature Toggles и их применение. История одного проекта

Каждое решение имеет последствия (с) из сети

Привет, Хабр! Представьте: вы – член большой команды среди десятка таких же команд на крупном и зрелом проекте. Казалось бы, все процессы уже выстроены, все масштабные разработки завершены и теперь остается только с наслаждением разрабатывать и дополнять проект новыми интересными фичами.

Гармония и красота.

Но откуда ни возьмись, появляется она – недоработанная масштабная функциональность, словно щупальцами оплетающая все базовые процессы сразу. Как монстр, затаившийся в пещере, она не давала покоя бизнесу вот уже 3 года, и успела  «сожрать» несколько команд разработки. И вот бизнес снова объявил охоту на монстра… а вы оказались в этом отряде самоубийц героев, призванных положить конец бесчинствам чудовища. 

Цели озвучены, задачи поставлены, команда в ужасе собрана. Но вот незадача, поле для сражений одно: либо ваша команда будет монстра рубить, либо остальные команды – семена сажать. И что же делать?

Для этого и были призваны Feature Toggle (FT). На самом деле они решают гораздо больше проблем, но и вызывают не меньше.

Меня зовут Александра, я QA-специалист в компании SimbirSoft. После того как наша команда впервые столкнулась с FT на проекте, я прочла много статей, посвященных им, и поняла – сколько проектов, столько и мнений о FT и о том, как с ними следует работать.

Я поделюсь своим опытом и наблюдениями за появлением Feature Toggles на одном из проектов, где работала с двумя моими коллегами из направления QA SimbirSoft. А также расскажу, к чему это привело.

Уверена, эта статья будет интересна для IT-специалистов у которых:

• на проекте несколько функциональных команд, но всего одна среда для разработки и тестирования;

• в процессе разработки и выпуска абсолютно новая функциональность, которая затрагивает и/или изменяет базовые функции;

• отсутствует чёткое ТЗ (техническое задание) или часто меняется;

• команда унаследовала функциональность, при этом нет связи со специалистами из предшествующих команд разработки;

• проект с «гибридным» фреймворком, то есть монолит на стадии распада в микросервисы;

• сроки максимально сжаты и вопрос об их переносе не рассматривается.

Именно в такой ситуации оказалась наша команда в самом начале пути.

Пара слов о Feature Toggle 

Feature Toggle (FT) – это инструмент, позволяющий переключаться со старой функциональности на новую, не пересобирая приложение и не выпуская его заново. Реализуется добавлением в код условного оператора (if), который дает возможность управлять поведением программы, просто меняя нужное значение в конфигурационном файле или базе данных. 

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

Жизнь на проекте до и после. Как всё начиналось и к чему пришли в итоге

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

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

Почему на проекте приняли решение прибегнуть к работе с FT:

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

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

3. Конфликты внутри команды и с представителями бизнеса. Команда работала на износ и ежедневно тратила время на решение проблем среды разработки, а сторона бизнеса не видела ощутимого прогресса и не могла оценить степень продвижения процессов, так как в релизе новая функциональность не появлялась.

Исходя из ситуации в команде, решение прибегнуть к работе с FT выглядело логичным и правильным. Но при реализации задумки возникли «нюансы».

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

Например, команде сообщили, что теперь мы работаем с FT. Их можно включать и выключать… и на этом всё.

Отсутствие регламента работы с FT, отсутствие понимания команды что с ними делать, а главное – как FT проявят себя в условиях конкретно нашего проекта привело к следующим ситуациям:

• Ошибки в обертке кода FT. Как следствие – функциональность не работает ни с включенным FT, ни с выключенным.

• В задаче с FT нет метки о состоянии FT с которым она должна быть влита в релизную ветку (или вообще нет метки):

  • процесс тестирования заторможен;

  • задача влита в релиз в не валидном состоянии;

  • риски возникновения ошибок;

• Долгая жизнь FT. Отмечено, чем дольше живет FT, тем более сильными связями он обрастает, а в конечном итоге в момент реализации возникает конфликт с параллельными задачами, следствие: трудозатраты на устранение конфликтов, увеличение времени регрессионного тестирования, возникновение сложных высокоприоритетных багов.

К проблемам выше также добавляется сложность ведения разработки функциональности под FT и ведения стандартного процесса в других командах. Например:

• Команда А занимается улучшением стандартного процесса.

• Команда Б разрабатывает функциональность под FT.

Задача команды Б блокирует работу команды А и ряда других команд, поэтому было принято решение тестировать ее в определенное время (здесь уже можно отметить сложность работы с задачей в команде Б).

Но в команде Б не один разработчик и не один специалист качества. Задача команды Б нужна для тестирования ряда других задач этой же команды. Таким образом, вся команда тормозит процесс разработки и проверки задач.

Возникает важный вопрос: почему приоритет отдан стандартному процессу, а не разработке нового?

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

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

История с «хэппи-эндом» или с продолжением?

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

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

В итоге были определены следующие пункты для устранения и нивелирования проблем, возникших после внедрения FT:

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

2. Создание регламента для заполнения отчета о тестировании и тестовой документации для задач под FT:
   — в отчете о тестировании указывается, в каком состоянии FT производилась проверка;
   — там же указываются другие задачи под FT (и их положение), которые влияют на проверяемую задачу;
   — в названии тестовой документации (например, тест-кейсов) указывается состояние и номер задачи под FT, для которой делаются проверки;
   — в предусловии тест-кейсов указывается пункт для регрессионного тестирования о том, какой ожидаемый результат должен быть получен (если он отличается от стандартного).

3. Определяются ответственные сотрудники, которые отслеживают жизненный отрезок FT, а также наличие зависимостей у задачи под FT:
   — если срок жизни FT превышает 2 месяца или задача под FT имеет зависимые задачи, приоритет выпуска таких задач поднимается, также озвучиваются риски и последствия не выпуска задачи;
   — составляют и ведут списки задач под FT, предоставляют их коллегам для сборки веток.

4. Определяются ответственные сотрудники по сбору и выкатке релизной ветки и ветки разработки, которые:
   — проверяют задачи под FT и их положение по списку;
   — вливают задачи под FT в релизную ветку в соответствующем состоянии;
   — вливают задачи в среду разработки во включенном состоянии.

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

Как обстоят дела сейчас

После ввода новых правил жизнь на проекте с FT стала намного легче. Был решен целый ряд проблем, как основных, так и возникших после его внедрения:

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

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

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

4. Процесс работы с задачами под FT значительно ускорился за счет устранения неразберихи в ведении документации, связанной с задачами под FT, в том числе и с самими тикетами/задачами.

Однако некоторые проблемы все еще остались:

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

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

3. Зависимости в задачах с FT. Выход из таких ситуаций уже найден, однако время от времени они могут возникать. Плюс в том, что теперь команда об этом знает и может сконцентрироваться на их решении в первую очередь.

Вывод

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

С помощью такого инструмента как FT команда сумела раздробить новую большую разработку и предоставила бизнесу и пользователям пилотную версию продукта. А дальше процесс разработки пошел куда быстрее. Сроки перестали гореть, команда вздохнула с облегчением и наступил мир…

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

Спасибо за внимание!

Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.