Сохраните рабочую версию сайта и проверьте, как вернуть её на сервер, прежде чем публиковать правки Claude Code. Для отката понадобятся исходный код, предыдущая сборка и понятная инструкция для того, кто выпускает обновление. Если правки затрагивают базу данных, нужен отдельный план её восстановления. Ниже разберём, что сохранить, как проверить возврат на тестовой копии и какие ограничения задать ИИ, чтобы после неудачного обновления вернуть рабочий сайт без новых изменений наугад.
Что сохранить перед обновлением сайта?
Начните с версии, которая сейчас работает у посетителей. Откройте сайт и пройдите основной путь клиента: от страницы услуги до отправки тестовой заявки. Если форма уже выдаёт ошибку, сохранение текущего состояния закрепит и эту ошибку. Запишите результат проверки рядом с названием версии.
Git хранит историю исходного кода, но обычно не охватывает весь сайт на сервере. Изображения из панели управления, настройки окружения и база данных могут находиться отдельно. Поэтому отметка в Git сама по себе ещё не означает, что сайт получится восстановить целиком.
- Зафиксируйте исходный код в Git. Сохраните идентификатор коммита, то есть конкретной версии, которая соответствует рабочему сайту.
- Сохраните предыдущую сборку. Это файлы, которые сервер отдаёт посетителям после подготовки проекта к публикации.
- Уточните, где находятся настройки окружения и как вернуть их прежние значения. Секретные ключи не добавляйте в репозиторий с кодом.
- Проверьте резервную копию базы и файлов, которые меняются через панель управления. Уточните, что именно в неё входит.
- Запишите способ возврата и имя ответственного. Например: выбрать предыдущий выпуск в панели размещения и проверить форму заявки.
Условное название «до правок каталога» понятнее, чем «последняя нормальная версия». Но одного названия мало: рядом нужен идентификатор версии или путь к архиву. Тогда другой разработчик сможет найти нужные файлы без переписки с автором обновления.
Как проверить откат до публикации?
Попросите разработчика развернуть сохранённую версию на тестовой копии сайта. Такая копия нужна для проверки без изменений на рабочем адресе. Сам факт, что архив скачивается и открывается, ещё не подтверждает, что из него запускается сайт.
Для сайта услуг проверьте страницу услуги и отправку тестовой заявки. Для каталога добавьте открытие карточки товара и переход между разделами. Выберите действия, через которые бизнес получает обращения, и запишите ожидаемый результат каждого: форма показывает подтверждение, а заявка появляется там, где её обрабатывают.
- Восстановите сохранённый выпуск на тестовой копии.
- Проверьте основной путь клиента по заранее составленному списку.
- Опубликуйте правки Claude Code только на этой копии.
- Верните предыдущий выпуск тем способом, который планируете использовать на рабочем сайте.
- Повторите проверку пути клиента после возврата.
Если проверка прошла, у вас уже есть подтверждение, что конкретный способ отката работает на тестовой копии. Запишите отличия от рабочего сервера: настройки, версии программ или способ публикации. Каждое такое отличие требует отдельной проверки перед выпуском.
Если на хостинге есть кнопка возврата к предыдущему выпуску, уточните её границы. Она может переключать только файлы приложения, оставляя базу и загруженные изображения без изменений. Попросите разработчика прямо написать, что эта кнопка возвращает, а чего не касается.
Как задать Claude Code правила безопасного выпуска?
Поручите Claude Code сначала составить план изменений. В запросе отделите подготовку от публикации: агент изучает проект, перечисляет затронутые части и ждёт согласования. Доступ к рабочему серверу выдавайте только для согласованной операции, если он вообще нужен для задачи.
Такое разделение есть в наборе скиллов Magerko: процесс удерживает агента от реализации, пока команда обсуждает задачу. Проверку результата автор набора поручает отдельному субагенту со свежим контекстом, который запускает проверки по критериям приёмки (GitHub, Magerko/claude-code-skills).
Для своего проекта можно закрепить похожий порядок в инструкции CLAUDE.md и отдельном скилле выпуска. Скилл здесь — набор повторяемых инструкций для определённой задачи. Практический способ оформить его разобран в статье «Как превратить чек-лист сайта в скилл Claude Code».
Дайте агенту такое задание: «Подготовь план обновления сайта. Укажи текущую рабочую версию, что нужно сохранить и как выполнить откат. Отдельно отметь изменения базы данных. Не публикуй правки и не запускай команды, которые удаляют или перезаписывают данные. Дождись моего подтверждения плана».
После согласования попросите отчёт о проверке: какое действие агент выполнил, какой результат ожидал и что получил. Фраза «ошибок не найдено» без перечня проверок не подтверждает работу формы. Нужен результат конкретного теста, например появление тестовой заявки в панели.
Как вернуть рабочую версию, если обновление сломало сайт?
Остановите следующие публикации и зафиксируйте проблему: адрес страницы, действие и текст ошибки. Не просите Claude Code сразу «починить всё на сервере». Новые правки затруднят поиск причины и добавят ещё одну версию, которую никто не проверял.
Перед возвратом убедитесь, что выбран нужный выпуск. Если операция перезапишет файлы или базу, сначала сохраните текущее состояние и подтвердите, что именно разрешено заменить. Особенно внимательно отнеситесь к базе: после обновления в ней могли появиться новые заказы или измениться остатки товаров.
- Определите последний выпуск, на котором основной путь клиента проходил проверку.
- Проверьте, совместим ли прежний код с текущей структурой базы.
- Верните выпуск по инструкции, которую проверяли на тестовой копии.
- Пройдите основной путь клиента на рабочем сайте.
- Сохраните описание сбоя для разбора на тестовой копии.
Если обновление изменило структуру базы, возврата файлов может оказаться недостаточно. Например, прежний код ожидает поле, которое новая версия удалила. В такой ситуации разработчик сначала выбирает способ восстановить совместимость и сохранить новые записи. Восстанавливать старую копию базы поверх текущей без проверки нельзя: записи после момента копирования будут потеряны.
Когда за выпуск отвечает подрядчик, включите проверку отката в условия приёмки. Результат работы понятен: разработчик передаёт рабочую версию, инструкцию возврата и отчёт о тестовом восстановлении. Это отдельная задача по подготовке сайта к эксплуатации, которую стоит согласовать до публикации.
Типичные ошибки при подготовке отката
- Сохранить только исходный код. Исправление: отдельно перечислить сборку, настройки и содержимое, которое меняется вне Git.
- Проверить только главную страницу. Исправление: пройти путь до заявки или другого целевого действия и увидеть результат в системе.
- Оставить резервную копию на том же сервере без другого экземпляра. Исправление: сохранить доступную копию отдельно и проверить, кто сможет её получить.
- Разрешить агенту автоматически восстанавливать базу при любой ошибке. Исправление: требовать отдельного подтверждения с описанием того, какие записи будут заменены.
- Считать сообщение Claude Code доказательством готовности. Исправление: запросить результаты конкретных проверок и самостоятельно пройти основной путь клиента.
Сейчас откройте задачу на ближайшее обновление и добавьте строку: «До публикации указать рабочую версию и показать проверенный способ её возврата». Это займёт меньше двух минут.
