Канареечное тестирование

• Что это
• Кто выполняет и как
• Feature Flags
• Полезности
• Челенджи
• В каких ситуациях подходит
• Что такое канареечный релиз
  • Подробнее
• Что с автотестами
• FAQ

Что это

Тестирование новой версии/функции у небольшого количества пользователей в реальном окружении.

Канареечное тестирование проверяет новые функции в приложении, не оказывая при этом влияния на user experience или сводя это влияние к минимуму.

В обиходе путают термины канареечное тестирование, канареечный релиз и канареечное развертывание, однако в действительности эти понятия различаются.

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

Название произошло от метода определения опасности при подземных работах, использовавшегося шахтерами с начала ХХ века для обнаружения в шахтах газов без запаха, но смертельно опасных — удушающего угарного газа СО, а также взрывоопасного метана, к которому канарейки также чувствительны. Шахтеры спускались в забой с клеткой с этой гиперактивной птицей, и если канарейка умолкала, то шахтеры понимали, что содержание СО и CH4 достигло опасного уровня, и покидали забой. 

Сверху кислородный баллон — да, канареек не использовали как расходный материал, вопреки расхожему мнению, им даже подавали кислород, по крайней мере в Англии. По рекомендациям ученых шахтеры пробовали брать с собой и других мелких, активно двигающихся (то есть активно потребляющих кислород) животных, тонко чувствующих газовый состав воздуха, типа мышей. Но прижились исключительно канарейки. Может быть также и потому что громко и весело щебетали и радовали суровых горняков, работающих в тяжелейших условиях. Вплоть до 1986 года в Великобритании канарейки работали живыми датчиками газов.

Аналогичным образом, канареечное тестирование программного обеспечения позволяет выявить дефекты на ранних стадиях релиза minor-функций (канареечный релиз — о нем отдельно в конце), и этим помогает предотвратить серьезные дефекты для всех пользователей.

Кто и как выполняет

Разработчики. Они проводят канареечное тестирование, развертывая определенную функцию или версию для очень небольшого количества пользователей. Цель: проверить, нет ли проблем в новом коде, прежде чем релизить его для всех пользователей. Такой подход, ограничивающий релиз небольшой группой конечных пользователей, позволяет команде проверить и оценить новую функцию, прежде чем делать ее доступной для всех (тем самым рискуя). Обычно выбирают 5-10% от общего числа пользователей.

Feature Flags

Канареечное тестирование часто проводится с применением так называемых feature flags, когда код релизят, но не активируют функции автоматически. Разработчики удаленно активируют эти функции у части пользователей. Метод feature-flags позволяет таргетировать приложение например на 1% пользователей, при этом мониторят метрики (количество ошибок, латентность, влияние активированной функции на бизнес-показатели). Таким образом избегают негативных последствий для всех пользователей, если что-то пойдет не так с этим апдейтом. 

И, обратно, можно легко деактивировать апдейт, переключив feature flag и отказавшись от апдейта, если пользователи не одобряют, или возникли технические сложности. Все можно делать постепенно, инкрементально, то есть поэтапно «раскрывая» функциональность пользователям. 

Полезности

Уменьшение общей проблемности кода и улучшение user experience; внедрение апдейтов на проде с минимальными проблемами для юзабилити, или вообще без каких-либо заметных осложнений для 90-99% пользовательской базы. А также:

• Простота метода. Новые функции обычно небольшие «по коду», активированы для немногих пользователей от которых проще собрать фидбек — все просто и быстро.
• Легко откатить изменения, если канареечный тест оказался неудачным, пользователи раздражены.
• Low-maintenance-процесс: разработчики сосредотачиваются на небольшой части кода, запускают ее на прод, анализируют результаты, и если все ОК, переходят к следующей функции.
• Не нужно переводить систему в downtime-состояние для релиза
• Не нужна большая-сложная инфраструктура, все делается дешево и сердито, стоимость багфикса также небольшая.
• Разработчики учатся экспериментировать с кодом и делают это безопасно.
• Пользователей можно сделать бета-тестерами, они будут давать более-менее годный фидбек, а главное своевременный.

Челенджи

Помимо всяческих полезностей, метод обладает и недостатками (впрочем не очень существенными):

• В первую очередь, риск проблем, даже для того небольшого числа пользователей
• Не будучи должным образом автоматизированным и интегрированным в пайплайн, такое тестирование может превратиться в достаточно трудоемкий процесс, уязвимый к мелким досадным ошибкам. Впрочем грамотные DevOps’ы знают как это решать, налаживая анализ логов и работу с полученными данными.
• Канареечное вряд ли идеально для standalone-приложений, разворачиваемых на пользовательских лэптопах, смартфонах и ПК (огромный парк устройств).
• А если у нескольких миллионов пользователей уже, скажем, несколько десятков версий одного приложения, процесс становится ощутимо сложным.

В каких ситуациях подходит хорошо

Стандартное применение: перед релизом новых версий, для оценки «как оно вообще». Подразумевается, что код перед этим прошел тщательнейшее модульное и интеграционное тестирование, во избежание проблем с деплоем и других подобных «производственных», что позволит сосредоточиться на user experience. Вообще, канареечное тестирование можно считать хорошей практикой, позволяющей видеть код «in action» и получить фидбек реальных пользователей, прежде чем решать, годен ли код к релизу. Особенно для команд, работающих в режиме непрерывной интеграции и деплоя (ну то есть практически всех).

Еще кейс, когда такой процесс является правильным выбором — когда тестовое окружение по каким-то причинам нельзя максимально «приблизить» по условиям к прод-окружению. В таких ситуациях (очень частых) проведение канареечных тестов с небольшой группой конечных пользователей — отличный способ быстро обнаружить проблемы в live-окружении.

Что такое канареечный релиз

Как нетрудно понять из вышеизложенного, канареечный релиз (canary release) — это новая версия/функция, которую разработчики делают доступной для некоторого количества пользователей. Этот «свежий код» и называется канареечным релизом; по завершении разработки функции канареечный релиз деплоится в реальное окружение. Затем для какого-то процента пользователей новая функция активируется («флагами», о которых шла речь выше), ну и разработчики ждут отзывов (фидбека) и анализируют логи и полученные данные, а также отслеживают например, не пострадала ли производительность, и устраняют возникающие проблемы и ошибки. И поскольку канареечный релиз затрагивает лишь небольшой процент пользовательской базы, то локализация, обнаружение и устранение проблем — не требует времени, усилий, и денег. 

Canary-релизы позволяют избежать простоя команды и железа, потери доходов компании или, того хуже, неудовлетворенности клиентов. Канари-релиз дает быструю информацию о новой функции «вообще» — а это всегда важно для руководителей проекта.

Подробнее о canary release

Мы уже знаем, что canary release — это стратегия деплоя, когда новая функция делается доступной только для ограниченного числа пользователей. Все части приложения, получившие обновления, постоянно мониторятся на предмет возникающих проблем; а также, разумеется, отслеживаются бизнес-показатели. Далее разработчики и стейкхолдеры принимают решение о внедрении новой функции для всей клиентской базы, с учетом результатов, полученных в ходе канареечного тестирования. Если при «пробах» новой функциональности не возникло никаких отрицательных явлений (особенно в сфере безопасности и производительности), то можно постепенно выкатывать обновление для остальных пользователей.

Canary-релизы различаются для веб-приложений и для мобильных. В первом случае канареечный релиз можно реализовать через две веб-версии; например расширение для Chrome можно сделать доступным только для части пользователей и проверить результат; а далее зарелизить глобально. 

Для мобильных приложений последняя версия делается доступной для какой-то группы пользователей; поскольку у пользователя на руках только одно окружение (его смартфон), нельзя скажем сделать несколько версий для одного пользователя; поэтому действуют через фича-флаги. Например, понадобилось обновить функцию поиска в приложении, чтобы можно было искать точную фразу; удаленно включается соответствующий feature flag и функция активируется у некоторых пользователей. 

Что с автотестами

Перед проведением канареечного тестирования следует выполнить необходимые автоматизированные тесты; это позволит убедиться, что часть кода, которая «ушла в live» выбранным пользователям, не содержит грубых багов, обладает определенным уровнем надежности. Обычно этот процесс налажен в командах; используется А/В-тестирование, полагаются на мощь современных методик DevOps, которые позволяют «в конвейерном режиме» разрабатывать, тестить, и разворачивать любые модификации кода.

Саммари и FAQ

Кратко плюсы canary-подхода: кроме подробно перечисленных выше (тихая безопасная проверка новой функции в live-окружении), также например A/B-тестирование без «даунтайма». А также плавность, постепенность введения новых функций, особенно важно если пользовательская база огромна и ошибки недопустимы.

Почему канареечный релиз и канареечное тестирование: как когда-то шахтеры брали с собой в шахту клетку с канарейкой, чтобы она сигнализировала им об опасности задохнуться — так и программисты теперь взяли в привычку тестировать свой софт сначала на небольшой части своих пользователей.

Источники: 1,2