Почему Jenkins становится дорогим

В сфере искусственного интеллекта произошло заметное событие. N1KPJl 1 час назад Почему Jenkins становится дорогим Средний 10 мин 2. 5K Блог компании Сбер DevOps * Ретроспектива Jenkins в больших организациях почти никогда не живёт сам по себе. Обычно он уже врос в процессы, завязан на внутренний оркестратор, плагины, доступы, аудит, безопасность и десятки интеграций.

Поэтому в реальной жизни команды чаще не «переезжают с Jenkins», а годами пытаются добиться более скромной цели: чтобы он хотя бы перестал мешать. Мы пришли к этим выводам не как владельцы одного pipeline, а как команда, через которую проходит автоматизация сразу для нескольких продуктовых команд. Особенно узнаваем этот сюжет для внутренних DevOps-, SRE- или платформенных команд, которые по факту работают как сервисный слой для множества продуктовых команд.

Технические детали

Снаружи это выглядит безобидно: есть Jenkins, есть набор pipelines, есть типовые интеграции, есть просьбы «добавить ещё один шаг», «проверку», «уведомление», «джобу», «обвязку». Но если через один и тот же Jenkins у вас проходит автоматизация сразу для многих команд, то почти любое локально удобное решение рано или поздно начинает масштабировать не только пользу, но и сложность. И очень часто лечат в этот момент не причину, а симптомы.

Почти все решения вокруг Jenkins сначала кажутся разумными. Более того, многие из них действительно работают и дают эффект. Проблема начинается позже: когда автоматизация растёт, вчерашнее удобство начинает превращаться в источник legacy, а цена изменений растёт быстрее, чем команда успевает это заметить.

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

Отраслевые последствия

Сам Jenkins в Pipeline Best Practices прямо рекомендует использовать Groovy в pipeline как «glue», а тяжёлую обработку и интеграции выносить во внешние шаги. Если упростить, то роль Groovy здесь сводится к трём вещам:Принимать решения: проверять условия, флаги, ветки. Передавать параметры между шагами.

Вызывать внешние инструменты: скрипты, контейнеры, утилиты. «Соседние» подходы давно развивают ту же мысль в других формах: Dagger, Tekton, Argo Workflows. Ценность этой статьи в другом: она про то, какие промежуточные решения ломаются первыми, когда вы не можете выбросить Jenkins и уже не готовы платить за жизнь логики внутри.

Часть приведённых здесь результатов не является лабораторным бенчмарком, это опыт нашей эксплуатации и экспертные оценки команды на характерных сценариях. Симптомы, на которые слишком долго не обращают вниманиеВначале всё выглядит безобидно: несколько pipelines, немного Groovy, несколько вызовов API, проверки, статусы, уведомления. Потом автоматизация разрастается, и картина становится знакомой многим.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.