Канареечные релизы — это способ безопасно протестировать новый код на небольшом количестве пользователей. Если всплывет ошибка, то обновление автоматически откатят к стабильной версии. Если все ок, то постепенно увеличат количество пользователей.

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

Канареечные тесты используют: Netflix, Google, Miro, Mozilla и их ночные и бета–версии Firefox, Google Play, Apple App Store.

Канареечные релизы — это  способ безопасно протестировать новый код на небольшом количестве пользователей. Если всплывет ошибка, то обновление автоматически откатят к стабильной версии. Если все ок, то постепенно увеличат количество пользователей.

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

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

В IT канарейками выступают пользователи. Люди работают с продуктом в обычном режиме, никто их не предупреждает, что сейчас будет релиз новой фичи. Разработчики выкатывают обновление и  следят, все ли работает, как они задумали. Если канареечный тест пройдет успешно, то новую версию сделают доступной для всех пользователей. Canary пропадает остается только release.

Канареечные релизы проводят после тестов в предпроизводственной среде. Затем релизят обновление на группу реальных пользователей.

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

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

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

Когда лучше не применять канареечные релизы:

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

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

Канареечные тесты используют: Netflix, Google, Miro, Mozilla и их ночные и бета–версии Firefox, Google Play,  Apple App Store.

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

При планировании развертывания учитывают:

1. Сколько пользователей отправят на канарейку вначале и в сколько этапов.
2. Как долго будет проходить тестирование. Стандартная продолжительность: от нескольких минут до нескольких часов.
3. Какие метрики будем отслеживать для анализа прогресса. Обязательные — отчеты об ошибках, производительность приложения.

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

Для начала попробуйте логарифмический подход с шагами: 1-10-100. То есть начинайте канареечный тест с отправки обновления 1% пользователей. Это поможет убедиться, что нет никаких серьезных проблем.

Затем повышайте количество пользователей до 10% от общего числа. Это даст посмотреть, как  обновление ведет  себя под нагрузкой.

Наконец, переносите обновление на 100% пользовательской базы и завершайте тестирование.

Когда наберетесь опыта, поэкспериментируйте с количеством этапов, чтобы выбрать оптимальное для своего продукта.  Кому–то достаточно двух этапов по 2-100. Другие предпочитают постепенные шаги по 10-20-50-100.

На канареечный релиз нет отбора. Пользователи попадают в него случайным образом.

Канареечные релизы путают с сине–зелеными и другими релизами. Разберемся, чем они отличаются:

• Канареечные релиз позволяет провести инкрементное развертывание нового сервиса. А при сине–зеленом релизе новая версия "переключается" одним действием и становится доступной всем пользователям мгновенно.
• Канареечный релиз раскрывает конкретную версию всего приложения или сервиса.
• Релиз dark canary отличается от обычного canary тем, что дублирует трафик от небольшой подгруппы пользователей и направляет его на новую версию сервиса, которая не возвращает данные пользователю. Новый сервис тестируется на реальном трафике, но конечные пользователи не видят результатов — их видит только команда инженеров.

В Miro канареечные релизы выкатывают на три разные роли, которые максимально задействованы в работе пользователей. Релизы выкатывают на три сервера:

1. API Server
2. Public Server
3. Board Server

Команда запускает канареечный релиз и следит за процессом в Sluck.  Тестирование длится ровно 4 часа.  Все это время команда смотрит метрики в  Grafana  и ошибки в Sentry.

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

Канареечные релизы — это  способ безопасно протестировать новый код на небольшом количестве пользователей. Если всплывет ошибка, то обновление автоматически откатят к стабильной версии. Если все ок, то постепенно увеличат количество пользователей.

Канареечные релизы — это  способ безопасно протестировать новый код на небольшом количестве пользователей. Если всплывет ошибка, то обновление автоматически откатят к стабильной версии. Если все ок, то постепенно увеличат количество пользователей.