Использовали ли вы Jenkins Shared Libraries для настройки пайплайнов?

Да, я активно использовал Jenkins Shared Libraries для стандартизации и устранения дублирования кода в пайплайнах. Это позволило нам вынести общую логику (например, этапы сборки, деплоя, уведомлений) в отдельный репозиторий.

Пример подключения и использования в Jenkinsfile:

@Library('company-pipeline-lib@v2.1') _ // Подключаем версию библиотеки

pipeline {
    agent any
    stages {
        stage('Build and Test') {
            steps {
                // Используем кастомный шаг из библиотеки
                buildMavenProject(
                    javaVersion: '17',
                    goals: 'clean package'
                )
                runIntegrationTests()
            }
        }
        stage('Deploy to Staging') {
            steps {
                deployToKubernetes(
                    environment: 'staging',
                    namespace: 'app-staging'
                )
            }
        }
    }
}

Ключевые преимущества, которые я реализовал:

• Стандартизация: Все команды используют одни и те же проверенные шаги для сборки, тестирования и деплоя.
• Снижение ошибок: Изменения в процессе CI/CD вносятся в одном месте (библиотеке) и применяются ко всем пайплайнам после обновления версии.
• Упрощение Jenkinsfile: Пайплайны в проектах становятся декларативными и читаемыми, так как скрывают сложную реализацию.
• Версионирование: Мы использовали теги (@v1.0, @v2.1) для контроля изменений и возможности отката.

Основная сложность — первоначальная настройка глобальной библиотеки в Jenkins и организация её репозитория (структура vars/ для шагов, src/ для более сложного кода на Groovy).