Каковы основные этапы CI/CD пайплайна

CI/CD пайплайн — это автоматизированная последовательность этапов, через которые проходит код от коммита до развертывания в продуктивную среду. Типичный пайплайн для Java-проекта состоит из следующих этапов.

1. Checkout (получение кода)

Клонирование репозитория или получение изменений из VCS. В Jenkins это обычно checkout scm, который автоматически определяет репозиторий и ветку.

2. Build (сборка)

• Компиляция исходного кода (mvn compile, gradle compileJava).
• Разрешение зависимостей (скачивание из Nexus/Maven Central).
• Генерация кода (Lombok, MapStruct, JAXB).

3. Test (тестирование)

• Unit-тесты (mvn test) — быстрая проверка логики отдельных компонентов.
• Интеграционные тесты (mvn verify) — проверка взаимодействия компонентов.
• Иногда — тесты производительности и нагрузочные тесты.

4. Code Quality (проверка качества кода)

• Статический анализ кода (SonarQube, Checkstyle, SpotBugs).
• Проверка покрытия тестами (JaCoCo).
• Проверка безопасности зависимостей (OWASP Dependency Check).

5. Package (упаковка)

• Создание артефакта: JAR, WAR, Docker-образ.
• Версионирование артефакта (семантическое версионирование или номер сборки).

6. Publish (публикация)

• Загрузка артефакта в Nexus Repository.
• Публикация Docker-образа в Docker Registry.

7. Deploy (развертывание)

• Развертывание на DEV/TEST/STAGING окружение.
• Для production — ручное подтверждение (в Continuous Delivery).

8. Smoke/Acceptance Tests (приемочные тесты)

• Проверка работоспособности приложения после деплоя.
• Автоматические end-to-end тесты (Selenium, REST Assured).
• Health check эндпоинтов (/actuator/health).

Пример Jenkinsfile с основными этапами

pipeline {
    agent any
    stages {
        stage('Checkout')  { steps { checkout scm } }
        stage('Build')     { steps { sh 'mvn clean compile' } }
        stage('Test')      { steps { sh 'mvn test' } }
        stage('Quality')   { steps { sh 'mvn sonar:sonar' } }
        stage('Package')   { steps { sh 'mvn package -DskipTests' } }
        stage('Publish')   { steps { sh 'mvn deploy -DskipTests' } }
        stage('Deploy')    { steps { sh './deploy.sh staging' } }
        stage('Smoke')     { steps { sh 'curl -f http://staging:8080/actuator/health' } }
    }
    post {
        always { junit '**/surefire-reports/*.xml' }
        failure { mail to: 'team@company.com', subject: "FAILED: ${env.JOB_NAME}", body: "Build ${env.BUILD_NUMBER} failed." }
    }
}

Визуализация потока

Checkout -> Build -> Test -> Quality -> Package -> Publish -> Deploy -> Smoke Tests
                      |         |
                  Fail fast  Quality Gate
                  (уведомление)  (блокировка)

Вывод

Каждый этап пайплайна выступает в роли «ворот качества» (quality gate): если этап завершается с ошибкой, дальнейшее выполнение прекращается, и команда получает уведомление. Принцип «fail fast» экономит ресурсы и время.

На собеседовании: часто просят перечислить этапы и объяснить, зачем нужен каждый из них. Хороший кандидат также упомянет принцип «build once, deploy many» — артефакт собирается один раз и переиспользуется на всех окружениях.