У нас был проект для B2B-сервиса, где релиз делали через SSH, по чек-листу в Notion и с одним человеком, который держал в голове правильный порядок команд. Пока команда состояла из двух человек, схема работала. Когда релизы стали выходить 3-4 раза в неделю, выкладка стала самой нервной частью разработки.
Проблема тут обычно не в людях. Просто продукт растет быстрее, чем процесс доставки изменений. В какой-то момент тормозить начинает уже не код, а сам деплой, и бизнес платит за это переработками, срывами и лишними окнами релиза.
Пока прод выкатывает один человек, процесса еще нет
Ручной деплой выглядит дешевым, пока релизы редкие. Потом выясняется, что код команда пишет быстрее, чем умеет безопасно довозить его до production. Я такое видел не раз: Laravel 11, PostgreSQL 16, staging есть, production есть, инструкция лежит, а релиз все равно занимает 40-60 минут и каждый раз проходит с напряжением.
Обычно картина простая:
- прод выкатывает один опытный разработчик;
- остальные сервер стараются не трогать;
- откат существует только как набор ручных шагов;
- после релиза еще 30-60 минут все проверяют руками.
На одном проекте релиз в 23:40 уронил очередь задач. Причина была скучная: после обновления забыли перезапустить worker. Починили за 18 минут, но вечер у команды уже сгорел.
У нас, кстати, была и своя ошибка: один раз слишком поздно добавили smoke-тест после деплоя и несколько релизов жили на ручной проверке. Формально все работало, но запас надежности там был слабый.
Если результат зависит от внимательности конкретного человека, это еще не процесс. Это ручная операция с высоким риском.
CI/CD делает один и тот же маршрут для каждого изменения
Короче, CI/CD нужен не ради красоты в резюме. Смысл очень приземленный: каждое изменение проходит один и тот же путь. Система сама проверяет код, собирает артефакт, выкатывает на staging, прогоняет быструю проверку и только потом пускает дальше.
Базовый pipeline для веб-продукта часто выглядит так:
push:
- lint
- unit_tests
- build
- docker_image
- push_to_registry
- deploy_staging
- smoke_test
- manual_approval
- deploy_production
Мы чаще берем GitHub Actions или GitLab CI/CD. Этого обычно хватает малому и среднему бизнесу без всякой экзотики. После такой настройки релиз обычно сжимается до 7-10 минут, и главное - он идет одинаково и в среду днем, и в пятницу вечером.
| Критерий | Ручной деплой | CI/CD |
|---|---|---|
| Время релиза | 40-60 минут | 7-10 минут |
| Повторяемость | зависит от человека | один сценарий |
| Риск ошибки | высокий | ниже за счет проверок |
| Откат | по памяти | по тегу версии |
Docker убирает споры про окружение и упрощает откат
Когда меня спрашивают, зачем здесь Docker, я бы сказал так: это упаковка приложения вместе с его зависимостями. Команда выкатывает не «что сейчас лежит в ветке», а конкретный образ, например app:1.14.3. Если после релиза пошли ошибки, можно быстро вернуться на app:1.14.2.
На проекте для логистики у нас была связка Node.js 20 + NestJS, Redis, PostgreSQL 16 и Docker Compose на обычном VPS. Все хотели сразу Kubernetes, потому что «так взрослее». На практике он добавил бы лишние 5-6 недель настройки и постоянную возню в поддержке. После перехода на контейнеры число историй из серии «локально работает» сократилось примерно на 70%.
Частая ошибка тут простая: сразу тащить тяжелую инфраструктуру «на будущее». Я бы сделал так: сначала собрать повторяемый деплой на том масштабе, который есть сейчас. Для регионального дистрибьютора, интернет-магазина или B2B-кабинета чаще хватает Docker Compose, registry и нормального rollback.
Ценность не в скорости, а в том, что менять продукт становится безопаснее
Многие ждут от CI/CD только ускорения. Но быстро выложить код можно и вручную, вопрос всегда в цене ошибки. Когда есть pipeline, команда начинает выпускать маленькие изменения чаще, и каждый релиз проще проверить, откатить и разобрать, если что-то пошло не так.
У одного клиента до автоматизации был выпуск раз в 2-3 недели. В релиз набивалась куча задач, потом полдня уходило на поиск виновника. После настройки pipeline они перешли на 2-5 релизов в неделю, и инциденты стало проще ловить по горячим следам.
Один CTO логистической платформы хорошо это сформулировал: чем меньше размер релиза, тем дешевле ошибка. На практике так и выходит.
С чего начинать без большой перестройки инфраструктуры
Если сайт меняется раз в квартал, можно не спешить. Но если у вас несколько разработчиков, база, интеграции и постоянные правки, ручной деплой уже начинает съедать время команды и нервы бизнеса.
Я бы сделал так:
- автосборка при push;
- lint, тесты и build;
- сборка Docker image с тегом версии;
- выкладка на staging;
- кнопка релиза на production и быстрый откат.
Такой стартовый набор мы не раз собирали за 1-2 недели. На одном проекте уложились в 6 рабочих дней без полной переделки серверов. Самая полезная вещь там была даже не скорость, а исчезновение зависимости от «того самого человека».
Самый дорогой серверный риск часто вообще не в железе и не в облаке. Он сидит в голове одного разработчика. У вас релиз уже стал знанием конкретного человека или все-таки частью продукта, которую можно запустить без него?
