IrinaIvanov
New member
Я руководил небольшой продуктовой командой, и наш CI/CD долго был предметом гордости: зелёные галочки, автотесты, автодеплой на стенд. Но однажды я заметил, что релизы стали занимать почти час, а то и больше. Разработчики ждали пайплайн, переключались на другие задачи и теряли фокус. В итоге CI/CD из ускорителя превратился в узкое горлышко, которое тормозило и разработку, и бизнес.
Первая проблема была в философии. Мы пытались прогнать на каждом коммите всё: линтеры, unit-тесты, интеграционные, миграции, сборку образов и полный e2e. Казалось, что чем больше проверок, тем надёжнее. На практике пайплайн рос, как снежный ком, а обратная связь приходила через 40–60 минут. К этому времени автор изменения уже забывал детали, а исправлять баг в чужом контексте было дорого.
Мы начали с замеров, а не с модных инструментов. Разбили пайплайн на этапы и посчитали, сколько времени уходит на ожидание раннера, установку зависимостей, сборку, тесты и ручные апрувы. Оказалось, что 70 процентов времени съедали e2e-тесты и отсутствие кэша, а ещё 15 минут мы теряли в очереди на единственный мощный раннер. Это был неприятный, но полезный сюрприз.
Дальше мы перестроили пайплайн по принципу быстрой и полной проверки. На pull request запускали только линтеры, unit-тесты и smoke-набор e2e — всё укладывалось в 5–7 минут. Полный e2e, нагрузочные и миграционные проверки уходили в ночной запуск или перед релизом. Добавили кэш зависимостей и Docker-слоёв, параллельные job-ы, path-фильтры для монорепозитория и автоскейлинг раннеров. Это дало самый заметный прирост.
Параллельно мы поменяли процесс. Перешли на маленькие PR, trunk-based development и feature flags. Ручные согласования заменили на автоматические политики: если зелёный пайплайн и есть одобрение кода, деплой идёт сам. Для продакшена оставили канареечный релиз и быстрый откат. Ещё стали измерять DORA-метрики: lead time, частоту деплоев, MTTR и change failure rate. Это помогло не спорить о вкусах, а видеть цифры.
Через несколько недель релиз сократился с 60 минут до 20, а затем до 12–15 минут. Частота деплоев выросла примерно в три раза, lead time упал ещё сильнее. Команда перестала бояться релизов: вместо ночных героических выкаток появились обычные рабочие дни. Ошибки, конечно, случались, но откатывались быстрее, потому что пайплайн стал предсказуемым.
Что я советую читателям? Начните с метрик и найдите самое дорогое звено. Не тащите все тесты на каждый коммит: разделите их на быстрые и полные. Кэшируйте всё, что можно, параллельте независимые шаги и не жалейте денег на нормальные раннеры. Воспринимайте CI/CD как продукт для команды: у него есть пользователи, SLA и бэклог улучшений. И не забывайте про культуру маленьких изменений.
А какой неочевидный ускоритель CI/CD сработал именно у вас: кэш, параллельность, разделение тестов или что-то ещё? Поделитесь опытом — вместе мы соберём отличную копилку решений.
Первая проблема была в философии. Мы пытались прогнать на каждом коммите всё: линтеры, unit-тесты, интеграционные, миграции, сборку образов и полный e2e. Казалось, что чем больше проверок, тем надёжнее. На практике пайплайн рос, как снежный ком, а обратная связь приходила через 40–60 минут. К этому времени автор изменения уже забывал детали, а исправлять баг в чужом контексте было дорого.
Мы начали с замеров, а не с модных инструментов. Разбили пайплайн на этапы и посчитали, сколько времени уходит на ожидание раннера, установку зависимостей, сборку, тесты и ручные апрувы. Оказалось, что 70 процентов времени съедали e2e-тесты и отсутствие кэша, а ещё 15 минут мы теряли в очереди на единственный мощный раннер. Это был неприятный, но полезный сюрприз.
Дальше мы перестроили пайплайн по принципу быстрой и полной проверки. На pull request запускали только линтеры, unit-тесты и smoke-набор e2e — всё укладывалось в 5–7 минут. Полный e2e, нагрузочные и миграционные проверки уходили в ночной запуск или перед релизом. Добавили кэш зависимостей и Docker-слоёв, параллельные job-ы, path-фильтры для монорепозитория и автоскейлинг раннеров. Это дало самый заметный прирост.
Параллельно мы поменяли процесс. Перешли на маленькие PR, trunk-based development и feature flags. Ручные согласования заменили на автоматические политики: если зелёный пайплайн и есть одобрение кода, деплой идёт сам. Для продакшена оставили канареечный релиз и быстрый откат. Ещё стали измерять DORA-метрики: lead time, частоту деплоев, MTTR и change failure rate. Это помогло не спорить о вкусах, а видеть цифры.
Через несколько недель релиз сократился с 60 минут до 20, а затем до 12–15 минут. Частота деплоев выросла примерно в три раза, lead time упал ещё сильнее. Команда перестала бояться релизов: вместо ночных героических выкаток появились обычные рабочие дни. Ошибки, конечно, случались, но откатывались быстрее, потому что пайплайн стал предсказуемым.
Что я советую читателям? Начните с метрик и найдите самое дорогое звено. Не тащите все тесты на каждый коммит: разделите их на быстрые и полные. Кэшируйте всё, что можно, параллельте независимые шаги и не жалейте денег на нормальные раннеры. Воспринимайте CI/CD как продукт для команды: у него есть пользователи, SLA и бэклог улучшений. И не забывайте про культуру маленьких изменений.
А какой неочевидный ускоритель CI/CD сработал именно у вас: кэш, параллельность, разделение тестов или что-то ещё? Поделитесь опытом — вместе мы соберём отличную копилку решений.