Канареечные релизы что это
Канареечные релизы – кто использует?
Давно хочу проект, на котором можно будет попробовать организовать канареечные релизы, но масштаб и критичность не те (масштаб маловат, а критичность систем в большинстве случаев великовата для таких экспериментов).
Кто использует – расскажите, как оно, я хоть позавидую.
P.S. Если кто-то не в курсе, то канареечный релиз – это способ безопасного тестирования нового кода в продакшене, а именно – частичный выпуск на небольшое количество пользователей с автоматическим откатом или, наоборот, увеличением количества пользователей по мере понимания, что код работает корректно.
Слово “канареечный” взято не с потолка, раньше шахтеры брали с собой канареек в клетках в угольные шахты для обнаружения повышения концентрации угарного газа. Канарейка, пока все было хорошо, постоянно пела, а при малейшей концентрации угарного газа – тут же умирала. То есть как только канарейка переставала петь – все знали, что самое время эвакуироваться. Птичек, конечно, жалко, но представляю, скольким шахтерам они так жизнь спасли.
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Тест канарейками
Я работаю в IT, где иногда для тестирования систем используется «канареечный тест». Смысл заключается в том, что новую версию системы делают доступной для небольшого числа реальных пользователей, так называемых «канареек», которые продолжают работать с системой в обычном режиме, а тем временем инженеры, ответственные за процесс разработки, внимательно отслеживают аномалии, убеждаются в том, что всё работает как задумано. Если «канареечный тест» проходит успешно, то новая версия системы становится доступной для всех пользователей. Принцип работы и название «канареечного теста» пришло в IT от шахтёров: в прежние времена, клетки с канарейками заносили в шахты для того, чтобы проверить их на наличие опасных для жизни газов. Канарейки очень чувствительны к мельчайшим примесям газа в воздухе, поэтому если птица умирала или вела себя неадекватно, то шахтеры немедленно покидали опасное место.
Вопрос в том, как масштабировать подобный локальный успех: с Ридом на позиции стартового центрового мы можем на равных бодаться против медленных центровых таких как Адамс, ЛаМаркус Олдридж или Вучевич, но игра против Атланты показала, что мобильный, атлетичный центровой типа Капелы будет казаться Уилтом Чемберленом, играя против лёгкой пятерки Миннесоты. В плей-офф 2017-18 года именно Капела стал «криптонитом» для Таунса, вчистую переиграв Карла на обоих концах площадки. Сейчас эта дуэль могла бы ответить на множество вопросов о системе «five-out», жаль из-за болезни Таунса это противостояние откладывается, как и тест системы в целом.
For reference, the Wolves are shooting 56.7% from the restricted area — second worse in the league
Houston is averaging almost the same number of RA attempts and is shooting 65.8% on those looks
С момента вступления в должность генерального менеджера Розас шаг за шагом воплощает идеи баскетбола, построенного на движении мяча и игроков, взаимозаменяемости позиций, грамотного использования пространства для развития атаки. Именно это и есть главная цель тестирования текущего состава и тренерского штаба. Эти принципы хорошо объясняет автор этих видео.
D’Angelo Russell Last 6 games: 26.3 PPG 6.7 APG
Даже в победном матче против Пеликанс нападение с Рикки забуксовало в концовке, потому что в упрощенном нападении от ведущего разыгрывающего требуется в равной степени умение обострять и пасовать, неслучайно МакЛафлин выглядит лучше испанца в роли запасного разыгрывающего.
Эту вроде бы несложную задачу с тремя переменными (разыгрывающими) и игровым временем наш тренерский штаб пока решить не может, это выражается в неудачных ротациях, несвоевременных заменах, негативно отражаясь на результатах команды. Я наблюдаю за болельщиками Миннесоты на англоязычных форумах и как часто случается с болельщиками команд-аутсайдеров, часть фанбазы ударилась в отчаяние (и я прекрасно понимаю их чувства), другая часть с «короткой памятью» стала «выделять» токсичные комментарии, требуя головы главного тренера и даже менеджера. Это после 16-ти игр. Некоторые особо «чувствительные канарейки» стали хэйтить собственных(. ) игроков. Я позволю себе напомнить несколько моментов, которые лично мне помогают «дышать» в такой сложной «игровой» ситуации.
Показал свой талант МакДэниэльс, которыйт хорошо выходит на подстраховку, защищается на периметре и имеет хороший релиз броска. Ему явно не хватает мышечной массы, но посмотрите как он бьётся в защите.
Работа тренерского штаба с Эдвардсом и карьера молодого игрока только началась. Но материал для работы интересный, многообещающий. Ну и уже стандартно, где-то один раз в неделю, он делает вот так.
К сожалению, ситуация с Таунсом не позволяет нам завершить первый этап «тестирования» системы. Поэтому предварительные выводы будут сделаны когда Карл отыграет 15-20 игр. По времени это совпадает с началом активных переговорах по трейдам, включая игроков подписанных в межсезонье. Уже сейчас начинают циркулировать слухи по обменам, но опытные менеджеры ждут своего шанса, проводят оценку своих активов, пытаются вырастить молодых игроков, реанимировать «сбитых лётчиков». Именно поэтому молчит Уджри, хотя Торонто ужасны в этом сезоне. Молчит Райли, хотя Майами теряет минуты драгоценного прайма Батлера, а Оладипо просится во Флориду. Именно поэтому ждёт и Розас. В прошлом сезоне первый этап тестирования закончился кардинальными изменениями и трейдами и сегодня никто уже не вспоминает что за нас играли Дженг, Ковингтон, КБД, Джордан Белл, Напьер, Грэм и Тиг.
Болельщики Миннесоты пережили 2020 год и хочется уже увидеть больше побед от команды, но мне хочется сказать напоследок одно: в своё время канарейки умирали для того, чтобы шахтёры могли жить. Это был жестокий, но эффективный способ, чтобы люди могли работать дальше в тяжелых условиях. Я не верю в чудеса, я верю в тяжелый труд, в работу. Поэтому я уверен, что данный этап становления команды (и организации) необходим. Я уверен, что это тестирование скоро закончится будут сделаны выводы, предприняты меры и начнётся новый этап развития. Иначе зачем умирают «канарейки»?
P.S. Вы можете подписаться на мой телеграм-канал, где я ежедневно скидываю интересные новости, связанные с Волками. За сим прощаюсь, до скорого, берегите себя!
Примечание: текст готовился в течении двух недель, поэтому точные цифры статистики могут разниться. Пусть это никого смущает, ведь сути дела это не меняет.
Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm
Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.
Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:
Еще проще представить такой вариант можно на kubectl, а в документации по Kubernetes даже есть полноценный туториал по этому сценарий. Но главный вопрос этого поста заключается в том, как мы собираемся автоматизировать этот процесс, используя Helm.
Автоматизация канареечного деплоя
Прежде всего нам понадобится карта чартов Helm, в которую уже внесены обсуждаемые нами выше ресурсы. Выглядеть она должна быть примерно так:
Основа концепции Helm — управление мультиверсиями релизов. Stable-версия — это наша основная стабильная ветка кода проекта. Но с помощью Helm мы можем развернуть канареечный релиз с нашим экспериментальным кодом. Главное — сохранить обмен трафиком между стабильной версией и канареечным релизом. Управлять всем этим мы будем с помощью специального селектора:
Наши как «канареечные», так и stable-ресурсы деплоя будут указывать эту метку на модулях. Если все настроить правильно, то во время деплоя канареечной версии нашей карты чартов Helm мы увидим, что трафик будет направляться на свежеразвернутые модули. Стабильная версия этой команды будет выглядеть так:
Теперь давайте проверим наш канареечный релиз. Чтобы задеплоить канареечную версию, нам надо помнить о двух вещах. Название релиза должно отличаться, чтобы мы не накатили апдейт на текущую stable-версию. Версия и тег также должны отличаться, чтобы мы могли развернуть другой код и определить различия по меткам ресурсов.
Вот, собственно, и все! Если пингануть службу, то можно увидеть, что канареечное обновление маршрутизирует трафик только часть времени.
Если вы ищите инструменты автоматизации деплоя, которые включают в себя описанную логику, то обратите внимание на Deliverybot и на инструменты автоматизации Helm на GitHub. Чарты Helm, используемые для реализации описанного выше способа лежат на Github, вот тут. Вообще, это был теоретический обзор того, как реализовать автоматизацию деплоя канареечных версий на практике, с конкретными концепциями и примерами.
Как эффективно релизить монолит, в который коммитят 150+ разработчиков из разных офисов
Я работаю инженером в Miro в команде, отвечающей за улучшение процесса релизов.
За последний год у нас появился зарубежный офис разработки, инженерная команда выросла вдвое, а полгода назад компания временно перешла на удалёнку. Параллельно с этим происходил постоянный кратный рост количества пользователей нашего продукта.
На фоне этих изменений нам важно было не терять в качестве и скорости, поэтому мы серьёзно обновили процесс серверных релизов. Расскажу про изменения, которые в итоге повысили долю успешных релизов.
Серверные релизы
Наш backend — это монолитное Java-приложение, которое может быть запущено с разными ролями для выполнения разных задач. Для работы backend мы используем AWS инстансы (CPU 4 ядра, RAM 16 ГБ). Большая часть backend-серверов – приложение, которое держит постоянное веб-сокетное подключение с клиентом, чтобы пользователи всегда видели реальное состояние досок в Miro. Для этих серверов мы используем роль Board-сервер (пользователи попадают на них при работе на досках). Для работы с бизнес-логикой и API-запросами используем роль API-сервер.
Релизы мы делаем бесшовными (graceful deploy) и стараемся проводить их во время наименьшей нагрузки на сервис. Во время планового релиза у нас в среднем 60.000 онлайн-пользователей и 50 работающих board-серверов.
Мы считаем релиз успешным, если он вышел в срок и в него попали все задачи, которые были готовы к релизу на момент его запуска. Соответственно, релиз считается неуспешным, если что-то пошло не так, потому что ошибки, которые потребовали остановки или отката релиза, увеличивают время доставки (time to market).
Любые изменения в процессе проведения релизов мы оцениваем исходя из того, насколько они приближают нас к успешному релизу.
Успешный релиз — это релиз, который вышел в срок и в который попали все задачи, готовые к релизу на момент его запуска.
Процесс подготовки релиза:
На каждый пулл-реквест прогоняется релевантный набор e2e тестов. Добавить изменения в мастер можно только при успешном прохождении всех тестов. Внутри автотестов есть маппинг соответствия тестов и кода продукта. Набор e2e-тестов для пулл-реквеста определяется нашим инструментом, который выбирает тесты, основываясь на этом маппинге и анализируя изменённые файлы в пулл-реквесте.
Каждый собранный мастер проходит полную регрессионную проверку. Релиз возможен, если все тесты прошли успешно. Упавшие тесты правят команды, ответственные за функциональность.
Для того чтобы релиз вышел автоматически, мы используем Allure Enterprise Edition, в котором отмечаем false-positive тесты как Resolved.
Процесс релиза:
Ищем сборку со 100% успешных тестов и версией, которая больше текущей версии на продакшене.
Запускаем канареечный релиз.
Мониторим метрики релиза в течение 4х часов.
Ставим статус Approved или Broken по завершении канареечного релиза. При статусе Approve основной релиз автоматически запускается следующим утром, при Broken запуска не произойдет.
Для релиза на API- и board-серверах создаём инстансы с новой версией. Количество инстансов рассчитываем, исходя из текущей нагрузки и добавляем 20%, чтобы не допустить высокой нагрузки во время или сразу после релиза.
Пользователи постепенно переходят на новые сервера, старые сервера мы выключаем и удаляем.
Релиз от создания инстансов до полного перехода на новую версию занимает полтора часа.
Канареечный релиз
Канареечный релиз нужен для того, чтобы валидировать изменения на небольшой случайной выборке пользователей. В ходе него мы поднимаем несколько серверов с новой версией и наблюдаем за ситуацией. Если на канареечном релизе всё идёт хорошо — релизимся на все сервера.
Процесс канареечного релиза
Канареечный релиз не способ тестирования на проде, а дополнительный эшелон защиты. Он позволяет уменьшить количество пользователей, которые столкнулись с ошибкой, если кейс сложный или если он повторяется только на инфраструктуре продакшена.
Для быстрой реакции на ошибки в канареечном релизе мы ввели роль дежурного серверного разработчика, которую выполняет каждый разработчик по очереди. Дежурный разработчик в течение четырех часов работы канареечного релиза реагирует на новые ошибки в Sentry и на общие предупреждения из Grafana, может остановить релиз самостоятельно при необходимости. После завершения канареечного релиза он обновляет статус релизной сущности в Bamboo: Approved или Broken.
В случае срочных релизов вне расписания команды могут запустить релиз через деплой в Bamboo самостоятельно, для этого в каждой команде есть инженеры с необходимыми правами.
Пользователи попадают на канареечный релиз случайным образом, с помощью балансировщика. Случайная выборка позволяет валидировать релизы на разных пользователях, но имеет и недостатки: без изменения в коде не позволяет балансировать типами пользователей и аккаунтами, не даёт проверять функциональность на конкретных аккаунтах или досках.
Выкатить канареечный релиз на определённую выборку пользователей мы можем, только если функционал был написан с Feature Toggle, а это уже реализация через код, а не через релизы.
Hot Fix в канареечном релизе
Раньше, находя ошибку в канареечном релизе, мы блокировали мердж в мастер и весь релиз. Это было неудобно, так как блокировало работу других команд и задерживало время выхода релиза.
Нам хотелось найти подход, при котором мы могли задерживать выход релиза минимально. Мы изучили существующие подходы (Trunk-Based Development, GitFlow и т.д.) и остановились на GitLab Flow.
Как мы работаем с Hot Fix по GitLab Flow:
Отводим релизные ветки от версии из канареечного релиза.
Мерджим фикс в мастер.
Выполняем git cherry-pick в релизной ветке.
Запускаем канареечный релиз на релизной ветке.
Запускаем следующий плановый канареечный релиз на версии мастера с фиксом или выше.
Подход помог нам вдвое снизить максимальное количество дней без релиза и количество перезапусков канареечных релизов, с четырёх до двух.
Предсказуемость и прозрачность процесса релиза
Для повышения качества релиза мы поддерживаем его прозрачность и предсказуемость. Используем для этого автоматические уведомления и дашборды с ключевыми метриками.
Раньше мы публиковали большой changelog один на все команды: в общем канале со всеми изменениями в релизе. Командам было трудно и больно ориентироваться в нём. Поэтому к общему changelog мы добавили командные changelog, в котором каждая команда видит статусы только по своим задачам и версию релиза, в которой они реализованы.
Дашбордами в Grafana мы пользуемся при работе с внеплановым релизами, чтобы быстрее их завалидировать. Во время плановых релизов нам хватает алертов из Grafana на основе метрик из Prometheus.
Всю статистику по релизам из Jira и Bamboo мы собираем и визуализируем в Looker, чтобы на основе исторических данных принимать решения о качестве процессов и улучшать их.
Данные по ошибкам, количество созданных и закрытых задач.
Сейчас мы внедряем фичу, которая позволяет командам блокировать ручные и автоматические релизы, если в мастере есть ошибка. Благодаря ей мы сможем автоматически собирать статистику количества сломанных мастеров, времени фикса и понимать, какие ошибки заблокировали выход релиза.
Изменения, которые увеличили долю успешных релизов
Канареечные релизы помогли сократить количество откатов релизов на 95%.
Отдельные changelog для каждой команды повысили общую прозрачность процесса. Теперь каждая команда вовремя и удобным способом получает уведомления о том, когда выходит их функциональность.
Мониторинг канареечного релиза дежурным серверным разработчиком уменьшил время реакции команды на найденный ошибки.
Подход GitLab Flow для hotfix позволил задерживать выход релиза минимально и исправлять ошибку, не блокируя работу других команд. Автоматические релизы стимулируют команды держать мастер всегда готовым к релизу.
Сбор и анализ всей истории релизов в Looker помогает проверять гипотезы и постоянно улучшать процесс.
Ближайшие планы
Конечная наша цель — выстроить процесс так, чтобы все релизы были успешными и пользователи никогда не сталкивались с ошибками. Для этого мы планируем следующие изменения:
Разбить монолит на микросервисы. Мы начинаем двигаться в эту сторону, но это отдельный большой проект вне темы статьи, поэтому останавливаться здесь на этом не буду.
Увеличить скорость релиза. Сейчас релиз на board-серверах занимает час, релиз на API-серверах — полчаса. Мы хотим быстрее.
Дать командам инструмент для автономного управления релизами. Сейчас есть возможность запустить канареечный релиз для hotfix, но команды не могут воспользоваться GitLab Flow полностью самостоятельно. Например, не могут самостоятельно отвести релизную ветку. У нас по умолчанию включена функция «Branch merging enabled», поэтому ветки при сборке содержит код мастера, а для релизных веток командам нужна помощь со стороны для ручного отключения этой фичи.
Сократить время от момента нахождения ошибки до вывода фикса на канареечный релиз. Сейчас у нас это может занимать до 6 часов рабочего времени в худших случаях из-за сложностей в коммуникациях или процессах.
Управлять нагрузкой на канареечных релизах, чтобы с ростом пользователей мы имели возможность увеличивать скорость прогона релиза, не меняя доли пользователей, участвующих в нём.
Добавить пользовательские метрики в валидацию релиза. Пока используем только технические метрики и метрики с багами.
Буду рада, если в комментариях поделитесь опытом повышения доли успешных релизов, особенно если вы уже реализовали описанные выше задачи.
Ускоряем деплой на продакшен канарейками и самописным мониторингом
Привет, меня зовут Лёша, я работаю в SEMrush в команде SRE, которая занимается обеспечением бесперебойной работы нашего сервиса. Эта история о том, как мы разогнали деплой в 6 раз и сократили затраты на мониторинг в 3 раза. И все это через приручение канареек и самописные инструменты.
Я расскажу, как мы улучшали релизный пайплайн с помощью канареечного деплоя. Так, за пару лет мы прошли путь от «надо бы попробовать» до самописного тулинга.
Надо бы попробовать
До описываемой тут истории наш деплой был устроен вот так:
наш релизный пайплайн до внедрения канареечного деплоя
Есть ветка, в которой ведётся разработка новой фичи. В какой-то момент разработчик решает, что код готов к доставке пользователю. Тогда код заливается на тестовый стенд, прогоняются автоматические тесты, QA и PO делают ревью. Если всё ОК, происходит автоматическая раскатка по продакшн-окружению. Классика.
Вопрос, который мы постоянно задаём себе в команде SRE: «Насколько этот процесс быстрый и надежный?» Также было несколько моментов, которые мы хотели улучшить.
Хотим улучшить: удобство деплоя
В SEMrush тесты пишут команды разработки. В основном тесты нацелены на покрытие фич и бизнес-требований. Тестов много, и уследить за порядком не всегда было просто. Происходили ситуации, когда фича могла быть уже не актуальна, а тесты ещё не удалены.
Были сложности с упавшими тестами. Команд разработки несколько, у каждого теста есть свой владелец. Когда при запуске всего набора тестов что-то падало, приходилось искать владельца теста и выяснять, что могло пойти не так.
Всё это приводило к тому, что решение о мерже и деплое принималось в ручном режиме, а прохождение инкремента по всему релизному пайплайну могло занимать до 60 минут. Мы хотели сделать деплой более удобным для всех.
Хотим улучшить: покрытие тестами
Структурно тестовое окружение такое же, как продакшен, но отличия есть:
Зовём на помощь канарейку
Чтобы побороть эти проблемы, мы решили добавить в пул продакшн-серверов ещё одну ноду. План был такой: будем выкатывать туда бета-сборку с новой фичей и заводить туда часть пользователей, чтобы посмотреть, что всё работает корректно. Так у нас появилась канарейка
концепция канареечного деплоя
Wiki-минутка: на протяжении нескольких веков шахтеры брали с собой под землю канарейку. Птица чувствительна к газам, и если в шахте была утечка, канарейка умирала. Печально, но так шахтёры получали сигнал, что пора эвакуироваться из шахты. Канарейка спасала человеческие жизни.
По задумке канареечный деплой должен был принести с собой важное улучшение: принятие решения о раскатке фичи по продакшену на основе предварительно собранных метрик.
по задумке канареечный пайплайн должен был стать таким
Проводим кастинг на канарейку
Ок, пробуем настроить канареечный деплой. Самый первый вопрос: на ком будем экспериментировать и собирать заветные метрики. Тут навскидку было три варианта.
Первый вариант (решение в лоб) — направить на новую ноду часть реальных пользователей. Не подошло по нескольким причинам. Во-первых, фидбек от пользователей может быть довольно медленным. Нужно будет каждый раз ждать, пока соберётся статистика в достаточном объёме. Во-вторых, у нас в системе есть важные сценарии, которые случаются не так часто. Придётся ждать их появления, чтобы проверить. В-третьих, нам не хотелось портить user experience даже маленькой части пользователей. Отбрасываем вариант.
Второй вариант (отвергнутый) — задействовать наши тесты. Их у нас много. Но тоже не подходит. На продакшн-данных тестировать сложно. К тому же нужно постоянно следить, чтобы в тесты для продакшена не затесались проверки, которые нельзя там запускать. Отбрасываем вариант.
Третий вариант (рабочий) — система мониторинга продакшн-сервисов. Она работает в продакшн-окружении. Всегда актуальна и даёт сигналы, когда что-то сломалось. К ней высокое доверие: дежурные администраторы по сигналу системы мониторинга начинают чинить проблему даже ночью. Берём этот вариант.
Может получиться быстро и надёжно, идём проверять.
Proof of Concept
В качестве системы мониторинга на роль канарейки мы взяли Pingdom, которым тогда пользовались. Сработало! Канареечная концепция реализуется, ничего не ломается. Но вопросы остались.
Канарейка VS тесты VS мониторинг
С приходом канарейки наш деплойный пайплайн стал выглядеть так:
релизный пайплайн после внедрения канареечного деплоя
Для каждого окружения мы имели свой набор инструментов. Каждый нужно поддерживать, при этом все они работают по-разному. Неудобно по нескольким причинам.
Случалась проблема «ненастоящего» браузера. Pingdom использует эмуляции, которые могут отличаться от реального браузера.
Такую картину можно было наблюдать даже для в ситуациях, когда у пользователей все работало исправно.
Ещё была проблема с рассинхроном тестов и мониторинга. В команде SRE мы в первую очередь доверяем мониторингу. Ребята из QA ориентируются на тесты. Получается следующее: соответствующие инструменты в каждом окружении работают по-разному и непонятно, за кем последнее слово.
А ещё было тяжело дебажить упавшие тесты. Pingdom – внешний инструмент. Оттуда можно достать ограниченную информацию об инцидентах. Этого не всегда хватало, чтобы разобраться в проблеме. На запросы разработчиков часто приходилось разводить руками.
Чтобы победить эти проблемы, мы решили сделать свой инструмент.
Introducing SEMrush PURR
Нам нужен реальный браузер, единые сценарии тестов и мониторинга, удобный дебаг. Для интеграции с нашим GitLab CI мы хотели иметь возможность запуска из CLI. И, раз такое дело, заодно и возможность запуска по расписанию. Такими были требования к новому инструменту.
Решение: мы взяли Puppeteer, сделали обвязку из NodeJS, добавили Redis для очередей. Инструмент назвали SEMrush PURR (от Puppeteer Runner).
Puppeteer – инструмент от Google; делает та же команда, что Chrome. Это реализация DevTools Protocol для той консоли Chrome, которой мы пользуемся каждый день. На тот момент поддерживались Chrome, Firefox (beta), Edge (alpha).
Puppeteer помог нам решить проблему «ненастоящего» браузера. Запуск из CLI дал возможность встроить запуск SEMrush PURR в пайплайн GitLab CI.
запуск SEMrush PURR – финальный шаг пайплайна; если PURR падает, выкладки не происходит
Для удобства дебага мы получили возможность делать скриншоты, записывать видео, собирать логи и трейсы. Если проверка упала, можно увидеть картинку прямо в GitLab и посмотреть, что случилось.
дебажим упавшие тесты
Единые сценарии тестов и мониторинга стали описываться в YAML-файле.
YAML-файл со сценариями тестов и мониторинга
Там можно указывать разные параметры (например, домен, который мы тестируем). Тут на скриншоте указано, что работаем с куками и авторизацией.
Для работы по расписанию запускаем наше NodeJS-приложение в Kubernetes. Настраиваем расписание проверки с помощью Redis (библиотека Bull). Результаты проверок отгружаем в Prometheus. Оттуда забираем алерты, если что-то упало.
Варианты запуска по расписанию не ограничиваются только этим стеком. Можно использовать хоть cron, хоть Google Cloud Functions, хоть AWS Lambda. Или захостить у себя на виртуалке.
Унификация пайплайна с SEMrush PURR
В итоге SEMrush PURR дал нам заветное: один и тот же инструмент и сценарии для всех трёх окружений.
релизный пайплайн после внедрения SEMrush PURR
Главный результат внедрения SEMrush PURR – сократилось количество post-deploy инцидентов, когда на продакшене оказался код с ошибками.
С канарейкой, но без ограничений Pingdom, время доставки фичи на продакшен снизилось с 60 до 10 минут. Не нужно ждать, пока освободится тестовый стенд; не нужно ходить в другие команды узнавать, что с их тестами.
Отдельный позитивный момент работы с SEMrush PURR для нас лично то, что конфигурацией проверок занимается наша команда. Так что мы имеем возможность делать частью проверок те вещи, которые важны для продакшн-системы, на наш взгляд.
Дружите с канарейками
Канареечный деплой помог нам улучшить релизный пайплайн. Хочется верить, что со временем эта практика может стать индустриальным стандартом, как когда-то тесты в целом. Хочется, чтобы больше людей и компаний имели доступ к пользе от канарейки.
Если вы уже пользуетесь канареечным деплоем (или вот-вот начнёте), обратите внимание на Puppeteer. Он помог нам получить окружение для мониторинга, близкое к настоящему браузеру пользователя.
Если будете подбирать тулинг, посмотрите на SEMrush PURR. Он доступен на GitHub. Будем рады, если наш инструмент поможет вам сделать канареечный деплой удобнее.