Staging — промежуточная копия сайта для проверки релиза до production. Её назначение — обнаружить ошибки без риска для реальных пользователей и данных. Нельзя считать staging безопасным, если он доступен всем по ссылке, содержит настоящие персональные данные или отправляет реальные платежи.
1. Разделите среды и доступы
Проверьте, что локальная, staging- и production-среды используют разные адреса, учётные данные и секреты. На staging применяйте тестовые ключи платежей и почты, а отправку писем и уведомлений в реальные каналы отключайте или переводите в sandbox-режим.
Ограничьте доступ к staging авторизацией на уровне сервера или другой адекватной защитой. Директива noindex полезна для поисковиков, но не является защитой доступа. Убедитесь, что canonical staging-страниц не указывает на случайные временные URL.
2. Сделайте резервную копию и план восстановления
Перед выпуском нужен проверяемый бэкап базы и необходимых файлов. Запишите, кто делает восстановление, сколько времени оно может занять и какие изменения данных будут потеряны. Не объявляйте бэкап рабочим, если никто не проверял возможность извлечь данные.
3. Проверьте критические сценарии
Возьмите проверки из UX-SPEC и тестирования прототипа. Для WordPress отдельно проверьте логин/выход, права гостя и авторизованного, формы, сохранение и удаление данных, загрузку файлов, email, резервные копии и ошибки при недоступном API.
Если используете WooCommerce, проверьте тестовые платежи и границу sandbox/production, не создавая реальных списаний. Убедитесь, что события аналитики не отправляются повторно от одного действия.
4. Проверьте SEO и интерфейс
Перепроверьте H1, canonical, robots.txt, sitemap и 301-редиректы в production-конфигурации. Не переносите staging noindex в боевой сайт. Проверьте мобильные формы и клавиатуру, затем запустите Lighthouse для поиска типовых проблем. Автоматический аудит не заменяет ручного тестирования.
5. Выпустите и понаблюдайте
Назначьте время релиза, владельца, порядок выкладки файлов/миграций, точки проверки и условия отката. Сразу после выпуска повторите самые важные сценарии на production с безопасными тестовыми данными. Проверьте серверные ошибки, почту и цели аналитики. При существенном сбое остановите изменения и следуйте плану восстановления.
Шаблон 11-DEPLOY.md
## RELEASE-CHECKLIST
- Версия и список изменений:
- Различия окружений и секретов:
- Бэкап и пробное восстановление:
- Миграции и обратная совместимость:
- Тесты функциональности:
- Проверки безопасности:
- Проверки SEO и мобильного UX:
- Ответственный и время релиза:
- Smoke test после релиза:
- План и условия отката:Когда шаг завершён
Релиз имеет конкретный набор проверок и ответственного; стейджинг не доступен публично без контроля, секреты разделены, восстановление спланировано. Только после этого переходите к запуску гипотезы и сбору реальных данных по заранее согласованному плану, если все необходимые предпосылки выполнены.
Источник: https://developer.wordpress.org/plugins/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.