Полное понимание канареечных релизов: от происхождения названия до техник проведения. Узнайте, как эффективно использовать канареечные релизы в разработке ПО.

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

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

Канареечные тесты используют: 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 часа на поиск проблемы, оценку того, как это влияет на пользователей, исправление. Если не успевают, то сразу откатывают все изменения назад. Это позволяет не блокировать выкатку другого функционала.

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

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