Какой использовал синтаксис для настройки Jenkins?

Настройка Jenkins: Основные подходы и синтаксис

В качестве Senior Frontend Developer, я часто настраивал CI/CD пайплайны в Jenkins для автоматизации сборки, тестирования и деплоя веб-приложений. Настройка осуществляется через два основных подхода: декларативный (Declarative Pipeline) и скриптовый (Scripted Pipeline) синтаксис, которые пишутся в Jenkinsfile и хранятся в репозитории проекта (инфраструктура как код). Рассмотрю оба, а также конфигурацию через веб-интерфейс.

1. Декларативный Pipeline (современный, рекомендованный синтаксис)

Это более структурированный и простой для чтения подход, использующий директивы. Основные блоки:

• pipeline: Корневой блок, определяющий весь пайплайн.
• agent: Указывает, где выполнять пайплайн (например, any, docker).
• stages: Содержит последовательность стадий.
• stage: Отдельная стадия (например, сборка, тестирование).
• steps: Конкретные шаги внутри стадии.
• environment: Для определения переменных окружения.
• post: Блок для действий после выполнения (например, уведомления).

Пример Jenkinsfile для фронтенд-проекта:

pipeline {
    agent any // Запуск на любом доступном агенте
    environment {
        NODE_VERSION = '18.16.0'
        PROJECT_NAME = 'my-frontend-app'
    }
    stages {
        stage('Checkout') {
            steps {
                // Клонирование репозитория из Git
                checkout scm
            }
        }
        stage('Install Dependencies') {
            steps {
                sh '''
                    nvm use $NODE_VERSION
                    npm ci --prefer-offline
                '''
            }
        }
        stage('Lint & Test') {
            steps {
                parallel(
                    'ESLint': {
                        sh 'npm run lint'
                    },
                    'Unit Tests': {
                        sh 'npm test'
                    }
                )
            }
        }
        stage('Build') {
            steps {
                sh 'npm run build'
                // Артефакты для архивирования
                archiveArtifacts artifacts: 'dist/**', fingerprint: true
            }
        }
        stage('Deploy to Staging') {
            when {
                branch 'develop' // Запускать только для ветки develop
            }
            steps {
                sh '''
                    npm run deploy:staging
                '''
            }
        }
    }
    post {
        success {
            // Уведомление в Slack при успехе
            slackSend channel: '#ci-cd', message: "Build успешен: ${env.JOB_NAME} - ${env.BUILD_NUMBER}"
        }
        failure {
            slackSend channel: '#ci-cd', color: 'danger', message: "Build упал: ${env.JOB_NAME} - ${env.BUILD_NUMBER}"
        }
    }
}

2. Скриптовый Pipeline (Groovy-based синтаксис)

Более гибкий, но сложный подход, где пайплайн описывается скриптом на Groovy. Подходит для сложной логики. Пример:

node('frontend-agent') {
    try {
        stage('Checkout') {
            checkout scm
        }
        def nodeHome = tool name: 'NodeJS-18', type: 'nodejs'
        env.PATH = "${nodeHome}/bin:${env.PATH}"
        stage('Build') {
            if (env.BRANCH_NAME == 'main') {
                sh 'npm run build:production'
            } else {
                sh 'npm run build'
            }
        }
    } catch (Exception e) {
        currentBuild.result = 'FAILURE'
        throw e
    }
}

3. Настройка через веб-интерфейс (UI)

Для базовой настройки использовал Jenkins UI, где конфигурация сохраняется в XML-файлах на сервере. Типичные шаги:

• Установка плагинов (NodeJS, Git, Pipeline, Slack Notification и др.) через Manage Jenkins → Plugins.
• Настройка глобальных инструментов (NodeJS, npm, Docker) в Global Tool Configuration.
• Создание нового Job (или Pipeline), где указывается:

    - Источник кода (Git репозиторий с credentials).
    - Триггеры сборки (по расписанию, webhook от GitHub/GitLab).
    - Среда сборки (выбор агента, переменные окружения).

Пример настройки триггера через UI (синтаксис в конфигурации Job):

// Poll SCM для проверки изменений каждые 5 минут
triggers {
    pollSCM('H/5 * * * *')
}
// Или Webhook (настраивается в репозитории)

Ключевые практики в моей работе:

• Использование Jenkinsfile для version control и повторяемости.
• Docker agents для изоляции окружения (указание agent { docker { image 'node:18-alpine' } }).
• Параллельное выполнение стадий (lint, тесты) для ускорения.
• Интеграция с инструментами:
  • SonarQube для анализа качества кода.
  • Artifactory/Nexus для хранения артефактов.
  • Slack/Teams для уведомлений.
• Использование Credentials для безопасного хранения токенов, паролей.

Для фронтенд-проектов особенно важна настройка кэширования node_modules (через cache директиву или внешние инструменты) и артефактов сборки для ускорения пайплайнов.

В современных проектах часто комбинирую декларативный синтаксис с shared libraries (общие библиотеки Groovy) для повторного использования кода, и параметризованные сборки (с parameters блоком) для ручного запуска с разными окружениями.