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