Автодеплой из Git на сервере: частые ошибки и решения

MAATRIX

Автодеплой из Git на сервере должен экономить нервы, но нередко делает наоборот: выкат ломает прод, скрипт падает на правах, webhook не срабатывает, а откатиться нечем. Почти все эти проблемы — следствие нескольких типовых промахов в организации деплоя. Разберём их по порядку и превратим выкат из источника стресса в спокойную рутину.

Ошибка: деплой роняет прод на половине выката

Самая болезненная ситуация. Скрипт деплоя запустился, подтянул код, начал ставить зависимости — и упал на середине, оставив приложение в поломанном состоянии. Пользователи ловят ошибки, а на сервере лежит половина новой версии и половина старой. Причина — скрипт не прерывается на ошибке и перезапускает сервис независимо от того, успешно ли прошла сборка.

Решение — сделать скрипт «всё или ничего». Первая строка должна прерывать выполнение на любой ошибке, а перезапуск сервиса стоять строго после успешной сборки:

#!/bin/bash
set -e
cd /home/deploy/app
git pull origin main
npm ci && npm run build
systemctl restart myapp

Строка set -e останавливает скрипт на первом же сбое, не доходя до перезапуска. Ещё надёжнее — собирать новую версию в стороне и переключаться на неё только после успешной сборки, тогда прод вообще не видит промежуточных состояний. Так падение деплоя оставляет работать старую версию, а не ломает сервис.

Ошибка: permission denied при деплое

Скрипт падает на правах: не может записать файлы, перезапустить сервис или прочитать каталог. Причина обычно в путанице с пользователями. Код клонирован под одним пользователем, сервис работает под другим, webhook запускает скрипт под третьим — и права не сходятся. Файлы, созданные при деплое, оказываются недоступны тому, кто обслуживает приложение.

Наведите порядок с владельцами. Определите единого пользователя для деплоя и приложения, и следите, чтобы весь рабочий каталог принадлежал ему:

chown -R deploy:www-data /home/deploy/app

Отдельная грабля — перезапуск сервиса требует прав, которых у деплой-пользователя нет. Не решайте это выдачей полного sudo без пароля на всё подряд. Разрешите пользователю деплоя ровно одну нужную команду перезапуска через точечное правило sudoers. Принцип тот же, что и везде в безопасности: минимально достаточные права, а не «дадим root, чтобы не мучиться».

Ошибка: webhook не срабатывает

Вы делаете push, но на сервере ничего не происходит — деплой не запускается. Git-платформа шлёт webhook, а он не доходит или не обрабатывается. Причин несколько. Порт обработчика может быть закрыт фаерволом, и запрос просто не проходит. Обработчик может отвергать запрос из-за неверной проверки секрета. Или сам сервис-обработчик не запущен.

Проверяйте по цепочке. Сначала — доходит ли запрос: многие Git-платформы показывают историю доставки webhook с кодом ответа. Ответ с ошибкой соединения означает проблему с портом или фаерволом; ответ с кодом отказа — проблему на стороне обработчика. Затем смотрите логи обработчика на сервере. Частая тонкость — проверка секрета: если секрет в настройках webhook и в обработчике не совпадают, запрос корректно отвергается, и это не баг, а защита. Сверьте секреты и убедитесь, что порт обработчика открыт именно для адресов Git-платформы.

Ошибка: деплой прошёл, но изменения не видны

Скрипт отработал без ошибок, а на сайте всё по-старому. Обычно виноват кеш или незапущенная пересборка. Если приложение обслуживается собранными статическими файлами, а шаг сборки не выполнился или собрал не туда, пользователи видят старую версию. То же с кешем: браузерным, серверным или кешем самого приложения, который не сбросился после выката.

Проверьте, что скрипт действительно выполняет сборку и кладёт результат в тот каталог, который отдаёт веб-сервер. После деплоя сбрасывайте нужные кеши явным шагом. Ещё одна частая причина — git pull подтянул не ту ветку. Убедитесь, что деплой берёт именно ту ветку, что вы пушите, а не осталась зафиксирована старая. Полезно, чтобы скрипт в конце выводил актуальный коммит — тогда сразу видно, какая версия реально выкачена:

git rev-parse --short HEAD

Ошибка: нет способа откатиться

Свежий выкат сломал приложение, а вернуться к рабочей версии нечем — и начинается лихорадочный ручной откат под давлением. Это не случайность, а следствие деплоя, спроектированного без мысли об откате. Автодеплой без плана возврата опаснее ручного, потому что автоматизирует и ошибку тоже.

Предусмотрите откат заранее. В простой схеме это возврат на предыдущий коммит и повторный запуск сборки. В схеме с несколькими релизами, где каждая версия лежит в своей папке, а активная выбирается символической ссылкой, откат — это мгновенное переключение ссылки на прошлый релиз без всякой пересборки. Второй вариант надёжнее для боевых сервисов. Главное правило — проверить откат в спокойной обстановке, а не изобретать его в момент аварии. Рабочий, заранее протестированный откат превращает поломанный деплой из катастрофы в минутную неприятность.

Ошибка: сборка при деплое кладёт сервер

Во время деплоя приложение начинает тормозить или вовсе недоступно, потому что тяжёлая сборка съедает все ресурсы сервера. Особенно заметно на слабых VPS: компиляция или сборка фронтенда забирает процессор и память, которых не хватает работающему приложению. Если деплои частые, сервис постоянно лихорадит в моменты выката.

Есть два honest-решения. Первое — вынести сборку за пределы боевого сервера: собирать на отдельном раннере CI, а на прод выкладывать готовый результат. Тогда деплой на сервере сводится к быстрому копированию и перезапуску, без тяжёлой сборки. Второе — если сборка всё же идёт на сервере и упирается в ресурсы, перейти на более мощную конфигурацию. У MAATRIX нарастить ресурсы VPS можно в любой момент, оплатив из России картой, по СБП или криптой. Выбор зависит от масштаба: для команды с частыми выкатами сборка на раннере обычно правильнее.

Как сделать автодеплой предсказуемым

Соберём выводы в короткий чек-лист, который закрывает большинство граблей. Скрипт деплоя делайте по принципу «всё или ничего»: set -e и перезапуск только после успешной сборки. Наведите порядок с пользователями и правами, выдавая минимально необходимое. Проверяйте доставку webhook по истории на Git-платформе и логам обработчика. Убеждайтесь, что выкачивается нужная ветка и сбрасывается кеш. И обязательно держите проверенный способ отката.

Отдельно облегчает жизнь адекватный сервер. Когда сборка не конкурирует с работающим приложением за ресурсы, половина проблем со скоростью и стабильностью деплоя исчезает сама. На такой основе автодеплой из Git на сервере работает так, как задумано, — вы делаете push и через минуту видите обновлённое приложение, не задерживая дыхание.

Частые вопросы