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

Мы пришли к этим выводам не как владельцы одного pipeline, а как команда, через которую проходит автоматизация сразу для нескольких продуктовых команд.

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

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

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

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

Если упростить, то роль Groovy здесь сводится к трём вещам:

1. Принимать решения: проверять условия, флаги, ветки.

2. Передавать параметры между шагами.

3. Вызывать внешние инструменты: скрипты, контейнеры, утилиты.

«Соседние» подходы давно развивают ту же мысль в других формах: Dagger, Tekton, Argo Workflows.

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

Часть приведённых здесь результатов не является лабораторным бенчмарком, это опыт нашей эксплуатации и экспертные оценки команды на характерных сценариях.

Симптомы, на которые слишком долго не обращают внимание

Вначале всё выглядит безобидно: несколько pipelines, немного Groovy, несколько вызовов API, проверки, статусы, уведомления. Потом автоматизация разрастается, и картина становится знакомой многим. Код дублируется между pipelines, а логика размазывается по Jenkinsfile, shared library, параметрам и плагинам; любое изменение превращается в цикл commit -> запуск -> анализ лога -> повтор, онбординг растягивается с дней до месяцев, а controller начинает ощущаться как дефицитный ресурс.

В этот момент у команды обычно появляется соблазн «чуть-чуть улучшить текущую модель» вместо того, чтобы пересмотреть саму границу ответственности между оркестрацией и исполнением. Именно здесь и начинается накопление дорогого legacy.

Решение №1. Исполняемая логика прямо в Jenkinsfile

Это самый старый и самый дорогой способ накопить технический долг.

На раннем этапе у нас Jenkins pipelines прямо выполняли действия релизного процесса: составляли отчёты по тестированию, проверяли согласования, двигали статусы релиза в Jira, проверяли quality gate, выполняли шаги чек-листа и отправляли уведомления.

Код pipelines располагался прямо в Jenkins. Для нескольких сценариев это кажется рациональным, но для десятков сценариев это превращается в свалку интеграций и бизнес-логики в одном месте.

pipeline {
    agent any
    stages {
        stage('Проверка релиза') {
            steps {
                script {
                    def releaseInfo = httpRequest(
                        url: "${env.RELEASE_API_URL}/releases/${params.RELEASE_ID}",
                        httpMode: 'GET',
                        authentication: 'release-api-token',
                        validResponseCodes: '200'
                    )

                    def approvals = httpRequest(
                        url: "${env.JIRA_URL}/rest/api/2/issue/${params.RELEASE_ID}",
                        httpMode: 'GET',
                        authentication: 'jira-token',
                        validResponseCodes: '200'
                    )

                    def gateResponse = httpRequest(
                        url: "https://sonar.domain.local/api/qualitygates/project_status?projectKey=${params.RELEASE_ID}",
                        httpMode: 'GET',
                        authentication: 'sonar-token',
                        validResponseCodes: '200'
                    )

                    def releaseJson = readJSON text: releaseInfo.content
                    def approvalsJson = readJSON text: approvals.content
                    def gateJson = readJSON text: gateResponse.content

                    if (releaseJson.status != 'READY_FOR_CHECK') {
                        error("Релиз не готов к проверке")
                    }

                    if (!approvalsJson.fields.labels.contains('approved-by-change-board')) {
                        error("Для релиза отсутствуют обязательные согласования")
                    }

                    if (gateJson.projectStatus.status != 'OK') {
                        error("Quality Gate не пройден")
                    }
                }
            }
        }
    }
}

Здесь проблема не в «длинном Jenkinsfile», а в том, что Jenkins становится местом жизни логики. Это важно не только эстетически. Сложный Groovy в pipeline выполняется на контроллере. Сам Jenkins официально рекомендует использовать Groovy как «glue», а не как основной слой обработки. В тех же best practices отдельно сказано избегать тяжёлого Groovy-кода, JsonSlurper, HttpRequest и прочих конструкций, которые нагружают контроллер.

То есть это не вопрос вкуса, а вопрос на какой машине исполняется логика и кто за это платит процессором и памятью. Если у вас мало автоматизации, то это можно долго не замечать. А если много, то контроллер рано или поздно начинает получать не оркестрацию, а чужую бизнес-логику под видом pipeline DSL.

Решение №2. Считать Shared Library архитектурным лечением

Когда хаос в Jenkinsfile становится слишком очевидным, первое естественное движение почти всегда одно и то же: вынести повторяющийся код в Jenkins Shared Library.

Мы сделали то же самое. В библиотеку ушли общие методы, работа с конфигурацией и helper-классы для интеграций с Jira, Confluence, BitBucket, Sonar, Nexus и другими системами. Эффект тоже был вполне реальный: дублирования стало меньше, изменения стало проще раскатывать, интеграции централизовались.

Проблема в том, что это лечит DRY (Don’t Repeat Yourself — Не повторяйся), но не архитектуру. Но после появления shared library не меняется главное: логика всё ещё живёт внутри экосистемы Jenkins, разработка и отладка по-прежнему крутятся вокруг него, точка исполнения не меняется, а контроллер всё ещё участвует в жизни этой логики сильнее, чем хотелось бы.

Более того, сам Jenkins в документации отдельно предупреждает избегать очень больших shared libraries: их нужно загружать, они увеличивают накладные расходы, а при массовом использовании цена становится заметной. Именно поэтому shared library очень легко переоценить. Она полезна как слой переиспользования, и плоха как оправдание мысли «архитектурную проблему организации автоматизации мы уже решили».

У нас это было видно даже по цене входа. По внутренней оценке команды, онбординг в подходе с Jenkins shared library занимал более 1,5 месяцев: человеку нужно было одновременно понять Jenkins, Groovy, особенности shared library и локальные соглашения команды.

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

Решение №3. Сменить язык, не меняя модель исполнения

Следующий ход обычно кажется взрослым. Раз Groovy в Jenkins неудобен и дорог, давайте вынесем логику в нормальный язык. В нашем случае это был Python.

Выбор был прагматичным: у команды уже был опыт, экосистема библиотек была заметно богаче и удобнее, чем в Groovy-слое Jenkins, а локальная разработка, тестирование и отладка сразу становились менее мучительными.

Но тут есть ловушка. Очень легко перепутать две разные вещи: «мы вынесли логику из Groovy» и «мы вынесли логику из модели исполнения Jenkins». Схема при этом оставалась старой: Jenkins делал checkout, подготавливал Python tool, создавал venv, ставил зависимости из requirements.txt, запускал Python-скрипт, принимал результат обратно и уже через плагины с pipeline-обвязкой оформлял статус, описание и следующий шаг.

def prepareVenv(requirementsPath = false, indexUrl = "http://mirror.domain.ru/pypi/simple/", trustedHost = "mirror.domain.ru") {
    def PYTHON_REPOSITORY = "--index-url=${indexUrl} --trusted-host=${trustedHost} --disable-pip-version-check"
    sh "python3 -m venv VirtualEnv"
    if (requirementsPath) {
        sh """
            source VirtualEnv/bin/activate
            python3 -m pip install --upgrade pip ${PYTHON_REPOSITORY}
            python3 -m pip install --upgrade setuptools ${PYTHON_REPOSITORY}
            python3 -m pip install -r ${requirementsPath} ${PYTHON_REPOSITORY}
        """
    }
}

Сменить язык, не меняя модель исполнения, дает очень важный результат: существенную часть логики стало возможно писать и запускать локально, цикл разработки заметно ускорился, а код стало проще тестировать именно как код, а не как поведение pipeline.

По нашей экспертной оценке, на 100 итераций отладки в старом Jenkins/Groovy-подходе уходило около 13 часов, а в Python-подходе — около 5 часов. Это не научный бенчмарк, а практические тесты команды на типовом сценарии. Но это хорошо показывает цену цикла: раньше изменение почти всегда означало коммит, ожидание запуска и разбор Jenkins-логов, а потом значимая часть работы ушла в обычную локальную разработку с debugger.

Проблема в другом: мы сменили язык, но не сменили момент и место подготовки среды исполнения.

Это было видно даже по времени до старта полезной логики:

• ранний Groovy-подход: около 55 секунд;

• Python без PEX: около 43 секунд;

• Python с PEX: около 35 секунд.

Улучшение есть, но архитектурного перелома нет. Пока Jenkins при каждом запуске всё ещё участвует в сборке среды выполнения, вы уже сделали код удобнее, но ещё не избавились от главного налога.

Решение №4. Прятать логику в YAML, step-ы и Jinja

После того как логика переехала в Python, следующий соблазн выглядел очень привлекательно: сделать поверх всего этого декларативный конструктор pipeline.

Идея была простой: YAML-манифест pipeline, YAML-манифесты шагов и Python-код, который эти шаги реализует. На бумаге это выглядело красиво, потому что обещало низкий порог входа, переиспользуемые кирпичики и описание pipeline как бизнес-сценариев.

На практике ограничения проявились быстро. Под каждый нетривиальный pipeline начинали появляться новые step-ы, реальное переиспользование оказывалось намного ниже ожиданий, разработчики тратили время на выдумывание «универсальных» action, а Jinja с YAML очень быстро превращались в плохо читаемую смесь. Отладка при этом расползалась сразу по трём слоям: Python-коду, YAML-манифестам и Jinja-выражениям.

Это важный момент, потому что здесь команды очень любят ошибаться в диагнозе. Проблема не в том, что «YAML плохой». Проблема в том, что алгоритмическую сложность нельзя безнаказанно спрятать в декларативную форму.

Если внутри процесса уже есть сложные условия, ветвления, циклы, вычисления и неочевидные зависимости между шагами, то low-code оболочка почти неизбежно начинает выращивать собственный недоязык программирования. Только без нормальной типизации, тестов, рефакторинга и удобной отладки.

Итог такого этапа почти всегда один и тот же: вы вроде бы делали систему «для простоты», а получили ещё один слой абстракции, который усложняет всё вокруг.

Решение №5. Ускорять старую схему вместо того, чтобы сломать её

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

У нас такой попыткой был PEX. Логика была понятной: если ускорить упаковку и развёртывание среды исполнения для Python, то, возможно, этого уже хватит.

Если смотреть только на время до старта полезной логики:

• без PEX: около 43 секунд;

• с PEX: около 35 секунд.

Иногда в слабой нагрузке экономия доходила примерно до 30 секунд или 1 минуты. В периоды нагрузки эффект становился ещё менее заметным. То есть PEX оказался полезным, но не финальным. Он улучшал старую модель, а не отменял её.

Корневая проблема оставалась прежней: среда исполнения всё ещё готовилась слишком поздно, прямо во время исполнения pipeline. Именно здесь стало окончательно понятно, что основной выигрыш лежит не в «ещё чуть-чуть лучше упаковать Python», а в том, чтобы вообще перестать собирать среду исполнения в момент запуска.

Что в итоге сработало

Рабочее решение оказалось довольно прямолинейным: заранее собирать образ с проектом и зависимостями и запускать его на динамическом агенте в Kubernetes. В этой модели Jenkins поднимает среду, прокидывает нужные переменные и доступы, вызывает среду исполнения и получает результат обратно. То есть делает именно то, что от него и требуется: оркестрирует запуск, а не живёт чужой логикой.

pipeline {
    agent {
        kubernetes {
            cloud 'kubernetes-dev3'
            yaml """
spec:
  containers:
    - name: jnlp
      image: .../jenkins-agent@sha256:...
    - name: project
      image: .../project-runtime@sha256:...
      command: ['sleep']
      args: ['99d']
            """
        }
    }

    stages {
        stage('run') {
            steps {
                script {
                    container('project') {
                        withApprolesEnvs(APPROLE_CREDENTIALS_MAPPING) {
                            sh "uv run project-runtime --version"
                            sh "uv run project-runtime pipeline run -n hello"
                        }
                    }
                }
            }
        }
    }
}

Практический эффект здесь уже был не косметическим. Время до запуска полезной логики сократилось примерно до 16 секунд: в среднем около 12 секунд уходило на ожидание и создание агента (минимум 4 секунды, максимум 35 секунд), ещё около 4 секунд на его подготовку (минимум 4 секунды, максимум 5 секунд). Главное же было не во времени запуска, а в смене модели: среда исполнения перестала собираться на лету, логика стала воспроизводимой и переносимой, а зависимость от конкретного Jenkins-agent заметно уменьшилась.

Если сравнивать с ранним Groovy-подходом, то время до запуска полезной логики сократилось примерно с 55 секунд до 16 секунд, то есть больше чем в 3 раза. И это был первый этап, где мы улучшили не только удобство разработки, но и саму модель исполнения.

Почему это оказалось лучше именно для нас

После всех промежуточных попыток главный вывод оказался неприятно простым: проблема была не в Groovy, не в YAML, не в отсутствии PEX и даже не в том, что нам «нужен был Python». Проблема была в том, что Jenkins слишком долго оставался местом, где живёт исполняемая логика.

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

Как только Jenkins стал тонким оркестратором запуска, а логика переехала в обычный код и готовый образ со средой исполнения, большая часть этих налогов перестала быть системообразующей.

Когда всё это действительно не нужно

Было бы нечестно заканчивать этот текст лозунгом «все срочно выносите логику из Jenkins в образы». Такой подход не нужен, если у вас мало pipelines, контроллер не испытывает заметной нагрузки, логика действительно сводится к orchestration glue, команда не готова владеть своим образом со средой исполнения или у вас просто нет инфраструктуры для динамических агентов в Kubernetes. Вполне может оказаться, что стоимость поддержки образа будет выше, чем выгода от смены модели.

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

Просто это уже другой класс проблем. Не проблема «мы случайно превратили Jenkins в платформу исполнения чужой логики», а проблема владения собственной средой исполнения.

Вывод

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

Сначала команды пишут логику прямо в Jenkinsfile. Потом лечат это shared library. Потом меняют язык, не меняя модель исполнения. Потом пытаются спрятать алгоритмы в YAML. Потом ускоряют упаковку среды исполнения, которую вообще не должны были собирать в момент запуска. И только потом приходят к неприятно простому выводу:

Jenkins полезен, когда он оркестрирует и Jenkins дорог, когда в нём живёт исполняемая логика.

В нашем случае самый заметный выигрыш дал не новый язык сам по себе и не очередная абстракция поверх pipeline DSL, а разделение оркестрации и исполнения: Jenkins поднимает среду и запускает готовую среду исполнения, а не пытается быть местом разработки, упаковки и жизни автоматизации.