CI/CD: Почему зеленые галочки в GitHub Actions не делают вас инженером

Многие привыкли воспринимать CI/CD как набор скриптов, которые просто запускают линтеры и тесты. Но если ваша команда релизится раз в месяц и при этом каждая выкатка превращается в пожар на проде, то у вас нет никакого CI/CD. У вас есть просто автоматизированная заливка кода.

Настоящий CI/CD — это в первую очередь инженерная культура доставки, а не просто конфиг в YAML-файле.

CI: Интеграция мелкими слайсами

Continuous Integration — это про постоянное подливание изменений в мейн-ветку.

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

Инженерный подход — резать огромную задачу на маленькие слайсики. Написал кусок логики — вмержил. Написал еще один — залил. Чтобы новый код не ломал продукт, мы используем feature flags о которых мы уже говорили.

Это как работа шеф-повара. Если он готовит сложное блюдо 40 минут и пробует его только перед подачей, велик риск узнать, что всё пересолено и время потрачено впустую. Программист с настроенным CI «пробует» каждый нарезанный ингредиент. Он уверен в результате на каждом этапе, потому что кодовая база растет не огромными кусками, а непрерывным потоком проверенных изменений.

CD: Смерть страницы «Технические работы»

Continuous Delivery решает проблему доступности.

Традиционный деплой — это когда мы переключаем сайт в Maintenance Mode, выкатываем код, накатываем миграции базы и надеемся, что всё заведется. Для пользователя это «окно», когда сервис недоступен. В современном мире это недопустимо.

Чтобы фича долетала до прода «по щелчку пальцев», используются механизмы атомарного деплоя:

1. Смена директорий: Мы собираем новую версию приложения в отдельной папке на сервере. Когда сборка готова и проверена, мы просто переключаем на нее симлинк. Пользователь мгновенно начинает получать данные из нового кода.
2. Контейнеризация: Приложение предсобирается в Docker-образ. В момент деплоя мы просто подменяем старый контейнер на новый.

Никаких уведомлений о технических работах. Весь процесс происходит бесшовно, потому что инфраструктура готова к подмене артефактов на лету.

Быстрая обратная связь как метрика успеха

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

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

Инженер не ждет релиза, чтобы проверить свою работу. Он проектирует систему так, чтобы любая критическая ошибка была выявлена еще до того, как код станет частью продакшн-окружения.

Ставь 🔥 если все разложилось по полочкам. А если остались вопросы по реализации или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!

10МДК | ВЕБМастер