Irina_M748
New member
Многие команды начинают внедрение CI/CD с покупки мощного сервера и установки Jenkins, а потом удивляются, почему пайплайн никто не пользуется. Я проходил этот путь дважды и усвоил главный урок: начинать нужно не с инструментов, а с автоматизации самого простого — сборки и запуска тестов. На первом проекте мы полгода строили идеальную инфраструктуру, а затем выяснилось, что половина тестов ненадёжна, и каждый прогон красный. Инженеры быстро потеряли доверие к системе и вернулись к ручным сборкам.
Нажать чтобы Перейти на сайт
С чего реально начать: возьмите один небольшой сервис и автоматизируйте его сборку по коммиту. Дальше добавьте прогон тестов, даже если их пока немного, и упаковку артефакта. Только после этого думайте о развёртывании. Мы намеренно отложили автоматический деплой на несколько спринтов — сначала команда должна привыкнуть к тому, что каждое изменение проверяется одинаково и предсказуемо.
Вторая ошибка, которую я видел и в своей команде, и у коллег, — это попытка сделать идеальный пайплайн сразу: блокеры на все проверки, обязательные ревью каждого файла, обязательное покрытие 80 процентов. Такие правила создают сопротивление. Люди начинают обходить систему: коммитят «чтобы собралось», а не чтобы работало. Мы пошли по пути постепенного ужесточения — сначала гейт на критичные проверки, затем расширяем по мере роста надёжности самих проверок.
Ещё важный момент — метрики. Мы долго не измеряли время сборки, время до деплоя и количество откатов, и поэтому не замечали, что пайплайн разросся до 40 минут. После того, как мы ввели замер и начали еженедельно смотреть на дашборд, выяснилось, что треть времени уходит на интеграционные тесты, которые можно параллелить. Оптимизация заняла две недели и освободила команде примерно шесть часов в неделю.
Узнать подробнее →
Отдельно скажу про людей, а не про технологии. CI/CD ломается именно там, где никто не отвечает за поддержку пайплайна. У нас появился выделенный инженер, который владел этими скриптами как кодом — с ревью, версионированием и документацией. Это не означает, что он делает всё сам, но ответственность должна быть закреплена. Иначе через полгода пайплайн превращается в непонятную конструкцию, которую боятся трогать.
Какой у вас сейчас главный тормоз на пути к стабильному CI/CD — сами процессы, инструменты или отношения в команде?
По теме советую почитать: Почему бизнесу нужен свой код, а не чужие шаблоны
Нажать чтобы Перейти на сайтС чего реально начать: возьмите один небольшой сервис и автоматизируйте его сборку по коммиту. Дальше добавьте прогон тестов, даже если их пока немного, и упаковку артефакта. Только после этого думайте о развёртывании. Мы намеренно отложили автоматический деплой на несколько спринтов — сначала команда должна привыкнуть к тому, что каждое изменение проверяется одинаково и предсказуемо.
Вторая ошибка, которую я видел и в своей команде, и у коллег, — это попытка сделать идеальный пайплайн сразу: блокеры на все проверки, обязательные ревью каждого файла, обязательное покрытие 80 процентов. Такие правила создают сопротивление. Люди начинают обходить систему: коммитят «чтобы собралось», а не чтобы работало. Мы пошли по пути постепенного ужесточения — сначала гейт на критичные проверки, затем расширяем по мере роста надёжности самих проверок.
Ещё важный момент — метрики. Мы долго не измеряли время сборки, время до деплоя и количество откатов, и поэтому не замечали, что пайплайн разросся до 40 минут. После того, как мы ввели замер и начали еженедельно смотреть на дашборд, выяснилось, что треть времени уходит на интеграционные тесты, которые можно параллелить. Оптимизация заняла две недели и освободила команде примерно шесть часов в неделю.
Узнать подробнее →Отдельно скажу про людей, а не про технологии. CI/CD ломается именно там, где никто не отвечает за поддержку пайплайна. У нас появился выделенный инженер, который владел этими скриптами как кодом — с ревью, версионированием и документацией. Это не означает, что он делает всё сам, но ответственность должна быть закреплена. Иначе через полгода пайплайн превращается в непонятную конструкцию, которую боятся трогать.
Какой у вас сейчас главный тормоз на пути к стабильному CI/CD — сами процессы, инструменты или отношения в команде?
По теме советую почитать: Почему бизнесу нужен свой код, а не чужие шаблоны