Jenkins для QA: основные паттерны построения пайплайна

Jenkins — старичок CI с 2011 года. В новых проектах его обходят (выбирают GitHub Actions, GitLab CI, CircleCI), но в корпоративных и legacy-проектах он живее всех живых. Гайд для QA, который оказался в проекте с Jenkins.

Declarative pipeline (Jenkinsfile)

Современный Jenkins — это Jenkinsfile в репо, не «настроил кнопками через UI». UI используется только для запуска и просмотра.

pipeline {
    agent any
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }
        stage('Test') {
            steps {
                sh 'npx playwright test'
            }
        }
    }
    
    post {
        always {
            publishHTML([reportDir: 'playwright-report', reportFiles: 'index.html', reportName: 'Playwright Report'])
        }
    }
}

Этот файл — в репо вместе с кодом. Изменения проходят через PR, ревью.

Шаблонные паттерны

Параллелизация по тэгам

stage('Tests') {
    parallel {
        stage('Smoke') { steps { sh 'pytest -m smoke' } }
        stage('API') { steps { sh 'pytest -m api' } }
        stage('UI') { steps { sh 'pytest -m ui' } }
    }
}

Smoke, API и UI запускаются параллельно — общее время = max(3 стейджей), а не sum.

Матрица браузеров

stage('Browser tests') {
    matrix {
        axes {
            axis {
                name 'BROWSER'
                values 'chromium', 'webkit', 'firefox'
            }
        }
        stages {
            stage('Test') {
                steps {
                    sh "npx playwright test --project=${BROWSER}"
                }
            }
        }
    }
}

Один stage блок → 3 параллельных прогона на разных браузерах.

Conditional stages

Smoke на каждый PR, full regression только на main:

stage('Full Regression') {
    when {
        branch 'main'
    }
    steps {
        sh 'pytest tests/regression/'
    }
}

Allure-отчёты

post {
    always {
        allure([
            includeProperties: false,
            jdk: '',
            properties: [],
            reportBuildPolicy: 'ALWAYS',
            results: [[path: 'allure-results']]
        ])
    }
}

Нужен плагин Allure в Jenkins.

Подводные камни

⚠️ Pipeline syntax: declarative (рекомендуется) vs scripted — два разных синтаксиса. Не смешивай. Современный — declarative.

⚠️ Workspace persistence: Jenkins не чистит workspace между билдами по умолчанию. Старые файлы остаются. Используй cleanWs() в pre или post.

⚠️ Secrets: пароли и токены — через withCredentials, не через env-переменные напрямую. Иначе светятся в логах.

⚠️ Параллелизм агентов: если у тебя один agent и 5 параллельных pipeline — они выстроятся в очередь. Считай ресурсы.

Когда мигрировать с Jenkins

Если можешь — мигрируй. Современный CI (GitHub Actions, GitLab CI) проще, дешевле, надёжнее. Jenkins требует поддержки сервера, периодических обновлений плагинов, ручной настройки.

Сценарии когда нельзя:

• Self-hosted requirement (compliance).
• Сотни легаси-pipeline’ов.
• Команда не готова к миграции.

Минимальный набор для QA

✅ Jenkinsfile в репозитории проекта (не в UI).

✅ pre блок с cleanWs() — чистый старт каждого билда.

✅ Параллельные стейджи для smoke / API / UI / unit.

✅ post { always { publishHTML/allure } } — отчёты доступны после билда.

✅ when { branch 'main' } для длинного регресса.

✅ Slack notification на падение — post { failure { slackSend ... } }.

Подробнее: Jenkins Pipeline syntax, Pipeline best practices.