Ручной деплой ломает прод: как GitLab CI убирает хаотичные откаты

Представьте: конец рабочего дня, нужно срочно выкатить небольшое исправление — поменять кнопку оплаты на сайте интернет-магазина. Разработчик подключается к боевому серверу по FTP, перетаскивает пару файлов, обновляет страницу… и видит белую заглушку. Сайт лежит. Заказчик уже звонит. Дальше — несколько часов попыток откатиться, путаница с версиями, звонки сисадмину, который вне доступа. Магазин не работает двое суток, деньги теряются, нервы сгорают. Знакомо? Это не единичный случай, а системная болезнь ручных деплоев. В статье разберём, почему так происходит, и как настроить CI/CD с GitLab, чтобы подобные выкатки превратились в рутинную кнопку «Выкладка», а не в русскую рулетку.

Как ручной деплой превращает обычный вечер в катастрофу

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

Сценарий аварии: FTP и никакого бэкапа

В примере выше обновляли тему интернет-магазина. Разработчик не знал, что коллега уже вносил правки в тот же файл конфигурации, и перезаписал его своей версией, потеряв изменения. Вдобавок на сервере не оказалось резервной копии за последние сутки — бэкап делал бывший сисадмин вручную и уволился. Откатиться не на что. Сайт лежит, пока не находят старую копию на ноутбуке у кого то из команды. Итог: двое суток простоя, упущенная выручка, испорченные отношения с покупателями.

Таких историй сотни: кто-то забыл очистить кеш, кто-то залил изменения не в ту ветку, кто-то случайно выполнил DROP TABLE на проде. Ручной деплой — это всегда человеческий фактор: усталость, спешка, недостаток компетенций. И чем больше людей трогают прод, тем выше вероятность фатальной ошибки.

Почему GitLab CI — не просто модное слово, а рабочий инструмент

GitLab CI/CD — это встроенный инструмент GitLab для автоматизации сборки, тестирования и доставки кода. Вместо ручного копирования файлов разработчик делает git push, и дальше всё происходит по сценарию: компиляция, проверка, упаковка в Docker-образ, запуск тестов и только после успешного прохождения — выкатка на сервер. Если тесты падают, код не попадает в прод.

Для собственника бизнеса это означает три вещи:

• Никаких сюрпризов после деплоя. Выкатку можно запускать в рабочие часы — и она пройдёт одинаково предсказуемо.
• Любой член команды может выкатить версию. Не нужно искать «того самого админа», который знает все пароли. Права на деплой выдаются через GitLab, всё логируется.
• Откат за минуты, а не за часы. Все версии хранятся в git-репозитории, а Docker-образы — в registry. Если что-то пошло не так, возврат к предыдущей версии выполняется одной командой.

При этом GitLab CI — лишь часть общей практики DevOps. Сам по себе инструмент не спасёт, если не продуманы процессы, окружения и мониторинг. Но он даёт скелет, на который наращивается всё остальное.

Типичный сценарий аварии: от FTP до отката без бэкапа

Выше мы описали аварию. Давайте разложим её на этапы, чтобы понять, где именно ломается процесс.

Шаг 1. Разработчик вносит изменение локально

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

Шаг 2. Загрузка на прод

Разработчик подключается к серверу и копирует файлы. Конфликты с чужими правками не проверяются. Иногда забывают про настройки, специфичные для боевого окружения (включённый режим отладки, ключи API, пути к БД). Иногда файлы попадают не в ту директорию.

Шаг 3. Мгновенный сбой

Сайт падает: белый экран, ошибка 500 или некорректная вёрстка. Начинается быстрый откат «наугад»: удаляют, восстанавливают, перезагружают сервер. Если повезёт — сайт оживает через час. Если нет — начинается долгий разбор.

Шаг 4. Восстановление без команды на связи

Инцидент часто случается, когда часть команды уже вне доступа. Ищут бэкап — его нет. Находят старую копию у уволившегося сотрудника, но свежие данные утеряны: заказы, регистрации, оплаты.

Этот сценарий — не выдумка, а обобщение десятков обращений, которые приходят в нашу компанию. Собственники просят «починить сайт» и «сделать так, чтобы больше не падало». Но починка — это не разовое действие, а переход на автоматический конвейер доставки кода.

Как выстроить пайплайн без хаоса: шаги и этапы

Настройка CI/CD не делается за один день, но базовый контур можно собрать за две три недели. Главное — не пытаться охватить всё сразу, а двигаться этапами. Рассмотрим практический план для команды из 3–5 разработчиков и небольшого монолита или нескольких сервисов.

Этап 1. Приводим код в порядок

Первый шаг — перенести весь код в GitLab, если он ещё не там. Настроить ветки: main (боевой контур) и develop (или feature-ветки). Договориться, что в main попадает только проверенный код через merge request. Это дисциплинирует команду и даёт точку возврата для любого состояния.

Этап 2. Пишем .gitlab-ci.yml

В корне репозитория создаётся файл .gitlab-ci.yml, в котором описываются стадии пайплайна. Минимальный набор для обычного веб приложения:

1. Build — сборка проекта, установка зависимостей, компиляция ассетов.
2. Test — запуск unit-тестов, линтеров, проверка типов.
3. Тестовый контур Выкладка — выкатка на тестовый сервер, где можно всё проверить вручную.
4. Боевой контур Выкладка — только после ручного подтверждения (кнопка в GitLab) код уходит в прод.

Такой пайплайн не требует глубоких знаний DevOps — его можно написать по документации за пару часов. Но если в проекте несколько сервисов, микросервисы или сложные зависимости, лучше пригласить специалиста по настройке CI/CD.

Этап 3. Включаем автоматические тесты

Без тестов CI/CD не имеет смысла: вы просто автоматизируете доставку ошибок. Начните с малого: добавьте проверку, что код собирается без ошибок, и пару быстрая проверка тестов, которые открывают главную страницу и проверяют ключевые элементы. Постепенно добавляйте unit-тесты, интеграционные тесты. Это не обязательно делать всё сразу, но каждый автоматический тест — это барьер на пути дефекта в прод.

Этап 4. Контейнеризация и выкатка

Следующий уровень — сборка Docker-образов и деплой через Docker Compose или Kubernetes. Контейнеры решают проблему «на моей машине работает, а на сервере нет», потому что окружение одинаковое. Для старта можно использовать Docker Compose на одной VPS, а позже перейти на Kubernetes, если нужно масштабироваться.

В таблице ниже — сравнение подходов к деплою, чтобы наглядно увидеть разницу.

Kubernetes и GitLab CI: когда пора автоматизировать контейнеры

Если проект растёт, появляются микросервисы, высокие нагрузки или необходимость быстро масштабироваться, одного Docker Compose может не хватить. Тогда в связку добавляют Kubernetes — систему оркестрации контейнеров. Она сама следит за состоянием подов, перезапускает упавшие экземпляры, распределяет трафик, выполняет rolling-обновления без простоя.

Настройка Kubernetes сложнее, чем Docker Compose, но интеграция с GitLab CI позволяет автоматически деплоить новые версии прямо в кластер. При этом используется подход GitOps: все описания деплоя хранятся в репозитории, и любые изменения инфраструктуры проходят через тот же процесс ревью и аудита, что и код приложения. Для владельца бизнеса это означает: любые изменения можно отследить, откатить и повторить, а инфраструктура не зависит от «единого админа», который всё держит в голове.

Если вы ещё не готовы внедрять Kubernetes, не беда. Многие проекты прекрасно живут на Docker Compose или простых виртуальных машинах. Главное — чтобы деплой был автоматизирован, а не выполнялся вручную. Kubernetes — это инструмент для тех, кто уже упёрся в ограничения других подходов.

DevOps-аутсорсинг позволяет быстро запустить CI/CD без найма сеньора

Настроить CI/CD самостоятельно можно, но это требует времени и компетенций. Для малого и среднего бизнеса часто выгоднее привлечь внешнюю команду, которая уже проделывала это десятки раз. DevOps-аутсорсинг решает несколько задач:

• Скорость. Вместо месяца проб и ошибок — готовый пайплайн за 2–3 недели.
• Экономия. Не нужно нанимать DevOps-инженера в штат с зарплатой от 200–300 тысяч рублей в месяц, если объём задач невелик.
• Опыт. Подрядчик знает типовые грабли: настройка секретов, работа с несколькими окружениями, безопасность, откаты.
• Фокус. Ваша команда продолжает заниматься продуктом, а не инфраструктурой.

В нашей практике типовой проект по настройке CI/CD для небольшой команды включает: аудит текущего процесса, перенос кода в GitLab, написание пайплайна, подключение Docker, настройку тестовый контур и боевой контур окружений, базовый мониторинг. Стоимость таких работ обычно стартует от 90 000 рублей за проектирование инфраструктуры, а постоянная DevOps-поддержка — от 240 000 рублей в месяц. Это не означает, что всем нужно сразу платить такие суммы: для небольших проектов бывает достаточно разовой настройки и обучения команды.

Три недели на переход: реальный план для малого бизнеса

Чтобы переход на CI/CD не превратился в долгострой, нужен чёткий план с контрольными точками. Вот реалистичный график для команды из двух трёх разработчиков и одного менеджера, который отвечает за сайт.

Неделя 1. Аудит и подготовка

Проводим ревизию: где хранится код, как сейчас происходит деплой, есть ли бэкапы, кто имеет доступ к серверу. Составляем список критичных сервисов и их зависимостей. Если кода нет в Git — переносим. Настраиваем GitLab, создаём репозитории, ветки, права доступа.

Неделя 2. Базовый пайплайн

Пишем .gitlab-ci.yml: сборка, тесты, выкладка на тестовый контур. Подключаем Docker. Настраиваем автоматический запуск пайплайна при push. Учим команду делать merge request вместо прямых коммитов в main.

Неделя 3. Тестовый контур и боевой контур

Доводим тестовый контур до состояния, близкого к боевой контур. Добавляем ручное подтверждение для выкладка в боевой контур. Проводим тестовый прогон: откатываемся, проверяем бэкапы, настраиваем уведомления в Telegram или MAX (мы — официальные партнёры MAX и Telegram). К концу этапа выкатываем первое боевое обновление через кнопку в GitLab.

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

Первый шаг: начните с аудита текущего деплоя

Не обязательно сразу бросаться в Kubernetes или переписывать всю инфраструктуру. Самое важное — признать, что ручной деплой создаёт риски, и сделать первый шаг: посмотреть, как сейчас выглядит процесс доставки кода. Если вы не знаете, с чего начать, мы готовы помочь. Наша команда настраивает GitLab CI/CD, Docker, Kubernetes и полный цикл DevOps для малого и среднего бизнеса. Оставьте заявку на DevOps-услуги — и через пару недель срочные выкатки перестанут быть зоной бедствия.