Исправление проверили на компьютере разработчика, затем несколько файлов скопировали на сервер. Сайт открылся, но через час выяснилось, что форма перестала отправлять заявки. Причиной мог стать пропущенный файл, другая версия PHP или изменение базы, которого не было на тестовой площадке.
Порядок публикации нужен не только крупным проектам. Даже небольшой сайт выигрывает, если известно, какая версия размещена, что входит в изменение и как проверить результат. Автоматизация может появиться позже; сначала процедуру стоит сделать понятной и воспроизводимой вручную.
Определите состав версии
В систему контроля версий обычно включают собственный код, шаблоны, стили и инструкции по настройке. Пользовательские загрузки, рабочая база, секреты и журналы имеют другой жизненный цикл. Их нельзя случайно заменить содержимым компьютера разработчика вместе с новой темой.
Для WordPress отдельно определите порядок работы с ядром, плагинами, темой и настройками. Часть изменений редактора хранится в базе, а не в файлах. Нужно заранее знать, как она попадёт на рабочий сайт. Формулировка «залить новую версию» слишком общая, если участники вкладывают в неё разный состав.
Зафиксируйте идентификатор версии и перечень связанных задач. Это позволит связать ошибку с конкретным изменением и сравнить рабочие файлы с подготовленным комплектом. Не редактируйте код на рабочем сервере как обычный способ разработки: такие правки легко забыть и затереть следующей публикацией.
Приблизьте тестовую среду к рабочей
Сверьте версию PHP, расширения, веб-сервер, СУБД и настройки приложения. Полное совпадение размеров инфраструктуры требуется не всегда, но различия, влияющие на изменение, должны быть известны. Проверка на другой версии PHP может не обнаружить ошибку, которая проявится после переноса.
На тестовой копии отключите боевые платежи, рассылки и обмены, ограничьте доступ и индексацию. Используйте обезличенные данные там, где возможно. Порядок подготовки описан в статье о тестовой копии сайта. Её состояние тоже нужно обновлять: давно забытый стенд перестаёт быть полезной проверкой.
Составьте проверку под конкретное изменение
Для новой формы проверьте успешную отправку, ошибки полей и получение обращения. Для каталога — фильтры, карточку, корзину и оформление. Для общего шаблона — несколько разных страниц и мобильный экран. Набор должен соответствовать затронутой функции, а не состоять только из открытия главной.
Проверьте работу без административной авторизации: кеширование и права посетителя могут отличаться. Посмотрите журнал ошибок и сетевые запросы при выполнении сценария. Для серьёзных изменений полезна проверка вторым человеком, который понимает ожидаемый результат и не знает внутреннего устройства исправления.
Подготовьте рабочий сайт к переключению
До переноса проверьте пригодность резервной копии и доступ к восстановлению. Уточните, затрагивается ли база. Обновление плагина может изменить её структуру, даже если публикация выглядит как замена файлов. Возврат старого кода не обязательно отменит такую миграцию.
Выберите время с учётом нагрузки и присутствия ответственных. Если нужен перерыв, согласуйте его и способ работы с внешними уведомлениями. Не оставляйте публикацию на момент, когда исполнитель уже не сможет наблюдать результат. Пользовательские данные за время работ должны сохраняться по заранее определённому порядку.
Переносите согласованный комплект
Избегайте ситуации, когда посетители некоторое время получают смесь старых и новых взаимозависимых файлов. Способ переключения зависит от хостинга и приложения: отдельный каталог версии, короткое окно обслуживания или другой поддерживаемый механизм. Важно понимать, что увидит запрос в середине операции.
Изменения базы выполняют отдельно и контролируемо. После переключения при необходимости обновляют кеш приложения и проверяют фоновые процессы. Массовая очистка всего подряд не заменяет понимание того, какие данные устарели. Безопасному разделению кода и данных посвящена статья об обновлении без затирания базы и загрузок.
Проверьте рабочий результат и сохраните запись
Повторите согласованные сценарии на публичном сайте, проверьте новые ошибки и поступление заявок. Не отправляйте реальные платежи без подготовленного порядка проверки. Для фоновых задач результат может проявиться позже, поэтому наблюдение должно охватить их следующий цикл.
Запишите размещённую версию, время, результаты проверок и известные ограничения. Если возникает нарушение, сравните его с заранее определёнными условиями возврата. Откат должен учитывать новую запись в базу; общий порядок разобран в отдельном материале.
Отдельно договоритесь о срочных исправлениях. Даже небольшой аварийный патч должен получить запись в основной версии кода после восстановления работы. Иначе следующая плановая публикация вернёт старую ошибку. Если обычную проверку пришлось сократить, запишите, какие сценарии остались непроверенными и когда их выполнят. Это позволяет закончить работу осознанно, не превращая временное исключение в новый постоянный порядок размещения изменений на сайте.
Закройте временные доступы, выданные для размещения, если они больше не нужны. Проверьте, что опубликованный комплект и инструкция остались доступны владельцу, а не только на компьютере исполнителя. Это завершает передачу результата после технической проверки.
Если изменения сайта публикуются каждый раз по-разному, напишите в HOMEWEB. Помогу организовать понятную процедуру для вашего WordPress или PHP-проекта и подобрать проверки важных функций.
