Изучение темных запусков, флагов функций и экспериментов A/B
Традиционно программные продукты разрабатываются и выпускаются поэтапно. Просто подумайте о своих установленных приложениях на вашем компьютере или смартфоне; часто он сообщит вам, когда вам нужно перейти на новую версию, и вам придется выполнить для этого действия вручную. Компания решит, что будет в новых версиях (будь то патч, минор или мажор), и вырежет выпуск для распространения.
Хотя это по-прежнему справедливо для настольных и мобильных приложений, сегодня многие веб-продукты развертываются с использованием непрерывной интеграции (CI). То есть в тот момент, когда разработчик отправляет свой код в основную ветку, он собирается и подвергается автоматическому тестированию в инструменте CI. После прохождения тестов он автоматически развертывается в рабочей среде. Этот метод обычно не имеет конкретных выпусков, поскольку изменения вносятся мгновенно и поэтапно.
Хотя это удлиняет цикл разработки и поощряет итерации, иногда это может быть рискованно. Возможно, вы не рассмотрели все крайние случаи в своих автоматических тестах, или, возможно, ваша новая функция окажется не масштабируемой и рухнет под тяжестью всех ваших пользователей.
Последнее, чего вы хотите, — это чтобы ваша новая функция вызвала лавину ошибок и обращений в службу поддержки. Так что же нужно сделать, чтобы снизить риск выпуска новой функции, одновременно пользуясь преимуществами более короткого и автоматизированного цикла разработки?
Темный запуск
Один из способов минимизировать риск — развернуть функцию только для части ваших пользователей, а не для всей пользовательской базы. Это называется темный запуск.
Это может быть особенно полезно, если вы работаете над рефакторингом или функцией с совершенно новым кодом, поскольку создает очень четкое разграничение между старым и новым кодом.
Например, скажите, что вы изменили дизайн и перестроили страницу профиля с нуля. Вы можете не быть полностью уверены, будет ли это работать с каждым случаем, потому что страница профиля содержит много пользовательского контента. Итак, вы решаете запустить новую страницу в темноте, заменив старый код на новый для подмножества пользователей.
Часто это включает добавление параметра URL для поиска:
/[username]?new-profile-page=true
Это отличный пример, если вы хотите быстро протестировать вещи, но вам нужно убедиться, что параметр всегда установлен, когда вам это нужно.
В качестве альтернативы вы можете положиться на локальное хранилище, чтобы установить его и забыть, например localStorage . В этом примере вам нужно будет установить элемент случайным образом или вручную через консоль разработчика:
Обратите внимание, что если функция темного запуска влияет на несколько страниц или потоков, вам придется передавать этот параметр на каждом этапе пути.
Наконец, вы выбираете продолжительность запуска темного запуска. В течение этого времени необходим мониторинг, так как вы должны убедиться, что новый код не выдает ошибок и масштабируется по мере добавления новых пользователей в корзину.
По прошествии этого периода времени, если все выглядит хорошо и денди, вы очищаете свой код, удаляя любую логику ветвления и запускаете свою функцию, включая ее для всех пользователей.
💡 Вы можете использовать темный запуск для создания бета-программ!
Реализовать с помощью «флажков функций»
Некоторые темные запуски выбирают подмножество автоматически и случайным образом или отображаются только в том случае, если присутствует параметр URL. Однако представьте, хотите ли вы больше контроля; возможно, вы хотите, чтобы очень определенные пользователи могли использовать вашу новую функцию. Введите флажки функций.
Флаг функции — это просто двоичный переключатель, указывающий, должен ли пользователь видеть функцию или нет. Для реализации флагов функций обычно требуется создание службы или пользовательского интерфейса, которые позволяют администратору выбирать, какие пользователи должны видеть новую функцию, без необходимости развертывания какого-либо нового кода.
Это требует большого количества операторов if-else в коде, чтобы определить, включен или выключен флаг функции:
То, как устанавливается флаг функции, может быть реализовано несколькими способами.
Вы можете создать пользовательский интерфейс, который позволит вам искать пользователя и назначать его ему. Или вы могли бы применить флаг функции к подмножеству пользователей, выбранных вами с помощью фильтров. Например, может быть, ваша новая страница профиля иллюстрирует количество подписчиков, и вы хотели бы показывать ее только пользователям с более чем 10 000 подписчиков.
💡 Вы можете использовать такие продукты, как LaunchDarkly, чтобы упростить работу с пометками функций!
Недостатки
У темного запуска есть два основных недостатка:
Во-первых, это может затруднить отслеживание потоков. Если, например, вам пришлось изменить URL-адрес для новой функции (скажем, у вас был /[username] в качестве маршрута для старой страницы профиля, а теперь у вас есть /profile/[username] для новой), вы должны убедиться, что каждая ссылка, ведущая на профиль зависит от того, в какой группе находится пользователь.
Во-вторых, вам, возможно, придется поддерживать две версии функции. Если вы занимаетесь редизайном или рефакторингом страницы или функции, если обнаружена ошибка, затрагивающая и то, и другое, вам придется исправить ее два раза, прежде чем вы полностью развернете новый код.
А/Б эксперименты
Другой метод, который компании используют для тестирования новых функций, — это эксперименты A/B (также известные как тестирование A/B).
Вы помните, как посещали уроки естествознания и узнали, что хороший эксперимент имеет научный контроль, чтобы свести к минимуму скрытые переменные, которые запутывают ваши выводы, а также гипотезы для проверки против этого контроля?
Поздравляем, вы уже на полпути к пониманию экспериментов A/B!
В эксперименте A/B вы тестируете несколько вариантов функции, страницы или потока, чтобы увидеть, какой из них работает лучше. Не позволяйте имени обмануть вас; это не обязательно должен быть только контроль и один вариант, у вас может быть несколько вариантов против контроля. Мы могли бы легко назвать это экспериментом A/B/C/D/E/….
Эксперимент A/B начинается с желаемой метрики, которую вы хотите улучшить, и гипотезы о том, как этого добиться. Возможно, вы задаетесь вопросом: Как мы можем улучшить процесс регистрации, чтобы больше пользователей успешно создавали новые учетные записи?. В этом случае желаемой метрикой является количество созданных новых учетных записей, и гипотеза состоит в том, что изменение процесса регистрации поможет улучшить эту метрику. .
Однако может быть неочевидно, что нужно изменить в процессе регистрации. Может быть, отказ от аватарки ускорит процесс? Может быть, требование от пользователя следить за группами сбивает их с толку, а не привлекает? Может быть, текущий поток на самом деле лучший?
Таким образом, вы проводите эксперимент, чтобы определить лучший способ продвижения этой метрики вперед. Вы сохраняете контроль, то есть сохраняете текущий поток как есть. Затем вы создаете N вариантов.
Для экспериментов A/B необходимо создать N+1 подмножеств пользователей для тестирования вариантов и контроля. Часто у команды есть пользовательский интерфейс, из которого они могут объявить свои сегменты и включить вариант для определенных пользователей.
Затем, как и при запуске в темноте, вы выбираете период времени для проведения эксперимента. В течение этого времени нужно постоянно следить за движением выбранной вами метрики; в этом случае запись новых учетных записей, созданных для каждого варианта.
В конце вы сравниваете производительность каждого варианта и контроля, и то, что получилось лучше, будет полностью реализовано в продукте и включено для всех. Как и в случае с темным запуском, требуется фаза очистки, чтобы удалить логику ветвления и любой другой беспорядочный код, который не нужен для выбранного варианта.
Недостатки
На мой взгляд, самым большим недостатком экспериментов A/B является стоимость разработки. Не только каждый вариант должен быть построен, но и логика ветвления, мониторинг и определение того, какие пользователи входят в какие сегменты. Это много работы и может занять время от других важных проектов.
Во-вторых, A/B-тестирование — это количественная попытка, основанная на одной метрике. Это может быть хорошо, если то, что вы хотите измерить, очень конкретно, но часто важно настроиться на других.
Эти стратегии должны знать все, кто планирует работать в области разработки продуктов или данных. Никто из нас не может точно предсказать, что может пойти не так с новой функцией или каков наиболее оптимальный подход к функции или потоку. Мы не наши пользователи, в конце концов!
