Декларативный vs. Скриптовый: Выбор синтаксиса конвейера Jenkins

Конвейер Jenkins предоставляет два способа написания Jenkinsfile: декларативный и скриптовый. Оба позволяют собирать, тестировать и развертывать приложения, но они предлагают разные компромиссы в читаемости, валидации и гибкости Groovy.

Если ваша команда выбирает синтаксис для нового конвейера, начните с рабочего процесса, который вам нужно будет поддерживать через шесть месяцев. Декларативный синтаксис обычно легче читать и проверять. Скриптовый предоставляет более прямой контроль над Groovy, когда конвейер действительно требует динамического поведения.

Понимание конвейеров Jenkins

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

Jenkins Pipeline as Code предоставляет несколько ключевых преимуществ:

Контроль версий: Jenkinsfile хранится в системе контроля версий, как и код приложения, что обеспечивает версионирование, аудит и совместную работу.
Повторяемость: Обеспечивает согласованное выполнение процесса доставки в разных средах и запусках.
Прозрачность: Предоставляет четкое и понятное представление всего процесса доставки.
Устойчивость: Конвейеры могут переживать перезапуски мастера Jenkins.
Расширяемость: С помощью общих библиотек сложная логика может быть абстрагирована и повторно использована.

Декларативные конвейеры

Декларативный конвейер — это более новый, структурированный синтаксис, предназначенный для упрощения написания и понимания конвейеров. Он предоставляет структурированный подход с предопределенными блоками, что помогает командам поддерживать согласованность Jenkinsfile.

Характеристики и синтаксис

Декларативные конвейеры обеспечивают определенную структуру, задаваемую блоками верхнего уровня, такими как pipeline, agent, stages, steps, post, environment, parameters, options, triggers, tools, input и when. Эта структура упрощает определение конвейера, предоставляя четкие границы для различных частей рабочего процесса.

Вот базовая структура декларативного конвейера:

pipeline {
    agent any // Или 'label', 'docker' и т.д.

    stages {
        stage('Build') {
            steps {
                echo 'Сборка приложения...'
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                echo 'Запуск тестов...'
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                echo 'Развертывание в production...'
                script {
                    // При необходимости сюда можно поместить скриптовую логику
                    // Например, вызов функции общей библиотеки
                    // mySharedLibrary.deployApplication()
                }
            }
        }
    }

    post {
        always {
            echo 'Конвейер завершен.'
        }
        success {
            echo 'Конвейер выполнен успешно!'
        }
        failure {
            echo 'Конвейер завершился ошибкой.'
        }
    }
}

Преимущества декларативных конвейеров

Простота и читаемость: Предопределенная структура делает конвейеры легкими для чтения и понимания даже для неспециалистов. Это больше похоже на файл конфигурации.
Структурированный подход: Обеспечивает соблюдение лучших практик и согласованность между конвейерами, снижая кривую обучения и вероятность ошибок.
Встроенные функции: Предлагает богатый набор встроенных функций для распространенных шаблонов CI/CD, таких как условное выполнение (when), действия после сборки (post), параллельное выполнение этапов и различные опции для управления потоком конвейера.
Легче в изучении: Разработчики без глубоких знаний Groovy могут быстро начать работу благодаря структурированному синтаксису.
Валидация: Jenkins может проверять больше структуры до выполнения, поскольку декларативный синтаксис имеет более строгие правила.

Ограничения декларативных конвейеров

Меньшая гибкость: Жесткая структура может быть ограничивающей для высокосложных или динамических рабочих процессов, требующих пользовательской логики Groovy вне предопределенных блоков.
Ограниченный прямой доступ к Groovy: Хотя блок script можно использовать для внедрения скриптового синтаксиса конвейера, чрезмерное использование может подорвать преимущества декларативного синтаксиса и сделать конвейер трудным для чтения.

Когда использовать декларативные конвейеры

Декларативные конвейеры являются рекомендуемым выбором для большинства распространенных сценариев CI/CD. Они идеально подходят для:

Команд, новых для Jenkins или Pipeline as Code.
Проектов с простыми или умеренно сложными процессами сборки, тестирования и развертывания.
Обеспечения согласованности и поддерживаемости многих конвейеров.
Использования встроенных функций Jenkins для распространенных шаблонов, таких как параллельное выполнение, условные этапы и уведомления.

Скриптовые конвейеры

Скриптовый конвейер, построенный непосредственно на языке программирования Groovy, был оригинальным синтаксисом для Jenkins Pipeline as Code. Он предлагает максимальную гибкость и мощность, позволяя разработчикам реализовывать высоконастраиваемые и динамические потоки автоматизации.

Характеристики и синтаксис

Скриптовые конвейеры выполняются последовательно сверху вниз, как традиционный скрипт Groovy. Они используют полный синтаксис Groovy и используют DSL (Domain Specific Language) конвейера Jenkins через методы, такие как node, stage, checkout, sh, git и т.д. Это обеспечивает прямой доступ к API Jenkins и полную мощь языка Groovy.

Вот базовая структура скриптового конвейера:

node('my-agent-label') {
    stage('Prepare') {
        echo 'Подготовка рабочей области...'
        checkout scm
    }

    stage('Build') {
        echo 'Сборка приложения...'
        try {
            sh 'mvn clean install'
        } catch (err) {
            echo "Сборка не удалась: ${err}"
            // Пользовательская обработка ошибок
            currentBuild.result = 'FAILURE'
            throw err
        }
    }

    stage('Test') {
        echo 'Запуск тестов...'
        // Динамическое определение наборов тестов
        def testSuites = sh(script: 'find tests -name "*.test"', returnStdout: true).trim().split('\n')
        if (testSuites.isEmpty()) {
            echo 'Тесты не найдены.'
        } else {
            for (suite in testSuites) {
                echo "Запуск набора тестов: ${suite}"
                sh "./run-test.sh ${suite}"
            }
        }
    }

    stage('Deploy') {
        // Сложная условная логика
        if (env.BRANCH_NAME == 'main' && currentBuild.currentResult == 'SUCCESS') {
            echo 'Развертывание в production...'
            sh './deploy-prod.sh'
        } else if (env.BRANCH_NAME == 'develop') {
            echo 'Развертывание в staging...'
            sh './deploy-staging.sh'
        } else {
            echo 'Для этой ветки развертывание не выполняется.'
        }
    }

    // Действия после сборки могут быть реализованы с помощью try-finally блоков или пользовательской логики
    // Например, отправка уведомлений
    if (currentBuild.result == 'SUCCESS') {
        echo 'Конвейер выполнен успешно!'
        // notifySuccess()
    } else {
        echo 'Конвейер завершился ошибкой.'
        // notifyFailure()
    }
}

Преимущества скриптовых конвейеров

Максимальная гибкость: Предоставляет полную мощь Groovy, позволяя реализовывать высокосложную и динамическую логику, пользовательские циклы, обработку ошибок и манипуляции с данными.
Прямой доступ к API Jenkins: Предоставляет больше возможностей для использования API Jenkins и Groovy, хотя некоторые операции все еще зависят от плагинов, разрешений и песочницы безопасности скриптов.
Динамическое поведение: Идеально подходит для рабочих процессов, требующих динамического выделения агентов, параллельного выполнения на основе условий выполнения или продвинутого управления ресурсами.
Расширяемость: Отлично подходит для создания сложных общих библиотек, которые инкапсулируют повторно используемую, сложную логику для декларативных конвейеров.

Ограничения скриптовых конвейеров

Более крутая кривая обучения: Требует глубокого понимания Groovy, что может быть барьером для команд, не знакомых с языком.
Меньшая структурированность: Без строгой структуры конвейеры могут стать несогласованными и трудными для чтения или поддержки в разных проектах или разработчиках.
Подверженность ошибкам: Гибкость Groovy означает больше возможностей для ошибок кодирования и меньше встроенной валидации по сравнению с декларативным синтаксисом.
Проблемы с читаемостью: Сложные скриптовые конвейеры могут быстро стать трудными для анализа и понимания, что затрудняет совместную работу и устранение неполадок.
Меньше специфичного для конвейера синтаксиса: Многие распространенные шаблоны CI/CD (такие как действия post или условия when) должны быть реализованы вручную с использованием конструкций Groovy (например, try-catch-finally, операторы if).

Декларативный vs. Скриптовый: Сравнение бок о бок

Чтобы обобщить различия, вот сравнительная таблица:

Особенность	Декларативный конвейер	Скриптовый конвейер
Структура синтаксиса	Структурированный, предопределенные блоки верхнего уровня.	Гибкий, на основе Groovy, последовательное выполнение.
Кривая обучения	Легче для новичков, требуется меньше знаний Groovy.	Круче, требуется опыт в Groovy.
Читаемость	Высокая благодаря структурированным блокам и четкому синтаксису.	Может быть низкой для сложных скриптов, зависит от стиля разработчика.
Гибкость	Ограничена предопределенными структурами; блоки `script` для Groovy.	Неограниченная, полная мощь Groovy.
Встроенные функции	Богатый набор для распространенных шаблонов CI/CD (`post`, `when`, `parallel`).	Требует ручной реализации с использованием конструкций Groovy.
Обработка ошибок	Блоки `post` для глобальных или этапных действий.	Ручные блоки `try-catch-finally`.
Расширяемость	Использует общие библиотеки для сложной логики Groovy.	Напрямую пишет сложную логику Groovy. Часто создает общие библиотеки.
Управление агентом	Глобальный `agent` или `agent` на уровне этапа.	Блоки `node`, можно определять агентов где угодно.
Сценарии использования	Стандартные рабочие процессы CI/CD, простая и умеренная сложность.	Высокодинамичные, сложные, пользовательские рабочие процессы; разработка общих библиотек.
Ощущение JSON/YAML	Ближе к языкам конфигурации.	Чистый язык программирования.

Выбор правильного синтаксиса

При выборе между декларативным и скриптовым конвейерами учитывайте следующие факторы:

Опыт команды в Groovy: Если вашей команде не хватает сильных навыков Groovy, декларативный синтаксис будет иметь гораздо более пологую кривую обучения и способствовать более быстрому внедрению.
Сложность рабочего процесса: Для большинства стандартных рабочих процессов CI/CD (сборка, тестирование, развертывание) декларативный синтаксис вполне подходит и часто превосходит скриптовый благодаря своей читаемости и встроенным функциям. Для высокодинамичных, условных или ресурсоемких задач может потребоваться скриптовый синтаксис.
Поддерживаемость и читаемость: Декларативные конвейеры обычно легче читать и поддерживать, особенно в больших организациях с множеством конвейеров и разработчиков. Эта согласованность снижает когнитивную нагрузку.
Существующая экосистема конвейеров: Если у вас есть существующие скриптовые конвейеры или надежный набор общих библиотек, построенных на скриптовом синтаксисе, вы можете придерживаться его для согласованности или постепенно мигрировать на декларативный синтаксис там, где это уместно.
Будущий рост: Декларативные конвейеры обычно достаточны и могут быть расширены с помощью пользовательской логики через общие библиотеки, которые сами по себе обычно пишутся на скриптовом Groovy. Это часто является лучшим гибридным подходом.

Лучшие практики для принятия решений

Начинайте с декларативного: Для новых конвейеров по умолчанию используйте декларативный синтаксис. Он охватывает подавляющее большинство случаев использования CI/CD и способствует согласованности и читаемости.
Используйте общие библиотеки: Когда вы сталкиваетесь с повторяющейся или сложной логикой в декларативных конвейерах, абстрагируйте эту логику в общую библиотеку. Общие библиотеки в основном пишутся на скриптовом Groovy, что позволяет объединить лучшее из двух миров: структуру декларативного синтаксиса и гибкость скриптового.
Избегайте чрезмерного использования скриптов в декларативном синтаксисе: Хотя декларативный синтаксис допускает блоки script, старайтесь минимизировать их использование. Если блок script становится слишком большим или сложным, это сильный индикатор того, что логику следует перенести в функцию общей библиотеки.
Рассмотрите миграцию: Если у вас есть устаревшие скриптовые конвейеры, которые становятся трудными для поддержки, рассмотрите возможность их рефакторинга в декларативный синтаксис, перенося сложные части в общие библиотеки.

Вывод

Для новых Jenkinsfile выбирайте декларативный синтаксис, если у вас нет конкретной причины не делать этого. Переносите повторяющуюся или сложную логику Groovy в общие библиотеки и оставляйте полностью скриптовые конвейеры для рабочих процессов, которые не могут быть чисто вписаны в декларативные этапы, условия и шаги.