Каждое решение имеет последствия (с) из сети
Привет, Хабр! Представьте: вы – член большой команды среди десятка таких же команд на крупном и зрелом проекте. Казалось бы, все процессы уже выстроены, все масштабные разработки завершены и теперь остается только с наслаждением разрабатывать и дополнять проект новыми интересными фичами.
Гармония и красота.
Но откуда ни возьмись, появляется она – недоработанная масштабная функциональность, словно щупальцами оплетающая все базовые процессы сразу. Как монстр, затаившийся в пещере, она не давала покоя бизнесу вот уже 3 года, и успела «сожрать» несколько команд разработки. И вот бизнес снова объявил охоту на монстра… а вы оказались в этом отряде самоубийц героев, призванных положить конец бесчинствам чудовища.
Цели озвучены, задачи поставлены, команда в ужасе собрана. Но вот незадача, поле для сражений одно: либо ваша команда будет монстра рубить, либо остальные команды – семена сажать. И что же делать?
Для этого и были призваны Feature Toggle (FT). На самом деле они решают гораздо больше проблем, но и вызывают не меньше.
Меня зовут Александра, я QA-специалист в компании SimbirSoft. После того как наша команда впервые столкнулась с FT на проекте, я прочла много статей, посвященных им, и поняла – сколько проектов, столько и мнений о FT и о том, как с ними следует работать.
Я поделюсь своим опытом и наблюдениями за появлением Feature Toggles на одном из проектов, где работала с двумя моими коллегами из направления QA SimbirSoft. А также расскажу, к чему это привело.
Уверена, эта статья будет интересна для IT-специалистов у которых:
на проекте несколько функциональных команд, но всего одна среда для разработки и тестирования;
в процессе разработки и выпуска абсолютно новая функциональность, которая затрагивает и/или изменяет базовые функции;
отсутствует чёткое ТЗ (техническое задание) или часто меняется;
команда унаследовала функциональность, при этом нет связи со специалистами из предшествующих команд разработки;
проект с «гибридным» фреймворком, то есть монолит на стадии распада в микросервисы;
сроки максимально сжаты и вопрос об их переносе не рассматривается.
Именно в такой ситуации оказалась наша команда в самом начале пути.
Пара слов о Feature Toggle
Feature Toggle (FT) – это инструмент, позволяющий переключаться со старой функциональности на новую, не пересобирая приложение и не выпуская его заново. Реализуется добавлением в код условного оператора (if), который дает возможность управлять поведением программы, просто меняя нужное значение в конфигурационном файле или базе данных.
Основные преимущества FT | Распространённые недостатки FT |
1. Возможность включать и отключать функциональность, описанную FT в любое время. | 1. Необходимость в пересмотре/изменении процессов разработки и публикаций. Особенно для проектов с множеством команд и нехваткой сред для разработки и тестирования. |
2. Возможность не пересобирать приложение заново, если новая функциональность не работает или работает не так, как ожидалось. | 2. Сложность обработки ошибок. Здесь необходимо понимание, по какому пути управления пошёл процесс и правильно ли код обернут в FT. |
3. Уменьшение количества веток, их времени жизни, а также сложность их слияния. | 3. Переобучение команды и новые требования: правила включения/отключения FT, обновление или очищение кода от неактуальных FT. При невыполнении этого пункта в команде и в коде может воцариться хаос (об этом расскажу далее). |
4. Ускорение процесса разработки и тестирования за счет доступности нового кода на тестовой среде и его влияния на смежные системы. |
Таким образом, FT могут пригодиться для множества проектов, и везде их реализация и использование будут отличаться.
Жизнь на проекте до и после. Как всё начиналось и к чему пришли в итоге
Итак, как было ранее сказано, на проекте имелась древняя нереализованная функциональность, над которой трудилась не одна команда в течение долгих трёх лет. Обозначена цель и сроки по выпуску релиза – ровно 6 месяцев отведено на всю работу. Но вот незадача, есть всего одна среда для разработки и тестирования, где работают множество специалистов.
Временны́е затраты на разработку были больным местом как для бизнеса, так и для команды разработки. При грамотном введении в процесс FT появляется возможность дробить большие задачи и выпускать их в прод частями в выключенном состоянии. Таким образом, они не могут повлиять на стандартную, не адаптированную под изменения функциональность, при этом СКВ не будет перегружена множеством веток, а значит, процесс слияния и выпуска займет меньше времени.
Почему на проекте приняли решение прибегнуть к работе с FT:
Разрабатываемая фича затрагивала базовые процессы, изменения в которых влияли на работу других команд (часто ее блокировали). Это приводило к сбою в работе тестирования сразу нескольких команд, грозило срывами сроков, возникновению большого количество багов, а также провоцировало конфликты между сотрудниками.
Каждый релиз необходимо было исключать новые растущие куски кода из реализации, а затем снова добавлять их в среду разработки. Последствиями этого стали конфликты при сборке ветки релиза и ветки разработки. Повышался риск того, что в релизной ветке окажется кусок кода новой функциональности или, наоборот, в ветке разработки могло не оказаться нужной задачи. Это сильно тормозило работу команды и, как следствие, приводило к срывам сроков.
Конфликты внутри команды и с представителями бизнеса. Команда работала на износ и ежедневно тратила время на решение проблем среды разработки, а сторона бизнеса не видела ощутимого прогресса и не могла оценить степень продвижения процессов, так как в релизе новая функциональность не появлялась.
Исходя из ситуации в команде, решение прибегнуть к работе с FT выглядело логичным и правильным. Но при реализации задумки возникли «нюансы».
Внедрение FT в работу произошло слишком быстро. В итоге к старым проблемам добавился целый скоп новых.
Например, команде сообщили, что теперь мы работаем с FT. Их можно включать и выключать… и на этом всё.
Отсутствие регламента работы с FT, отсутствие понимания команды что с ними делать, а главное – как FT проявят себя в условиях конкретно нашего проекта привело к следующим ситуациям:
Ошибки в обертке кода FT. Как следствие – функциональность не работает ни с включенным FT, ни с выключенным.
В задаче с FT нет метки о состоянии FT с которым она должна быть влита в релизную ветку (или вообще нет метки):
процесс тестирования заторможен;
задача влита в релиз в не валидном состоянии;
риски возникновения ошибок;
Долгая жизнь FT. Отмечено, чем дольше живет FT, тем более сильными связями он обрастает, а в конечном итоге в момент реализации возникает конфликт с параллельными задачами, следствие: трудозатраты на устранение конфликтов, увеличение времени регрессионного тестирования, возникновение сложных высокоприоритетных багов.
К проблемам выше также добавляется сложность ведения разработки функциональности под FT и ведения стандартного процесса в других командах. Например:
Команда А занимается улучшением стандартного процесса.
Команда Б разрабатывает функциональность под FT.
Задача команды Б блокирует работу команды А и ряда других команд, поэтому было принято решение тестировать ее в определенное время (здесь уже можно отметить сложность работы с задачей в команде Б).
Но в команде Б не один разработчик и не один специалист качества. Задача команды Б нужна для тестирования ряда других задач этой же команды. Таким образом, вся команда тормозит процесс разработки и проверки задач.
Возникает важный вопрос: почему приоритет отдан стандартному процессу, а не разработке нового?
Потому что улучшения стандартного процесса выйдут в релиз уже сейчас, принося пользу пользователям и бизнесу. Новый процесс еще не готов и не несет никакой фактической пользы в настоящий момент.
На самом деле выше описана серьезная ситуация, которая достойна отдельной дискуссии. Однако, мы вернемся к тому, как же мы боролись с FT и что для этого делали.
История с «хэппи-эндом» или с продолжением?
На мой взгляд, качественная коммуникация – залог успеха в любом командном проекте, и этому есть подтверждение.
После того как команда начала использовать FT, обрастая кучей новых проблем и вопросов, руководители проекта назначили собрание. На нём коллеги поделилась своими «болями» и предложениями.
В итоге были определены следующие пункты для устранения и нивелирования проблем, возникших после внедрения FT:
Подготовка регламента для создания и ведения тикета/задачи под FT:
- в теле задачи с FT устанавливается маркер, в каком состоянии она должна быть залита в релиз;
- в описании задачи прописывается, в каком состоянии FT задача должна быть протестирована.Создание регламента для заполнения отчета о тестировании и тестовой документации для задач под FT:
- в отчете о тестировании указывается, в каком состоянии FT производилась проверка;
- там же указываются другие задачи под FT (и их положение), которые влияют на проверяемую задачу;
- в названии тестовой документации (например, тест-кейсов) указывается состояние и номер задачи под FT, для которой делаются проверки;
- в предусловии тест-кейсов указывается пункт для регрессионного тестирования о том, какой ожидаемый результат должен быть получен (если он отличается от стандартного).Определяются ответственные сотрудники, которые отслеживают жизненный отрезок FT, а также наличие зависимостей у задачи под FT:
- если срок жизни FT превышает 2 месяца или задача под FT имеет зависимые задачи, приоритет выпуска таких задач поднимается, также озвучиваются риски и последствия не выпуска задачи;
- составляют и ведут списки задач под FT, предоставляют их коллегам для сборки веток.Определяются ответственные сотрудники по сбору и выкатке релизной ветки и ветки разработки, которые:
- проверяют задачи под FT и их положение по списку;
- вливают задачи под FT в релизную ветку в соответствующем состоянии;
- вливают задачи в среду разработки во включенном состоянии.При проверке задачи под FT специалист по качеству сообщает командам в чате, что собирается включить/отключить FT, так при внезапном возникновении проблемы, члены команды не будут тратить время на выяснение ее происхождения. Скорее всего причина – в задаче под FT.
Как обстоят дела сейчас
После ввода новых правил жизнь на проекте с FT стала намного легче. Был решен целый ряд проблем, как основных, так и возникших после его внедрения:
После подготовки большого блока кода с новой разрабатываемой функциональностью (в отключенном состоянии) значительно упростился мердж, исчезли трудности со сборкой и выпуском веток, а также ускорился процесс разработки и тестирования за счет устранения проблем на стендах.
Новую пилотную версию фичи смогли использовать представители бизнеса и фокус-группа. Таким образом, конфликты между командой разработки и бизнесом были решены, так как заказчики наглядно видели прогресс выпуска продукта.
На основании работы пилотного проекта были выявлены нуждающиеся в изменении моменты, находящиеся на ранней стадии разработки. Их своевременная корректировка выходит значительно дешевле для бизнеса.
Процесс работы с задачами под FT значительно ускорился за счет устранения неразберихи в ведении документации, связанной с задачами под FT, в том числе и с самими тикетами/задачами.
Однако некоторые проблемы все еще остались:
Проблема с нехваткой стендов и конфликты между разработкой задач в разных командах. Здесь стоит отметить, что данная проблема исчезнет самостоятельно после того, как проект будет выпущен в полном объеме. С момента выпуска пилота количество конфликтов заметно сократилась. В дальнейшем такая тенденция будет только расти.
Новые сотрудники или специалисты из других команд, которые подключились на помощь, не ознакомлены с правилами и могут их упускать. Путаница с задачами возникала несколько раз, но здесь поможет коммуникация. Над задачей никогда не работает один специалист, поэтому новичков быстро
ставят на рельсы истиныобучают правилам ее выполнения.Зависимости в задачах с FT. Выход из таких ситуаций уже найден, однако время от времени они могут возникать. Плюс в том, что теперь команда об этом знает и может сконцентрироваться на их решении в первую очередь.
Вывод
Давайте подведем итог и посмотрим, что же стало с командой смельчаков, которая бросила вызов гиганту.
С помощью такого инструмента как FT команда сумела раздробить новую большую разработку и предоставила бизнесу и пользователям пилотную версию продукта. А дальше процесс разработки пошел куда быстрее. Сроки перестали гореть, команда вздохнула с облегчением и наступил мир…
… тут должно быть продолжение, и оно есть! Сейчас наша команда заканчивает работу по выпуску уже второго этапа. Пилот преобразовался в полноценный процесс и радует пользователей, потребителей и бизнес, а мы продолжаем работу над улучшением продукта.
Спасибо за внимание!
Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
