Пайплайн у вас есть. Он есть у всех: CI перестал быть предметом споров примерно тогда же, когда Docker перестал быть новостью. Именно поэтому разговор пора вести другой — не “зачем вам CI”, а можно ли верить вашему зелёному пайплайну, сколько он стоит и кто им владеет. Разбор в формате “зачем — как — чем — цена отказа” — пилот рубрики: дальше в ней будут другие практики, формат останется.

Зачем: что CI покупает, когда он уже есть

Раздел “зачем” в статье про CI обычно продаёт частую интеграцию. Вам продавать нечего: пайплайн стоит, зачем он — вы знаете. Честный вопрос 2026 года другой: что практика покупает, когда инструмент уже куплен?

Ответ дала индустрия, причём цифрами. DORA 2025 — опрос почти пяти тысяч инженеров — фиксирует: AI на работе используют 90%, пропускная способность команд с ростом AI-адопшн растёт — и нестабильность поставки растёт вместе с ней. Формулировка отчёта прямая: AI — усилитель. Он не чинит инженерную систему, а выкручивает громкость того, что в ней уже играет: у зрелых команд — скорость, у остальных — хаос. Компенсатор в отчёте назван ровно один: качество контура обратной связи — автотесты, дисциплина в репозитории, быстрый однозначный сигнал по каждому изменению.

То есть CI. Не сервер и не YAML, а контур, который на каждое изменение отвечает “хорошо” или “плохо”. Пока код писали только люди, контур страховал. Теперь, когда треть разработчиков признаётся, что мало или совсем не доверяет коду из модели (тоже DORA), он стал основным местом, где недоверие конвертируется в решение. Работа сместилась с “написать” на “убедиться” — а “убедиться” в масштабе потока, который генерит пара агентов за ночь, руками не делается. В сам пайплайн, кстати, AI команды пускают неохотно: по JetBrains State of CI/CD 2025 73% не используют его там вообще. По-моему, инстинкт здоровый: гейт, решающий “пускать ли в прод”, — последнее место, где хочется вероятностного поведения.

Отсюда рабочее определение. CI — это управление риском изменений, и у него один продукт: сигнал, которому должны верить. Зелёный пайплайн — не самоцель и не отчётность, а ответ на вопрос “сколько внимания живого инженера нужно этому изменению”. Раньше на вопрос “можно релизить?” отвечал Дима (да, Дима кочует у меня из текста в текст, потому что он есть в каждой команде). Дима больше не масштабируется: он физически не прочитает всё, что приехало за ночь. Если зелёному верить нельзя, у вас нет CI — у вас есть генератор зелёных квадратиков/галочек/полосочек: все затраты на месте, функции ни одной.

Как: шесть принципов, и Jenkins среди них по-прежнему нет

Прошлую версию этого списка я собирал бы из страхов десятилетней давности. Эта — из жалоб последних лет: каждую из шести я слышу регулярно, просто теперь они начинаются со слов “CI у нас есть, но…”.

1. Вердикт — быстрее десяти минут (максимум!), иначе это налог. Дольше — инженер переключился на другую задачу, пуши копятся пачками, красное “где-то в пачке” размывается до красного “где-то в проекте”. Медленный пайплайн — налог на каждый пуш каждого инженера, и платится он вниманием (привет контекст-свитчинг) — самым дорогим, что есть у инженера и команды. Что не влезает в десять минут, уходит во вторую очередь: ночные интеграционные, нагрузочные, длинные e2e. Кэши, инкрементальные сборки, выборочное тестирование — не “оптимизации потом”, а способ, которым десятиминутный вердикт вообще осуществим в проекте старше года.

2. Сигналу либо верят, либо его чинят. Третьего нет. Флапающий тест — не “ну бывает”, а инцидент сигнала: каждый перезапуск без чёткого диагноза обучает команду, что красное значит не “стоп”, а “попробуй ещё раз”. Индустрия наплодила инструментов — карантины, flake-бюджеты, автодетект флапов как встроенная фича CI-платформ… Но инструмент здесь вторичен. Первичен договор: перезапуск — обезболивающее, и работает оно только вместе с лечением. Тест, который “все знают, что мигает” — это дыра в сигнале, оформленная как ритуал.

3. Зелёный main — это инфраструктура, а не подвиг дисциплины. Два зелёных PR, смерженные подряд, дают красный main: каждый проверялся против базы, которой к моменту мержа уже нет. На троих это лечится меншеном в чате. На пятидесяти инженерах — очередью на мердж: GitHub merge queue, GitLab merge trains, Graphite или Aviator для любителей stacked PR. Современный разговор о ветках — вообще не про “долго ли живёт ветка” (день-два, это не обсуждается лет десять), а про время жизни PR в очереди и цену её прогона. Стоп-кран “main красный — все стоят” никуда не делся; просто теперь его дёргает автомат, а не самый смелый/опытный человек в чате.

4. Артефакт собирается один раз — и известно, из чего. Дальше один и тот же бинарь или образ промоутится по средам: тестовые — стейджи — проды. “Пересоберём начисто для прода” звучит заботливо, а означает: в прод поедет то, что не проверял никто. Добавка 2026 года: частью вердикта стало происхождение — из какого коммита артефакт собран, каким пайплайном, с какими зависимостями. Почему это перестало быть паранойей — в разделе про цену отказа.

5. Пайплайн — тонкая обёртка над скриптами. Логика сборки и проверок живёт в скриптах репозитория и может запускаться локально; YAML только вызывает их по порядку. Это лечит жанр “в CI падает, локально не воспроизводится” и радикально удешевляет переезд. Переезд — не гипотетический: по тому же опросу JetBrains 32% организаций живут сразу на двух CI-системах, ещё 9% — на трёх и больше. Миграция — не катастрофа раз в десятилетие, а фоновый режим индустрии.

6. CI — прод-система, и у неё есть владелец. Самая привилегированная прод-система компании: секреты всех окружений, право писать в registry и катить в прод. И при этом часто единственная, у которой нет ни владельца, ни мониторинга, ни бюджета — “настроили же”. Всё чаще НЕ вижу: очередь на раннеры — производственная метрика, обновление раннеров — чейндж с blast radius, минуты компьюта — статья расходов. Насколько всерьёз индустрия считает эти минуты, показал GitHub: в декабре 2025-го он объявил плату $0.002/мин за джобы даже на ваших собственных раннерах — сообщество взбунтовалось, и через несколько дней затею отложили на неопределённый срок. Сам заход красноречивее отката: минуты CI — это рынок и деньги, а не побочный расход. Если на вопрос “кто владеет пайплайном” ответ — “ну, исторически сложилось”, то владельца нет, но обычно есть заложник :)

Кому нужна каноническая формулировка основ — она у Фаулера (знаю, что никто не прочитает :)) в редакции 2024 года; здесь дальше то, чего в ней нет.

Чем: три дорожки, одна таблица

Инструмент — последний вопрос в цепочке “боль — принцип — практика — инструмент” (подробно я разбирал её в статье про карго-культ). Задают его, к сожалению, обычно первым.

Миграция между первыми двумя — отдельный вид спорта, причём массовый: те самые 32% на двух системах — это в основном команды, застрявшие в переезде на месяцы и годы. Так что вторая таблица — не страшилка, а прогноз. Что при переезде выживает, а что нет:

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

Где в этой таблице Jenkins, вынесенный в заголовок? А нигде — и это не просто так: по опросам он до сих пор массово жив в среднем и крупном энтерпрайзе. Jenkins способен реализовать все шесть принципов; беда в том, что он с той же готовностью реализует их отсутствие — свобода скриптованных джобов это позволяет. Плюс сам сервер, который надо обновлять, вечно конфликтующие плагины и Groovy, который в команде знает полтора землекопа. В новый проект в 2026-м я бы его не брал. Но если у вас живёт ухоженный Jenkins и команда довольна — это не техдолг по умолчанию: шесть принципов выше реализуются и на нём. Начните с проверки, миграция подождёт.

Про российскую дорожку: в моей практике самый частый отечественный CI-контур — по-прежнему self-hosted GitLab. GitFlic и GitVerse выбирают, когда нужен софт из реестра или полностью закрытый контур. CI там рабочий, но моложе, и экосистему готовых джобов заменяет bash (GitFlic я гонял живьём, GitVerse — пока только по докам и демо, честно). При логике-в-скриптах — жить можно; при логике-в-маркетплейсе перечитайте абзац про “занял вечность”.

Цена отказа: отказывает не сервер, а сигнал

Цену отказа без CI вы представляете и так — этот раздел не про неё. Отказ образца 2026 года выглядит иначе: пайплайн есть, работает, ест бюджет — и врёт. Два режима отказа, оба тихие.

Отказ первый: зелёный, которому никто не верит. Пайплайн на месте, стадия тестов на месте, тесты настоящие. Одна деталь:

tests:
  script:
    - ./scripts/test.sh
  allow_failure: true   # поставили "на время инцидента" - разблокировать деплой

Коммиту, который добавил эту строку, год. Сообщение коммита — “временно”. Стадия честно гоняет тесты, тесты честно падают, пайплайн честно “зеленеет”. Подделку сигнала уровня “echo вместо тестов” на ревью поймает любой стажёр — а эта строка прошла ревью легально, у неё даже была уважительная причина (возможно).

Дальше по накатанной. Флапающие перезапускают до зелёного, а каждый запуск это минуты раннеров, очередь на них — то есть деньги и время. Каждый третий хотфикс идёт со [skip ci] стоп-словом. У мейнтейнеров есть право мержить прямо в main мимо пайплайна — и им пользуются. Пре-коммит хуки поставили всем, --no-verify весь отдел выучил за неделю: обходной путь распространяется по команде быстрее любой практики. Плохой CI не просто бесполезен — он ежедневно тренирует команду обходить процессы, и натренированные люди потом обходят уже не только его. Итог: прод охраняет система, которой не верит никто, включая её авторов. По-моему, это хуже, чем не иметь CI вовсе: инфраструктура оплачена, а сигналов от неё нет.

Отказ второй: CI, который у вас угнали. Март 2025-го, атака на tj-actions/changed-files — экшон, который стоял в 23 тысячах репозиториев. Атакующие украденным токеном мейнтейнера перевесили теги экшена на коммит, дампивший память раннера прямо в логи сборки: токены, ключи, секреты всех окружений. Началось всё не с массовой рассылки, а с целевой атаки на Coinbase: CI-контур криптобиржи сочли самой перспективной дверью (та атака не удалась — но сам выбор двери показателен). Логика атакующих железная — см. принцип 6: система со всеми секретами компании и правом писать в прод, а обновляют и мониторят её как пет-проект. Что индустрия сформулировала по горячим следам: пинить экшены по SHA, а не по тегу; долгоживущие секреты менять на короткоживущий OIDC; права токена — минимальные по умолчанию. Сделали, как полагается, далеко не все.

Когда это НЕ нужно

Фирменная рубрика: без границы применимости разбор — не разбор.

Соло-прототип, хакатон, скрипт для себя — не нужно. Цена ошибки — ваше собственное время, линтер гоняется локально. Это не изменилось и не изменится.

Изменился частый перекос. Раньше карго-культом был пайплайн ради галочки; теперь всё чаще встречаю карго-культ масштаба: merge queue на команду из трёх человек, отдельная “платформенная команда” под пять репозиториев, недельный проект по selective testing в пайплайне, который идёт четыре минуты. Все приёмы из этой статьи родились от боли конкретного масштаба. Скопировать их до появления боли — значит просто воспроизвести форму. У бигтеха свои болезни, у остальных — свои. Зачем лечиться от чужих, если даже не болит?

Критерий, когда пора: появился второй активный контрибьютор — или первый пользователь, которому больно от ваших поломок. Поправка 2026 года: агент, который пушит ветки, пока вы спите, считается за второго контрибьютора — причём за того, чьи коммиты вы заведомо читаете по диагонали. Минимальный набор собирается за вечер:

# .gitlab-ci.yml - стартовый минимум
stages: [check]

lint:
  stage: check
  script: [./scripts/lint.sh]   # логика - в scripts/, принцип 5

test:
  stage: check
  script: [./scripts/test.sh]   # то же самое запускается локально

Этого достаточно. Очереди, карантины и метрики пайплайна докупите, когда заболит — по боли, а не по чек-листу.

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

git fetch --prune   # иначе половина списка - призраки удалённых веток
git for-each-ref --sort=committerdate refs/remotes --no-merged=origin/main 
  --format='%(committerdate:short) %(refname:short)' | head

И напишите цифру в комментариях. У меня рекорд — пара лет, причём ветка моя. Уверен, что перебьёте ))

Раньше в цикле:

• “Карго-культ DevOps: чек-лист самопроверки”

• “Мидл — это не три года опыта. Грейды в DevOps как типы ответственности”