Как не сломать прод: что нужно проверить перед релизом

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

• общие проверки,
• проверки перед запуском нового продукта,
• проверки перед релизом обновлений.

Перед релизом проверь, какие изменения попадут в основную ветку и не затронут ли они существующие функции. Убедись, что:

• код прошёл проверку коллегой, если это предусмотрено процессом;
• линтеры и другие обязательные проверки не выявили ошибок;
• в релиз не попали незаконченные функции, отладочный код и лишние файлы;
• в репозитории нет паролей, токенов и других секретов.
• Например, разработчик меняет расчёт стоимости заказа и случайно добавляет изменение, из-за которого скидка применяется дважды. Просмотр изменений помогает заметить проблему до выкладки.

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

В большинстве команд проверки перед релизом частично автоматизированы с помощью CI/CD (Continuous Integration / Continuous Delivery или Deployment). При отправке изменений в репозиторий или создании pull request CI-пайплайн может автоматически:

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

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

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

Проверь не только новую функцию, но и существующие сценарии: не сломались ли они после изменений?
В зависимости от проекта запускают:

• Модульные тесты — проверяют отдельные функции и компоненты.
• Интеграционные тесты — проверяют взаимодействие частей системы, например приложения и базы данных.
• Сквозные тесты (E2E) — проверяют полный сценарий, например регистрацию или оформление заказа.

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

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

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

Объём проверок зависит от изменений: необязательно повторно тестировать все интеграции, если релиз их не затрагивает.

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

Например, пользователь может изменить идентификатор заказа в URL и увидеть заказ другого человека, если сервер проверяет только факт входа, но не право доступа к конкретному заказу.

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

Перед релизом определи порядок выкладки и ответственных за неё. Команда должна понимать, как проверить результат, остановить выпуск при проблемах и вернуть предыдущую версию, если это потребуется.

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

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

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

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

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

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

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

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

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

Проверь не только новую функцию, но и существующие сценарии: не сломались ли они после изменений? Запусти автоматические регрессионные тесты и отдельно проверь критичные пользовательские сценарии.

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

• выросла доля HTTP 5xx,
• перестал работать вход в аккаунт,
• увеличилось время ответа критичных API,
• появились ошибки миграции или потери данных,
• перестали обрабатываться платежи или другие критичные операции.

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

До релиза определи, как вернуться к предыдущей версии приложения, если обновление вызовет проблемы. Учитывай, что откат кода не отменяет изменения в базе данных автоматически. Заранее продумай, как восстановить совместимость или вернуть данные в рабочее состояние.

После релиза нужно быстро обнаружить ошибки. Для этого используют:

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

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

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

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

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

1. Оцени масштаб: какие функции затронуты и есть ли риск потери данных.
2. Сообщи команде, если ты работаешь не один: следуй принятому процессу реагирования на инциденты.
3. Восстанови работу: при необходимости останови выкладку или выполни откат.
4. Найди причину: изучи логи, метрики и изменения в коде.
5. Предотврати повторение: добавь тест или проверку, которая поможет обнаружить такую проблему раньше.

При серьёзном сбое в приоритете — восстановить работоспособность системы, а затем разобраться в причинах.