Привет! Я Александра Невзорова, QA в команде оформлений. Моя команда занимается процессингом оформления кандидатов во всю группу компаний. Поделюсь докладом моей коллеги — Марии Палагиной из команды разработки веб-платформ об автоматических релизах. 

Автоматические релизы — не просто модное словосочетание. Это мощный инструмент, который может кардинально изменить подход команды к выпуску новых версий продукта. 

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

Что такое релиз

Релиз — это не просто выпуск новой версии. Это сложный процесс, который обычно состоит из следующих этапов:

• Сборка артефакта — создание исполняемого файла или пакета для развертывания.

• Проверка артефакта — тестирование собранного артефакта на соответствие требованиям.

• Доставка — размещение артефакта в целевой среде.

• Оповещение — информирование команды разработки и пользователей о выходе новой версии.

• Мониторинг — отслеживание работы новой версии в продакшене.

• Откат — возможность вернуться к предыдущей версии при возникновении проблем.

Как показывает практика, понятие «автоматический релиз» может восприниматься по-разному в зависимости от роли участника процесса.

Что такое автоматические релизы 

Когда мы говорим об автоматических релизах, чаще всего подразумеваем автоматизацию процессов выкатки новой версии приложения в production. В современном ИТ-мире эта выкатка практически всегда происходит с помощью инструментов CI/CD — мы ведь не переносим файлы вручную, верно?

Три компонента CI/CD:

• Continuous Integration (CI) — непрерывная интеграция кода, включающая тестирование и мерж изменений.

• Continuous Delivery (CD) — поддержание мастера в состоянии, готовом к выпуску.

• Continuous Deployment — автоматическое развертывание изменений на тестовых и продакшен-средах.

Получается, автоматические релизы уже внедрены во многих компаниях? Но почему, говоря о своей команде, большинство все еще использует фразу «Мы релизим вручную»?

Рассмотрим, как разные роли могут понимать термин «автоматический релиз»:

Инженеры. Для инженеров автоматические релизы — часть CI/CD. Но восприятие может различаться в зависимости от специализации. 

SRE-инженеры фокусируются на Continuous Deployment и методах безопасного деплоя:

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

• Blue/Green Deployment — существуют две независимые среды: «Синяя» (активная версия) и «Зеленая» (новая версия). Трафик постепенно перенаправляется в «Зеленую» среду для оценки стабильности, а затем полностью переключается на нее.

• Rolling Update — поэтапная раскатка новой версии с минимальными перебоями в работе системы.

SRE-инженеры сосредотачиваются на настройке и поддержке инфраструктуры.

Для QA-инженеров авторелизы — стабильность и надежность продукта. Это переход от рутинных проверок к стратегическому управлению качеством, где ключевую роль играет автоматизация тестирования в рамках пайплайнов. Она сокращает время на регрессионное тестирование, позволяя QA-инженерам сосредоточиться на улучшении процессов, анализе метрик и тестировании сложных сценариев.

Разработчики воспринимают авторелиз как возможность не отвлекаться от написания кода на рутинные задачи: сборку, подготовку версии, подготовку окружения и тому подобное. В идеале релиз становится «невидимым» для разработчика, позволяя ему полностью сосредоточиться на коде и его качестве.

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

Технически подкованные менеджеры (тимлиды, delivery-менеджеры) ценят в автоматизации:

• экономию времени — команда не тратит ресурсы на рутинные задачи;

• снижение человеческого фактора — автоматизация уменьшает вероятность ошибок;

• повышение качества — за счет регулярного тестирования и мониторинга.

Когда мы говорим про авторелизы, понимаем, что это комплексный подход, в котором с одной стороны — процессы CI/CD, а с другой — все те бонусы, которые можно с такого выстроенного процесса получить.

Подходы к построению релизного процесса

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

Автоматические релизы: короткие пайплайны. Классический TBD-подход: каждое изменение, прошедшее тестирование и аппрув, автоматически выкатывается в прод. Подходит для команд, которые работают с маленькими MR (merge request), используют fast-forward для поддержания чистоты мастера или имеют высокое покрытие автотестами.

В пайплайне есть:

• install — сборка артефакта;

• publish — публикация собранного артефакта в среде;

• rollback — возможность откатить релиз;

• finalize — уведомление команды о совершенном релизе, запись релизных логов и т. п. 

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

Релизы по расписанию. Автоматизация есть, но финальный релиз происходит не сразу, а по заданному расписанию. Например, раз в день или раз в неделю. Релизы по расписанию позволяют:

• снизить нагрузку на систему;

• сгруппировать изменения;

• провести финальную проверку перед выкаткой.

В пайплайне не было публикации в прод (неактивен стейдж publish). В примере в самом начале пайплайна не получилось правильно проставить релизное имя (но важно не конкретно имя, а наличие ошибки в любом месте пайплайна). Если бы в процессе выполнения пайплайна ошибок не возникло, публикация на прод произошла бы в указанное время. 

Полуавтоматический формат, когда все этапы автоматизированы, но финальный шаг (публикация в прод) выполняется вручную. Такой формат позволяет добавить человеческий контроль перед выкаткой и учитывать внешние факторы: нагрузку на систему, важные события и так далее.

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

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

Преимущества и недостатки авторелизов

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

Частые релизы могут аффектить систему. Необходимо учитывать влияние частых релизов на ее производительность и стабильность:

• перетирание кэша;

• возникновение проблем во время пиковой нагрузки;

• из-за большого числа джоб в пайплайне — нагрузка на ранеры;

• проблемы неконсистентности в приложении — например, неконсистентность интерфейса, если в одном из маленьких релизов обновились не все кнопки; 

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

Кроме этого, существуют некоторые риски и сложности реализации, которые могут не возникать при ручных релизах:

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

• Дополнительные процессы, например автооткаты — при частых релизах увеличивается вероятность необходимости отката.

• Автоматизация метрик и мониторинга, чтобы определить по метрикам, что что-то идет не так.

• Широкое покрытие автотестами. При частых релизах нужны частые регрессы: при преимущественно ручных регресс-тестированиях увеличится нагрузка на команду.

Несмотря на недостатки, авторелизы имеют и множество преимуществ:

• Мотивация на тестирование внутри MRa: в условиях, когда мастер автоматически попадает на прод, возрастает мотивация протестировать изменения внутри MR-ов. Также автоматизация релизов требует надежного покрытия автотестами.

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

• Снижение когнитивной нагрузки — команда фокусируется на важных задачах, так как проверки и действия для релиза уже вшиты в пайплайн и не требуют ручной работы.

• Ускорение TTM (Time To Market) — быстрее выкатываем фичи, нет простоя между разработкой и релизом.

• Уменьшение человеческого фактора — меньше ручных действий. 

• Гибкость времени релизов — можно настроить запуск релизного пайплайна в нерабочее время.

• Как приятный побочный эффект — улучшение качества благодаря регулярному тестированию и мониторингу.

Выводы

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

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

Главное, не зацикливаться на поиске идеального процесса, а строить релизы, которые подходят продукту, осознанно оценивая пользу и риски автоматизации.

А вы уже внедряли авторелизы в своих командах? Возможно, вы заметили еще какие-то плюсы и минусы этого процесса. Предлагаю обсудить в комментариях!