DevOps для собственного сайта: CI/CD-конвейер, автотесты, откат деплоя и управление окружениями
1. Почему собственному сайту нужен конвейер, а не «зашёл по SSH и поправил»
У собственного сайта обычно три способа деплоя: перетащить файлы по FTP, вручную подтянуть git по SSH, нажать «перезапустить» в панели управления. Все три работают, пока посещаемость меньше 5000 в месяц, но как только вы одновременно меняете код, базу данных и сторонние плагины, частота инцидентов растёт в разы. Ценность CI/CD не в том, что деплой становится быстрее, а в том, что каждое изменение воспроизводимо, отслеживаемо и откатываемо.
Простой критерий: если в команде нет второго человека, который может безопасно провести деплой, пока вы в отпуске, значит, процесс деплоя ещё не автоматизирован. На B2B-сайте контент обновляется нечасто, но ошибка при релизе изменений в формах, оплате или структурированных данных для SEO напрямую бьёт по заявкам. О связанных задачах производительности читайте в Core Web Vitals— там про ритм оптимизации.
| Способ развёртывания | Время на один деплой | Вероятность ошибки | Возможность отката | Этап применения |
|---|---|---|---|---|
| Ручное перетаскивание файлов по FTP | 10–30 минут | Высокая (часто забывают файлы) | Нет, только из бэкапа | Прототипы, тесты в одиночку |
| Подтянуть git по SSH и перезапустить | 5–10 минут | Средняя (различия окружений) | Доступен git reset | Небольшие сайты с посещаемостью <5000 |
| Конвейер CI/CD | 15–25 минут | Низкая (автоматические точки контроля) | Переключение версии в один клик | Боевой сайт, командная работа |
| GitOps + K8s | 10–15 минут | Очень низкая | Декларативный откат | Несколько инстансов и окружений |
2. Как спроектировать пять контрольных точек конвейера
Не гонитесь сразу за принципом «коммит — и в продакшен». Конвейер для собственного сайта лучше разбить на пять этапов, и сбой на любом из них останавливает процесс: сборка, юнит-тесты, дымовые тесты на пре-проде, канареечный релиз, полный релиз. На этапе сборки фиксируются версии зависимостей и собирается неизменяемый образ; на этапе юнит-тестов прогоняются тесты и статический анализ кода; на этапе пре-прода дымовые E2E-тесты идут в staging-окружении, идентичном продакшену; на этапе канареечного релиза сначала переводится 5% трафика и наблюдение идёт 15 минут; если метрики в норме, трафик переводится на 100%.
Бюджет времени должен быть жёстким. Сборка ≤5 минут, юнит-тесты ≤3 минуты, предрелиз ≤10 минут, наблюдение на канареечном релизе 15 минут — итого ≤35 минут. Если дольше, разработчики начнут пропускать пайплайн и деплоить вручную, и автоматизация станет бесполезной. Связь CDN-кэша и статики см. в Глобальное ускорение CDN.
| Этап | Обязательные шаги | Порог прохождения | Действия при сбое |
|---|---|---|---|
| Сборка | Установка зависимостей, сборка образа, сканирование образа | Нет уязвимостей высокого риска, образ <1 ГБ | Блокировка, переход к следующему этапу запрещён |
| Юнит-тесты | Юнит-тесты, статический анализ, проверка типов | Покрытие ≥70%, нет блокирующих предупреждений | Блокировка, уведомление автора коммита |
| Smoke-тесты на предрелизе | Три E2E-сценария: главная, список товаров, форма запроса | Все пройдены, доля ошибок API 0% | Блокировка, логи сохранены |
| Канареечный релиз | Переключение 5%→25%→100%, наблюдение по 15 минут на каждом этапе | Доля ошибок <1%, P95 задержки не растёт более чем на 20% | Автоматический откат на прежнюю версию |
| Полный релиз | Переключение на 100%, архивирование номера версии | Наблюдение 30 минут без отклонений | Ручной откат |
III. Автотесты: какие сценарии писать для собственного сайта
Небольшие команды чаще всего бросаются в две крайности: либо вообще не пишут тесты и всё проверяют вручную, либо сразу гонятся за покрытием 90%. Реальность собственного сайта такова: бизнес-логика несложная, но ошибки в формах, SEO и мультиязычности бьют напрямую. Рекомендуем разбить тесты на три уровня и расставить их по отдаче от вложений.
Первый уровень — юнит-тесты: покрывают утилиты, расчёт цен, валидацию форм. Целевое покрытие 70%, гнаться за 100% не нужно. Второй уровень — E2E smoke-тесты: только три ключевых пути — открытие главной, переход из списка товаров в карточку, успешная отправка формы запроса. Третий уровень — регрессионные тесты: перед каждым релизом вручную пройти 10 ключевых страниц на предрелизе. Структурированные данные и проверку Schema см. в Структурированные данные Schema.
| Уровень тестов | Рекомендуемое число сценариев | Время одного прогона | Цель покрытия | Приоритет вложений |
|---|---|---|---|---|
| Юнит-тесты | 30–80 | 1–3 минуты | Утилиты, цены, валидация | Максимальная |
| Тесты API | 10–20 | 2–5 минут | Отправка форм, CRM webhook | Высокий |
| E2E smoke-тесты | 3–5 | 5–10 минут | Три основных пути: главная/карточка/запрос | Высокий |
| Визуальная регрессия | 10–20 скриншотов | 10–15 минут | Ключевые страницы на десктопе и мобильных | Средний |
| Ручная регрессия | 10 страниц | 30 минут | Мультиязычность, оплата, письма из форм | Перед каждым релизом |
IV. Деплой и откат: откат образа и откат данных — это две разные вещи
Самая частая авария при откате: код откатили, а схему базы данных — нет, и новая версия кода не может подключиться к старой структуре таблиц. Правильный подход — развести изменения кода и базы данных на два независимых пайплайна. Изменения кода идут через blue-green или rolling-деплой, их можно переключить в любой момент; изменения базы данных должны быть обратно совместимыми — сначала стратегия expand-contract: добавить новые колонки, не трогая старые, после переключения кода перенести данные и в конце удалить старые колонки.
Практический критерий: любое изменение структуры базы данных перед выкладкой нужно прогнать локально на обезличенной копии продакшен-данных через полный цикл «обновление → работа → откат → повторное обновление». Не прошло — не выкладываем. Подробности о резервном копировании и учебных восстановлениях — в Бэкап и восстановление сайта.
| Тип изменения | Способ отката | Ожидаемое время | Требования |
|---|---|---|---|
| Только статика и шаблоны | Сброс CDN и возврат к старому образу | 2–5 минут | Хранить последние 10 версий |
| Код приложения (без изменений БД) | Blue-green: возврат к старой среде | 3 минуты | Старая среда живёт 30 минут |
| Добавление столбца или таблицы в БД | Обратная совместимость, откат не нужен | 0 | Новый столбец допускает NULL |
| Смена типа столбца или удаление столбца | Прямая выкладка запрещена, только в два этапа | Через две версии | Сначала расширить, потом сжать |
| Изменение конфигурации | Откат одной кнопкой в центре конфигурации | 1 минута | Конфигурация под контролем версий |
Пять: управление средами — хватит ли трёх?
Минимум для самостоятельного сайта — три среды: dev для локальной разработки, staging для тестов и предрелиза, prod для реальных пользователей. staging должна быть устроена так же, как prod: та же версия PHP или Node, та же версия базы данных, те же расширения, те же правила CDN. Самая частая ошибка — SQLite на staging и MySQL на prod: расхождение в поведении функций даты обнаруживается только после выкладки.
Разделение конфигурации обязательно. Пароли к базе данных, ключи сторонних API, платёжные ключи — всё через переменные окружения или центр конфигурации, не в репозитории. Простая проверка: опубликуйте репозиторий на GitHub — если ни один реальный ключ не утёк, всё в порядке. На многоязычных сайтах к различиям сред добавляется проблема кэша переводов, см.Процесс публикации многоязычного контента.
| Среда | Зачем нужен | Источник данных | Триггер деплоя | Открыта наружу |
|---|---|---|---|---|
| local | Локальная разработка | Тестовые данные или обезличенная копия | Вручную разработчиком | Нет |
| dev | Ежедневная сборка | Обезличенный снимок продакшена | При каждом слиянии в основную ветку | Добавить Basic Auth |
| staging | Приёмка перед выкладкой | Еженедельный обезличенный снимок | Автоматически после тега | Добавить Basic Auth |
| prod | Реальные пользователи | Продакшен-данные | Ручная публикация одной кнопкой | Открытый |
FAQ: частые вопросы
Нужны ли CI/CD для сайта, который ведёт один человек, или это слишком тяжело?
Какое покрытие юнит-тестами считать достаточным?
Есть ли смысл в канареечном релизе для сайта с небольшим трафиком?
Что делать, если миграция базы данных провалилась?
Нужно ли использовать реальные данные в staging?
Сколько должен идти CI/CD-пайплайн?
В заключение
Для DevOps на собственном сайте не нужно равняться на IT-гигантов. Команда из двух человек с GitHub Actions, Docker-образами и blue-green скриптом превращает деплой из «ручного перетаскивания файлов в три часа ночи» в «нажатие кнопки в начале рабочего дня». Частоту аварий определяет не новизна инструментов, а то, зашиты ли в пайплайн три вещи: управление окружениями, откат базы данных и наблюдение за канареечным релизом.
Внедряйте в три шага. На первой неделе переведите ручной деплой в скрипты, чтобы всё разворачивалось одной командой. На второй неделе добавьте юнит-тесты и E2E-смоук как обязательный шлюз. На третьей неделе настройте blue-green деплой и откат в один клик. После этих трёх шагов частота деплоя вырастет с раза в неделю до нескольких раз в день, а среднее время восстановления после сбоя уложится в 10 минут. Как настроить мониторинг и алерты на сайте, читайте в Мониторинг сайта и оповещения.
Фраза на память: цель CI/CD — не «быстро деплоить», а «спать спокойно, когда что-то сломалось» — откат за 3 минуты, и только тогда команда решается выпускать каждый день.