Выкладка правок на живой сайт — момент повышенного риска. Между «у меня локально всё работало» и «на сайте белый экран» обычно лежит один забытый файл, одна несовместимая настройка или одна миграция базы, которую применили не в том порядке.
Несколько простых практик сводят этот риск почти к нулю, и для этого не нужна сложная инфраструктура. Ниже — порядок, которым мы пользуемся на проектах поддержки: от системы версий и тестового контура до чек-листа после выкладки и разбора типичных ошибок.
Базовый порядок
Каркас, к которому сводится всё остальное, выглядит одинаково и для крупного портала, и для корпоративного сайта на шаред-хостинге.
- Изменения хранятся в системе версий, а не копируются файлами по FTP.
- Сначала проверка на тестовой копии, максимально похожей на боевую.
- Резервная копия базы и файлов снимается до выкладки, а не после.
- Выкладка выполняется скриптом или командой, а не руками по одному файлу.
- Ключевые страницы и формы проверяются сразу после, по короткому списку.
- Есть заранее известный способ откатиться, и он опробован не в момент аварии.
Каждый пункт по отдельности выглядит очевидным. Проблемы начинаются там, где один из них выпадает: чаще всего это тестовый контур и резервная копия.
Система версий и тестовый контур
Система версий решает две задачи. Первая — всегда известно, что именно изменилось и кем; при разборе поломки это экономит основное время. Вторая — становится возможен откат: не «вспомнить, какие файлы правили», а вернуть предыдущее состояние целиком.
Тестовый контур должен быть похож на боевой не по духу, а по составу: та же версия языка и базы, те же расширения, те же настройки веб-сервера, те же права на файлы. Тестовая копия на другой версии окружения проверяет не то, что поедет в бой, и создаёт ложное спокойствие.
- Отдельный домен или поддомен, закрытый от индексации и от посторонних.
- Свежая копия боевой базы, обезличенная, если в ней есть персональные данные.
- Отключённые внешние интеграции и почтовые рассылки, чтобы тест не писал реальным клиентам.
- Тот же набор конфигураций, но со своими ключами доступа, а не боевыми.
Резервные копии и быстрый откат
Резервная копия ценна только тогда, когда её пробовали разворачивать. Мы видели проекты, где копии исправно снимались год, а при первой же аварии выяснялось, что архив базы пуст или содержит одну таблицу из тридцати. Проверка восстановления — отдельная процедура, её стоит делать по расписанию.
Копия снимается непосредственно перед выкладкой, отдельно файлы и отдельно база, и лежит там, откуда её можно достать при недоступном сайте. Хранить единственную копию на том же сервере, который может лечь, смысла мало.
Откат должен занимать минуты. Если возврат к прошлой версии — это ручное восстановление из архива на полчаса, команда будет чинить на живом сайте вместо отката, а это ровно тот сценарий, которого мы избегаем.
Выкладка скриптом, а не руками
Ручная выкладка воспроизводима ровно до тех пор, пока её делает один и тот же человек в спокойном состоянии. Скрипт делает одно и то же каждый раз: забирает нужную версию, кладёт файлы, чистит кэш, применяет миграции, проверяет, что сайт отвечает.
| Практика | Что даёт | Чем оборачивается отсутствие |
|---|---|---|
| Небольшие частые выкладки | Проще найти причину поломки | Разбор большого пакета изменений вслепую |
| Быстрый откат | Минуты вместо часов простоя | Починка на живом сайте под давлением |
| Отдельный тестовый контур | Ошибки не доходят до клиентов | Роль тестировщика достаётся посетителям |
| Выкладка скриптом | Один и тот же результат каждый раз | Забытый файл и расхождение версий |
| Выкладка не в час пик | Меньше пострадавших при сбое | Сбой приходится на пик заявок |
| Проверка сразу после | Поломка видна за минуты | О проблеме сообщает клиент |
| Мониторинг доступности | Сигнал без участия человека | Сайт лежит до утра незамеченным |
Даже простой сценарий из нескольких команд, лежащий в репозитории и запускаемый одной строкой, лучше, чем инструкция в заметках. Скрипт заодно служит документацией: по нему видно, из чего состоит выкладка на этом проекте.
Миграции базы отдельно от кода
Самые неприятные аварии на выкладке связаны не с файлами, а с базой. Код уже ждёт новую колонку, а миграция не применилась; или миграция применилась, а старый код с изменённой таблицей не работает. Разводить эти шаги нужно осознанно.
- Изменения схемы делать совместимыми в обе стороны: сначала добавить, потом переключить код, потом убрать лишнее.
- Не удалять колонки и таблицы в той же выкладке, где меняется работающий с ними код.
- Хранить миграции в репозитории вместе с кодом, а не выполнять запросы руками в консоли.
- Перед применением на бою прогнать миграцию на свежей копии боевой базы и замерить время.
- Длинные операции по большим таблицам выносить в отдельное окно, а не в обычную выкладку.
Отдельно про правки данных: массовое обновление записей — не миграция схемы, а самостоятельная операция со своей резервной копией. Обратного хода у неё чаще всего нет.
Малые частые выкладки и режим обслуживания
Чем меньше изменений в одной выкладке, тем дешевле разбор, если что-то сломалось: круг подозреваемых сужается до нескольких строк. Пакет из двадцати несвязанных правок, накопленный за месяц, превращает поиск причины в отдельный проект.
Режим обслуживания — заглушка вместо сайта на время работ — нужен реже, чем принято думать. Для обычной выкладки файлов он избыточен: подмена каталога или перезапуск процесса занимают доли секунды. Он оправдан там, где идёт длинная миграция базы или операция, при которой сайт объективно отдаст ошибку.
Если заглушку всё-таки включают, она должна отдавать корректный код ответа для временной недоступности и содержать понятный текст с контактами. Обычная страница с ошибкой сервера в этой роли вредит, особенно если работы затянулись.
Что проверить сразу после выкладки
Короткий список, который проходится за несколько минут и закрывает большую часть сценариев.
- Главная и две-три внутренние страницы разных типов открываются без ошибок.
- Форма заявки отправляется, письмо приходит на все указанные адреса.
- В логах веб-сервера и приложения нет новых ошибок за последние минуты.
- Мета-теги, канонические адреса и разметка на месте, страницы не закрылись от индексации.
- Стили и скрипты подтянулись новой версией, а не остались в кэше.
- Вход в админку работает, содержимое редактируется и сохраняется.
- Показатели ответа сервера и счётчик посещаемости не просели за первый час.
Список полезно держать в репозитории рядом с кодом и дополнять после каждой аварии: то, что однажды сломалось, ломается повторно.
Минимум для небольшого сайта без CI
На шаред-хостинге без непрерывной интеграции достаточно трёх вещей: код в репозитории, копия сайта для проверки на отдельном поддомене и свежие резервные копии, которые пробовали разворачивать. Выкладку в этом случае делает простой скрипт синхронизации, запускаемый вручную, но всегда одинаково.
Отдельно стоит проверить, что автоматическая выкладка не перезапишет правки, сделанные прямо на сервере. Если сайт годами правился руками, первая же автоматическая выкладка способна вернуть его к состоянию годовой давности. Такие расхождения ищутся сверкой контрольных сумм до, а не после запуска.
Типичные ошибки
Править файлы прямо на боевом сервере. Выкладывать в пятницу вечером или перед праздниками. Собирать несколько несвязанных изменений в одну выкладку. Снимать резервную копию после начала работ. Проверять результат только на своей машине с забитым кэшем. Каждое из этих действий рано или поздно оборачивается вечерним разбирательством вместо спокойного релиза.
Если нужна помощь
Мы ведём выкладки на легаси-проектах и на современных сборках: заводим репозиторий, поднимаем тестовый контур, настраиваем резервное копирование и проверяем сайт по списку после каждого релиза. Если нужно перевести сайт с ручных правок на предсказуемый порядок — настроим техническую поддержку сайта с регламентом выкладок и откатов.
