Релиз как спецоперация
Выкат делается раз в две недели, ночью, по чек-листу из сорока пунктов и силами одного человека. Его отпуск или больничный останавливает выпуск задач.
CI/CD и релизы
Выкатываем изменения несколько раз в день без страха и простоя
Строим конвейеры сборки, проверок и доставки для Laravel-проектов: автоматические тесты на каждый коммит, одинаковый артефакт на всех окружениях, blue-green и canary-выкат, откат одной командой.
Или сразу: +7 (962) 368-39-51 Telegram
5–10 мин
от коммита до результата проверок
1 команда
на откат к предыдущей версии
DORA
метрики, по которым видно прогресс
0
ручных шагов при выкате
Как выглядит деплой до автоматизации
Ниже — то, что мы чаще всего видим в проектах, которые развиваются годами и выросли из одного сервера.
Тесты не гоняются на каждый коммит
Полный прогон занимает час, поэтому запускается вручную перед релизом. Регресс находят пользователи, а не конвейер, и стоит это дороже любых тестов.
Миграции применяются руками
Схему меняют прямо на продакшене через консоль, без обратной совместимости. Изменение типа колонки требует остановки приложения и не откатывается назад.
Окружений нет, проверяем на продакшене
Staging либо отсутствует, либо разошёлся с продакшеном по версиям, данным и настройкам настолько, что проверка на нём ничего не доказывает.
Секреты и конфиги копируются по SSH
Пароли к базе, токены платёжных систем и ключи API лежат в .env на сервере, попадают в бэкапы, дублируются в переписке и не ротируются годами.
Откат означает восстановление из бэкапа
Если новая версия ломает сценарий оплаты, команда тратит один-три часа на разбор и восстановление вместо переключения на предыдущий релиз за минуту.
Что входит в настройку CI/CD
Объём подбираем под проект: кому-то достаточно конвейера и staging, кому-то нужны несколько окружений и canary-выкат с автооткатом.
Конвейер сборки и проверок
Каждый merge request проходит одинаковый набор проверок, поэтому качество перестаёт зависеть от дисциплины конкретного разработчика.
- GitLab CI или GitHub Actions: стадии lint → test → build → deploy
- Статический анализ (PHPStan/Larastan, Pint, ESLint) и unit/feature-тесты
- Кэш зависимостей Composer и npm: обратная связь за 5–10 минут вместо часа
- Параллельный прогон тестов по группам на нескольких раннерах
Артефакты и окружения
Собранный и протестированный артефакт продвигается по окружениям без пересборки — исключаем ситуацию «на стенде работало, в проде другое».
- Docker-образ с неизменяемым тегом по SHA коммита
- Публикация в container registry и продвижение dev → stage → prod
- Разворачивание окружений из кода: одно описание для стенда и продакшена
- Сканирование образа и зависимостей на уязвимости прямо в конвейере
Стратегии безопасного выката
Выбираем схему под ваш риск: полный blue-green для критичных релизов или канареечный выкат на часть трафика для частых изменений.
- Rolling update, blue-green и canary с автоматическим откатом по метрике ошибок
- Feature flags: функциональность включается и выключается без релиза
- Миграции по схеме expand/contract — совместимость старого и нового кода
- Дымовые тесты после выката с автоматическим возвратом версии при падении
Передача и эксплуатация
Конвейер должен жить без нас: оставляем документацию, дашборды и обученную команду, а не хрупкую конструкцию из скриптов.
- Runbook «как выпустить и как откатить» для нового инженера в команде
- Метрики DORA: lead time, частота релизов, доля сбоев, время восстановления
- Обучение команды: разбор пайплайна, работа с секретами, разбор инцидентов
- Поддержка после запуска: обновление раннеров и базовых образов
Как мы внедряем CI/CD
Работаем итерациями: первая версия конвейера появляется в первые две недели и сразу используется, а не собирается «до идеала» в стороне.
-
01 3–5 дней
Аудит процесса релиза
Разбираем, как релиз устроен сегодня: сборка, тесты, миграции, окружения, доступы. Замеряем время выката и частоту сбоев, чтобы было с чем сравнивать.
-
02 1–2 недели
Сборка конвейера
Настраиваем стадии, кэш, параллельный прогон тестов и сборку образа. Добиваемся, чтобы конвейер падал на реальных ошибках, а не на нестабильных тестах.
-
03 1–2 недели
Окружения и выкат
Переносим конфигурацию и секреты в управляемое хранилище, описываем окружения кодом, включаем выбранную стратегию выката и откат одной командой.
-
04 1–2 недели
Обкатка и передача
Проводим несколько реальных релизов вместе с командой, доводим runbook, обучаем инженеров и передаём конвейер в сопровождение.
Релиз должен быть скучным событием
Пока выкат — это событие, к которому готовятся, его будут делать редко и большими порциями. Чем крупнее порция изменений, тем выше вероятность, что что-то сломается, и тем сложнее найти причину: в одном релизе смешаны новая оплата, обновление каталога и правки вёрстки.
Автоматизация меняет не только скорость, но и саму природу риска. Маленькие релизы, которые выкатываются несколько раз в день, проверяются быстрее и откатываются дешевле. Ошибка, найденная в течение десяти минут после выката, стоит на порядок меньше ошибки, найденной через два дня после ночного релиза.
Миграции без простоя: схема expand/contract
Основная причина простоя при обновлении — не деплой кода, а изменение схемы базы данных. Пока миграция выполняется, старая версия приложения продолжает обслуживать запросы и уже не соответствует новой структуре таблиц.
Поэтому мы раскладываем изменение на три шага. На первом (expand) добавляем новую колонку или таблицу так, чтобы старая версия кода продолжала работать, и включаем двойную запись. На втором переводим чтение на новые поля и выпускаем релиз. На третьем (contract) удаляем старое — уже отдельным, спокойным релизом, когда убедились, что откат не понадобится. Тяжёлые операции — перестройку индексов, пересчёт больших таблиц — выполняем отдельными задачами под контролем метрик, а не внутри выката.
Метрики, по которым видно, что CI/CD действительно работает
Отраслевой стандарт измерения — четыре показателя DORA. Частота развёртывания (deployment frequency) показывает, насколько быстро продукт доносит изменения до пользователей. Время от коммита до продакшена (lead time for changes) отражает длину очереди между решением и результатом. Доля неудачных изменений (change failure rate) говорит о качестве проверок в конвейере. Время восстановления (time to restore) — о том, насколько хорошо продуман откат.
Мы замеряем эти метрики до начала работ и после каждого этапа. Типичная картина в проекте, который приходит с ручным деплоем: релиз раз в две недели, lead time около месяца, время восстановления — часы. После внедрения конвейера, окружений и стратегии отката релизы идут несколько раз в неделю, а восстановление занимает минуты.
Частые вопросы
Для проекта на Laravel с одним-двумя окружениями — от трёх до шести недель до полностью автоматического выката. Первая версия конвейера появляется на первой неделе и сразу используется командой, дальше добавляем окружения, миграции и стратегию отката. Системы из нескольких сервисов с собственной инфраструктурой занимают от двух месяцев.
Нет. Для проекта на классическом сервере конвейер может собирать артефакт и раскладывать файлы с переключением симлинка — это уже даёт воспроизводимость и мгновенный откат без переезда на контейнеры. Docker нужен там, где важно одинаковое окружение на всех машинах, горизонтальное масштабирование и предсказуемая сборка зависимостей.
При наличии SSH и доступа к git можно построить минимальный, но честный конвейер: тесты и сборка на отдельном раннере, выкат по SSH с переключением симлинка и возвратом на предыдущую версию. Полноценные окружения, канареечный выкат и горизонтальное масштабирование потребуют VPS или контейнерной платформы — это отдельный этап, который имеет смысл планировать после базовой автоматизации.
Да, и для многих проектов это обязательное условие: исходный код, артефакты и секреты не должны покидать ваш контур. Разворачиваем GitLab Runner или self-hosted раннер GitHub Actions на вашей инфраструктуре и настраиваем кэш зависимостей локально. Дополнительный плюс — нет ограничений на минуты сборки и очередей облачных раннеров.
DevOps: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Хотите выпускать релизы без ночных дежурств?
Расскажите, как устроен деплой сейчас, — предложим план автоматизации, сроки и стоимость.