Canary Releases

Oleg Filimoshin
Epicntr
Published in
3 min readSep 14, 2020

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

Метод снижения риска внедрения новой версии программного обеспечения в “производственную среду”. Происходит путем плавного развертывания изменений для небольшой группы пользователей.

Отрывок из блога Мартина Фаулера

Откуда такой термин?

Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.

В чем основная суть метода?

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

Альтернативный способ?

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

Какие плюсы у канареечного релиза?

  • Отпадает необходимость держать лишние окружения: экономия времени разработчиков на поддержку актуального состояния тестовой среды.
  • Снижение финансовых затрат на n-ое количество тестовых окружений.
  • Тестирование происходит сразу на продакшен среде — выявляются ошибки интеграции, которые могут не возникать на тестовом окружении.
  • Позволяет перейти на Trunk-Based Development (Patterns for Managing Source Code Branches) — подход, когда в системе контроля версий используется одна ветка, в которую сразу попадает весь написанный код. Такой подход избавляет разработчиков от затрат времени на решение больших и сложных конфликтов в коде. А так же исключает ситуацию, когда уже реализованный функционал где-то теряется :)
  • Бонусом появляется возможность проводить A/B тесты на пользователях и находить лучшее решение, а также быстро проверять гипотезы.
  • Возможность демонстрации заказчику будущих изменений сразу на продакшен окружении.
  • Ранний доступ для лояльных пользователей и сбор обратной связи позволяют узнать как воспримут будущие изменения реальные пользователи.
  • Если есть разные платформы (andord, ios, web) — одновременно для пользователей всех платформ предоставить доступ к новому функционалу — единовременный релиз.
  • Культура децентрализованного принятия решений — принимать решения на основе продуктовых или технических метрик. Например, автоматизировать откат новой фичи в случае аномального роста нагрузки после релиза.

Какие накладные расходы для использования канареечных релизов?

  • Разработчик должен гарантировать, что его код не содержит синтаксических ошибок и способен запуститься. Решается успешной компиляцией или использованием статического анализатора кода для интерпретируемых языков перед поставкой кода в продакшен среду.
  • Использование готового или разработка своего механизма переключения доступа к фичам — Feature Toggles (aka Feature Flags)

Почему стоит использовать канареечные релизы?

Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.

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

--

--

Oleg Filimoshin
Epicntr
Editor for

I’m an architect (public cloud) I have a wide experience in design of networks, software development, design of architecture