В Jenkins пишешь Freestyle или библиотеку

Мой подход к Jenkins: Freestyle против Pipeline

Как DevOps-инженер с более чем 10-летним опытом работы с Jenkins, я однозначно предпочитаю писать Pipeline-скрипты (в идеале — Jenkinsfile, хранимый в репозитории) или использовать Shared Library, а не создавать Freestyle-проекты. Вот подробное обоснование.

Почему Pipeline, а не Freestyle

Freestyle-проекты — это классический, но устаревший подход с графическим интерфейсом. Они подходят для:

• Простейших задач (например, запуск одного скрипта).
• Быстрого прототипирования.
• Небольших команд, не имеющих опыта с инфраструктурой как код.

Однако их серьезные недостатки:

• Конфигурация хранится в Jenkins, а не в репозитории, что усложняет версионирование, отслеживание изменений и восстановление.
• Отсутствие стандартизации: каждый проект настраивается индивидуально через UI, что ведет к дрейфу конфигурации.
• Сложность поддержки при росте числа джоб: изменения приходится вносить вручную в каждом проекте.
• Ограниченная гибкость для сложных сценариев (параллельные этапы, циклы, обработка ошибок).

Pipeline-скрипты (в формате Declarative или Scripted) решают эти проблемы:

• Инфраструктура как код: весь Pipeline хранится в Jenkinsfile в репозитории приложения.
• Версионирование и код-ревью: изменения в Pipeline проходят через те же процессы, что и код приложения.
• Повторное использование: шаблоны можно выносить в Shared Libraries.
• Расширенная логика: поддерживаются сложные сценарии, условное выполнение, параллелизм.

Пример Declarative Pipeline (Jenkinsfile)

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean compile'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'mvn deploy'
            }
        }
    }
    post {
        failure {
            emailext subject: 'Pipeline failed',
                     body: 'Проверьте консольный вывод',
                     to: 'team@example.com'
        }
    }
}

Когда использовать Shared Library

Shared Library — это следующий уровень абстрагирования. Я создаю библиотеки, когда:

• Несколько проектов используют одинаковые шаги или последовательности (например, сборка Docker-образа и публикация в registry).
• Требуется сложная бизнес-логика, которую неудобно дублировать в каждом Jenkinsfile.
• Нужно стандартизировать и централизованно обновлять общие функции.

Пример структуры Shared Library:

vars/           # Глобальные переменные (вызываемые как шаги)
    buildDockerImage.groovy
    deployToK8s.groovy
src/            # Классы и утилиты на Groovy
    com/company/CIUtils.groovy

Пример шага из библиотеки (vars/buildDockerImage.groovy):

def call(String imageName, String tag = 'latest') {
    script {
        docker.build("${imageName}:${tag}")
        docker.withRegistry('https://registry.company.com', 'docker-credentials') {
            docker.push("${imageName}:${tag}")
        }
    }
}

И тогда в Jenkinsfile это используется лаконично:

stage('Build and Push') {
    steps {
        buildDockerImage('myapp', env.BUILD_NUMBER)
    }
}

Практические рекомендации

1. Начинайте с Declarative Pipeline для новых проектов — он более структурированный и читаемый.
2. Храните Jenkinsfile в корне репозитория приложения, чтобы связь между кодом и процессом CI/CD была явной.
3. Используйте Shared Library при дублировании кода в Pipeline или для инкапсуляции сложной логики.
4. Избегайте Freestyle для production-проектов, так как это ведет к техническому долгу.

Заключение

В современном DevOps-стеке, где инфраструктура как код и GitOps стали стандартом, Freestyle-проекты — это анахронизм. Pipeline-скрипты и Shared Libraries обеспечивают необходимые повторяемость, версионирование и масштабируемость. Они интегрируются с практиками Continuous Integration и Continuous Deployment, позволяя управлять конвейерами через код, что критически важно для быстрой и надежной доставки ПО. Мой выбор — всегда Pipeline, а для сложных сред — с обязательным использованием Shared Libraries для унификации процессов.