Релиз заканчивается проверкой пользовательского действия
Успешная сборка Next.js подтверждает только прохождение определённого этапа. Она не доказывает, что новый процесс получил нужную конфигурацию, авторизация работает через публичный домен, а заявка сохраняется в правильную базу. Релиз стоит описывать последовательностью решений: подготовить, собрать, испытать, разрешить переключение, проверить результат. У каждого решения должны быть свидетельство и ответственный.
Заранее определите признаки остановки: недоступен вход, растут серверные ошибки, не проходит ключевой сценарий, теряются обращения. Согласуйте допустимое окно наблюдения и того, кто принимает решение об откате. В момент сбоя неудобно обсуждать полномочия и искать прежнюю сборку. Готовый порядок действий сокращает неопределённость, но сам по себе не обещает отсутствие простоя.
Подготовка: изолированный кандидат и известное окружение
Выделите каждому релизу отдельный каталог или неизменяемый образ, идентификатор и описание изменений. Запишите версии Node.js, Next.js, зависимостей, способ запуска и необходимые переменные. Не собирайте новый вариант поверх работающей директории: оператор должен однозначно понимать, какой комплект сейчас обслуживает посетителей. Предыдущий комплект сохраняйте до завершения наблюдения и решения о хранении.
Разделяйте параметры сборки и исполнения. Согласно руководству Next.js по самостоятельному размещению, значения NEXT_PUBLIC_ встраиваются в браузерный JavaScript при сборке. Изменение окружения уже запущенного процесса не перепишет этот код. В манифесте достаточно имён и назначения переменных; секретные значения не должны попадать в отчёт о релизе.
Сборка и испытания до переключения
Используйте зафиксированные зависимости, выполните предусмотренные проектом проверки типов, линтер и тесты, затем production-сборку. Команды сверяйте с установленной версией и скриптами проекта. Production checklist Next.js рекомендует проверять производственный режим до выпуска. Результат dev-сервера не заменяет испытание того артефакта, который будет опубликован.
Запустите кандидата на отдельном локальном порту или закрытом стенде. Проверьте не только главную, но и динамическую страницу, статические ресурсы, вход и запись тестового объекта. Изолируйте письма, платежи, фоновые задачи и другие внешние действия. Если тест использует копию данных, убедитесь, что её параметры не позволяют случайно обратиться к рабочим интеграциям.
Healthcheck должен отвечать на конкретный вопрос. Проверка жизни процесса и готовность обслуживать запросы различаются: открытый порт не подтверждает доступность необходимых зависимостей. Продумайте безопасную проверку готовности с короткими таймаутами и без изменения пользовательских данных. Не возвращайте наружу строки подключения, внутренние исключения и другие подробности инфраструктуры.
Совместимость миграций определяет возможность отката
Перед изменением схемы или данных сделайте либо проверьте резервную копию и возможность восстановления. Затем отдельно проверьте совместимость старого приложения с новой схемой. Архив базы не превращает удаление столбца в безопасное действие: восстановление старого состояния может потерять записи, поступившие после переключения. План возврата приложения и план восстановления данных решают разные задачи.
Практичный вариант для согласованного проекта: сначала добавить совместимые поля, затем выпустить код, поддерживающий переходное состояние, перенести данные и только отдельным выпуском убрать старую структуру. Конкретный порядок зависит от схемы и нагрузки. Проверяйте обе версии на переходных данных. Необратимое преобразование должно явно ограничивать откат, а не прятаться за общей кнопкой возврата.
Переключение и ограничения PM2
При одном процессе PM2 в режиме fork перезапуск нельзя называть zero-downtime: остановка и запуск могут создать перерыв. Документация PM2 о cluster mode описывает reload в контексте кластера и предупреждает о возможном переходе к обычному restart при таймауте. Само наличие команды reload не доказывает бесшовность вашей схемы.
Если выбран параллельный запуск старой и новой версий, заранее проверьте маршрутизацию, завершение текущих запросов, сессии и обработчики фоновых задач. Не допускайте двойного исполнения заданий. Для Next.js отдельно важны открытые до переключения вкладки: старый клиент может запросить ресурсы или серверное действие прежней сборки. Стратегию совместимости проверяйте на используемой версии фреймворка.
Чек-лист переключения и возврата
- Сверьте идентификатор кандидата, результаты тестов, копию данных и адрес предыдущего релиза. Убедитесь, что решение о публикации действительно относится к этой сборке.
- Проверьте готовность кандидата и только затем выполните согласованное переключение. Сохраните время операции и фактическую конфигурацию маршрутизации без секретов.
- Через публичный адрес откройте страницу, войдите тестовой учётной записью и выполните контрольное действие. Подтвердите результат в целевой системе, а не только уведомление интерфейса.
- При выполнении условия отката верните трафик на совместимый прежний релиз. Если совместимости нет, остановитесь на заранее согласованном сценарии восстановления или исправления.
- После возврата повторите проверки, оцените новые записи и фоновые задания. Зафиксируйте фактический перерыв и причину сбоя для следующего испытания.
Критерии приёмки
Нужны проверенный артефакт, рабочие публичные сценарии, наблюдение за ошибками и испытанная процедура возврата на стенде. Измеренное время отката относится к условиям испытания, а не гарантирует одинаковый результат любой аварии. Общую схему окружений дополняет материал о CI/CD, а связанный разбор портфолио посвящён поэтапному релизу Yabeard. Такие проверки входят в план DevOps и инфраструктуры.
Короткий FAQ
Достаточно ли статуса online в PM2?
Нет. Это состояние процесса, а не доказательство корректного входа, чтения и записи через рабочий адрес.
Откат приложения всегда возвращает данные?
Нет. Данные живут отдельно. Их восстановление требует собственного решения с учётом новых записей и совместимости схемы.
Нужен ли кластер каждому небольшому сайту?
Нет. Архитектуру выбирают по требованиям доступности и ресурсам. Для одного процесса честно согласуйте возможный перерыв.