Флаги функций - чрезвычайно важный метод быстрого развертывания высококачественных изменений в производственной среде. Моя группа в Microsoft с большим успехом приняла их за последние несколько лет. Они позволяют нам интегрировать почти все наши изменения в одну ветку. Они позволяют нам контролировать развертывание функций и обеспечивать предохранительный клапан на случай, если что-то пойдет не так. Однако использование флагов функций в качестве долгосрочных отказоустойчивых систем может привести к проблемам.

Интеграция кода

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

Я помню, как работал над ныне несуществующей функцией чата. Несмотря на то, что наш фреймворк поддерживал использование флагов функций, в культурном отношении они не воспринимались и не использовались так широко. Поэтому вместо того, чтобы полагаться на них, мы начали работу в функциональной ветке, где внесли несколько крупных изменений. После нескольких недель проектирования, кодирования и тестирования мы попытались объединиться. Однако на той же неделе другая команда объединила ветку, которая также находилась в разработке. К сожалению (для меня), они объединились первыми, и я потратил неделю на устранение конфликтов, повторную стабилизацию и повторную проверку. Какая трата!

Когда используются флаги функций, изменения кода становятся инкрементными и последовательно объединяются в основную ветку. Код не обязательно должен быть готов на 100% для слияния. Получите работу некоторых начальных сценариев, отметьте изменение и слияние (после проверки кода, конечно). Это сводит к минимуму потери из-за конфликтов слияния и помогает проверить реальное состояние продукта на ранних этапах спринта.

Продакшн-фобия

«Я на 100% уверен, что это сработает в продакшене» - Никто и никогда

Независимо от объема местного тестирования, как только клиенты получают в свои руки изменение, вступает в силу Закон Мерфи. Трудно эффективно учесть все ситуации, которые могут произойти, если вы работаете в масштабе на основе производственных данных.

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

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

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

В чем подвох?

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

«Эта функция работает сейчас, но что, если мы столкнемся с проблемами завтра. Боюсь!" - Мне

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

Я впервые столкнулся с этим исправлением производительности, которое сделал год назад. Обеспокоенный потенциальным, непреднамеренным воздействием изменения, я отметил его и оставил помеченным на несколько месяцев (несмотря на то, что все, казалось, работало нормально). Примерно через шесть месяцев я получил от клиента отчет о редком состоянии гонки, когда мое изменение вызывало проблему. Изучая проблему, я решил, что самым быстрым решением для этого клиента было отключение флажка. Когда флаг отключен, клиент столкнулся с еще более серьезными проблемами. Старый код больше не действовал, и мой клиент был еще больше сбит с толку и разочаровался.

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

Больше нет страха

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