Автоматизация процессов разработки: CI/CD без боли

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

Я через это проходил на своих же проектах. Долгое время у меня был зоопарк: часть скриптов на одном, часть на другом, запуск через «зайди по SSH и дёрни вот эту команду». Работало. Но каждое изменение стоило нервов, а откатиться было нечем.

Расскажу по шагам, как привожу проекты к нормальному автодеплою и какой минимальный пайплайн собираю первым. Без идеологии, только то, что реально делаю.

Автоматизация процессов разработки начинается с порядка

CI/CD — это конвейер. Если на входе хаос, на выходе будет автоматизированный хаос, только быстрее. Поэтому сначала четыре скучных вещи.

Один язык вместо зоопарка

В один момент я взял все старые скрипты и перевёл их на Python. Не потому что Python лучше всех, а потому что одно окружение вместо четырёх — это в четыре раза меньше поводов, чтобы что-то не собралось. Один язык, один менеджер зависимостей, один способ запускать тесты.

Если у вас в проекте живут три технологии и каждая по историческим причинам — это первое, что нужно решить. Не обязательно переписывать всё. Достаточно перестать плодить новое.

Docker: чтобы «у меня работает» перестало быть аргументом

Дальше всё уехало в докер-контейнеры. Это та точка, с которой автоматизация вообще становится возможной: контейнер описывает окружение в файле, а не в чьей-то голове. На сервере, на ноутбуке разработчика и в пайплайне поднимается одно и то же.

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

Git как единственный источник правды

Всё заведено в git. Это звучит как банальность, но я регулярно вижу проекты, где на боевом сервере лежит код новее, чем в репозитории, потому что «надо было срочно поправить».

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

Структура, которую понимает новый человек

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

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

Что такое пайплайн простыми словами

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

Цель ровно одна: чтобы изменения залетали на боевой сервер и применялись без боли и страданий. Не чтобы было модно, не чтобы в резюме написать. Чтобы правка от идеи до продакшена занимала минуты и не требовала человека с бубном.

Минимальный CI/CD, который стоит собрать первым

Не надо сразу строить многоступенчатый конвейер с ручными согласованиями. Возьмите пять шагов.

1. Сборка. Собирается образ проекта. Не собралось — дальше не едем, автор изменения сразу получает уведомление.
2. Проверки. Линтер и тесты, даже если тестов пока три. Три работающих теста лучше, чем ноль идеальных.
3. Деплой на тестовый контур. Отдельный сервер или отдельное окружение, где можно ломать.
4. Деплой на прод. Сначала по кнопке, а не автоматом. Автоматический прод — это следующий уровень доверия, его надо заслужить.
5. Проверка живости после деплоя. Простейший запрос к сервису: поднялся или нет. Если нет — откат.

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

Четыре причины, по которым деплой остаётся больным

Нет откатов. Если единственный способ починить прод — быстро написать новый код, вы будете бояться деплоить. Возможность вернуться на предыдущую версию одной командой снимает этот страх.

Миграции базы едут вместе с кодом наугад. База — самая опасная часть. Изменения схемы должны применяться отдельным осознанным шагом и быть обратно совместимыми хотя бы на один релиз.

Секреты лежат в репозитории. Рано или поздно это стоит очень дорого. Ключи, токены и пароли — только в переменных окружения на стороне сервера.

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

Как это выглядело у нас

Живой пример. Я взял в работу сервис по туризму области — подбор маршрутов по интересам. Под сервис парсинга подняли продакшн-сервер, и следующим же шагом я сел за CI/CD-пайплайн: чтобы изменения сразу залетали на боевой сервер и применялись без боли.

Порядок был именно такой: сначала сервер и окружение, потом конвейер, и только потом активная разработка фич. Если делать наоборот, вы половину времени будете руками разносить изменения по машинам.

Кстати, в том же проекте пришлось писать свой парсер, который тащит места, фотографии и рейтинги с карт, — потому что API этого не даёт, даже платное. Это тоже часть автоматизации разработки: когда готового решения нет, вы пишете своё, но пишете его так, чтобы оно жило в общем конвейере, а не запускалось отдельно с чьего-то ноутбука.

Когда это всё не нужно

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

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

Что дальше

Автоматизация разработки — не отдельная услуга «поставьте нам CI/CD». Это то состояние, до которого мы доводим каждый проект, за который берёмся, — иначе его невозможно поддерживать.

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