Alex.Volkov
New member
Мы впервые занялись CI/CD около четырёх лет назад, и тогда это было для меня чем-то вроде магии: кнопка, пара часов ожидания — и новая версия уже на серверах. До этого релиз выглядел так: я локально собирал проект, прогонял тесты вручную, копировал файлы по ssh на боевой сервер, а потом молился, чтобы ничего не развалилось. Один раз я так сломал прод на полчаса — и с тех пор у меня осталось твёрдое убеждение, что ручные выкатывания слишком дороги.
Нажать чтобы Перейти на сайт
Переход дался непросто. Первое, с чем мы столкнулись, — это culture: разработчики привыкли, что сборка у каждого своя, и «у меня локально работает» стало классическим аргументом. Помогло не сколько писем, сколько наглядное сравнение: один общий pipeline, одинаковые окружения, одна и та же команда запуска у всех. Второе — тесты. Часть из них пришлось переписать и починить, зато с этого момента красный статус pipeline стал означать «релиз не выйдет», а не «ну посмотрим у прода на всякий случай».
Отдельная боль — окружения. Мы завели staging, максимально приближённый к проду, с теми же настройками и структурой базы. Это заняло больше времени, чем сама настройка CI-сервера, но именно на staging мы стали ловить те ошибки, которые раньше всплывали только у пользователей. Плюс появились миграции базы данных, которые можно применять шагами и откатывать назад, если что-то пошло не так.
Ощутимый эффект мы получили не сразу, а примерно через полгода. Релиз из двух-трёх часов ручной работы превратился в пятнадцать-двадцать минут общего времени, из которых я теперь почти не трачу. Более того, выкатываться стали все члены команды, а не только я: каждый мержит ветку, ждёт зелёную проверку и радуется, если всё прошло. Команда начала релизить часто и маленькими порциями, и это оказалось куда безопаснее, чем ежемесячные большие «страшные» релизы.
Узнать подробнее →
Разумеется, CI/CD — не серебряная пуля. Он не спасёт вас от плохо написанных тестов, от кривой архитектуры или от спешки в задачах. У нас бывали дни, когда pipeline падал по девять раз подряд из-за одного flaky-теста, и это реально выматывало. Отдельный класс проблем — связность: сломанный шаг деплоя блокирует всё, и тут важно уметь быстро откатиться на предыдущую версию, а не разбираться в тупике.
Если хотите честный совет — внедряйте постепенно. Начните с одного репозитория, одного простого pipeline и честного разговора с командой о том, зачем мы это делаем. Автоматизация не отменяет аккуратность, она просто делает аккуратные действия дешёвыми, а дорогие ошибки — заметно реже. А у вас уже есть CI/CD на ваших проектах, и что оказалось главным подводным камнём при внедрении?
По теме советую почитать: Искусственный интеллект в разработке: что реально работает сегодня
Нажать чтобы Перейти на сайтПереход дался непросто. Первое, с чем мы столкнулись, — это culture: разработчики привыкли, что сборка у каждого своя, и «у меня локально работает» стало классическим аргументом. Помогло не сколько писем, сколько наглядное сравнение: один общий pipeline, одинаковые окружения, одна и та же команда запуска у всех. Второе — тесты. Часть из них пришлось переписать и починить, зато с этого момента красный статус pipeline стал означать «релиз не выйдет», а не «ну посмотрим у прода на всякий случай».
Отдельная боль — окружения. Мы завели staging, максимально приближённый к проду, с теми же настройками и структурой базы. Это заняло больше времени, чем сама настройка CI-сервера, но именно на staging мы стали ловить те ошибки, которые раньше всплывали только у пользователей. Плюс появились миграции базы данных, которые можно применять шагами и откатывать назад, если что-то пошло не так.
Ощутимый эффект мы получили не сразу, а примерно через полгода. Релиз из двух-трёх часов ручной работы превратился в пятнадцать-двадцать минут общего времени, из которых я теперь почти не трачу. Более того, выкатываться стали все члены команды, а не только я: каждый мержит ветку, ждёт зелёную проверку и радуется, если всё прошло. Команда начала релизить часто и маленькими порциями, и это оказалось куда безопаснее, чем ежемесячные большие «страшные» релизы.
Узнать подробнее →Разумеется, CI/CD — не серебряная пуля. Он не спасёт вас от плохо написанных тестов, от кривой архитектуры или от спешки в задачах. У нас бывали дни, когда pipeline падал по девять раз подряд из-за одного flaky-теста, и это реально выматывало. Отдельный класс проблем — связность: сломанный шаг деплоя блокирует всё, и тут важно уметь быстро откатиться на предыдущую версию, а не разбираться в тупике.
Если хотите честный совет — внедряйте постепенно. Начните с одного репозитория, одного простого pipeline и честного разговора с командой о том, зачем мы это делаем. Автоматизация не отменяет аккуратность, она просто делает аккуратные действия дешёвыми, а дорогие ошибки — заметно реже. А у вас уже есть CI/CD на ваших проектах, и что оказалось главным подводным камнём при внедрении?
По теме советую почитать: Искусственный интеллект в разработке: что реально работает сегодня
