Как выглядит логика работы хорошего CI/CD

Логика работы современного CI/CD Pipeline

Хороший CI/CD — это не просто автоматизация сборки, а целостная культура доставки ПО, реализованная через автоматизированный конвейер. Его логика строится на принципах непрерывности, автоматизации и обратной связи. Вот как выглядит его архитектура:

Ключевые принципы

1. Непрерывная интеграция (CI)
   Каждая правка кода запускает автоматическую сборку и тестирование, обеспечивая раннее выявление проблем.

2. Непрерывная доставка (CD)
   Каждая успешная сборка автоматически готовится к развертыванию в любую среду (включая прод).

3. Идемпотентность и воспроизводимость
   Каждый запуск конвейера дает одинаковый результат при одинаковых входных данных.

4. Security by Design
   Проверки безопасности встроены в каждый этап (SAST, DAST, сканирование зависимостей).

Архитектура типичного конвейера

# Пример декларативного Jenkinsfile (основные стадии)
pipeline {
    agent any
    stages {
        stage('Fetch & Validate') {
            steps {
                checkout scm
                sh 'pre-commit run --all-files' # Статический анализ кода
            }
        }
        
        stage('Build & Unit Tests') {
            steps {
                sh 'mvn clean compile'
                sh 'mvn test'
                parallel {
                    stage('SonarQube Analysis') {
                        sh 'mvn sonar:sonar'
                    }
                    stage('Dependency Check') {
                        sh 'mvn org.owasp:dependency-check-maven:check'
                    }
                }
            }
        }
        
        stage('Containerize') {
            steps {
                sh '''
                    docker build -t app:${BUILD_ID} .
                    docker scan app:${BUILD_ID} --severity high
                    docker tag app:${BUILD_ID} registry.company.com/app:${COMMIT_SHA}
                '''
            }
        }
        
        stage('Integration Tests') {
            steps {
                sh 'docker-compose -f docker-compose.test.yml up --abort-on-container-exit'
            }
        }
        
        stage('Deploy to Staging') {
            when {
                branch 'main' # Автодеплой только для main
            }
            steps {
                sh 'kubectl apply -f k8s/staging/'
                input message: 'Promote to production?' # Ручное подтверждение
            }
        }
        
        stage('Deploy to Production') {
            steps {
                sh 'kubectl apply -f k8s/production/'
                sh './scripts/smoke-test.sh' # Smoke-тесты после деплоя
            }
        }
    }
    
    post {
        always {
            cleanWs() # Очистка workspace
            emailext subject: 'Build ${BUILD_STATUS}',
                      body: 'Сборка ${JOB_NAME} завершена со статусом ${BUILD_STATUS}'
        }
        failure {
            slackSend channel: '#alerts', message: 'Build ${BUILD_NUMBER} failed!'
        }
    }
}

Критические компоненты логики

1. Триггеры и управление потоком

• Триггеры: Push в репозиторий, Pull Request, по расписанию, ручной запуск
• Артефакты: Библиотеки, Docker-образы, Helm-чарты передаются между стадиями
• Кэширование: Кэш зависимостей и слоев Docker ускоряет выполнение

2. Стратегии тестирования

# Пример скрипта запуска тестов с разными уровнями
#!/bin/bash
# Unit-тесты (быстрые, обязательные)
npm run test:unit

# Интеграционные тесты (требуют инфраструктуры)
if [ "$ENV" == "staging" ]; then
    npm run test:integration
fi

# E2E тесты (только для основных сценариев)
if [ "$BRANCH" == "main" ]; then
    npm run test:e2e -- --grep "@critical"
fi

3. Стратегии развертывания

• Blue-Green: Минимальное время простоя, быстрое откатывание
• Canary: Постепенное развертывание на подмножестве пользователей
• Feature Flags: Управление функциональностью без деплоя кода

4. Мониторинг и обратная связь

• Метрики конвейера: Время выполнения, успешность, стоимость
• Production-метрики: Задержки, ошибки, бизнес-показатели
• Автоматические откаты: При обнаружении проблем в мониторинге

Best Practices

Обязательные практики:

• Инфраструктура как код (IaC): Конвейер должен создавать среды самостоятельно
• Immutable Infrastructure: После сборки артефакты не изменяются
• Secrets Management: Никаких секретов в коде или логах
• Pipeline as Code: Конвейер описывается в репозитории с приложением

Оптимизации:

• Параллельное выполнение: Независимые задачи выполняются параллельно
• Инкрементальные сборки: Для feature-бранчей - только необходимые тесты
• Артефактные репозитории: Nexus, Artifactory для хранения результатов сборки

Пример продвинутой логики с feature branches:

// Условная логика в Jenkinsfile
stage('Conditional Deployment') {
    when {
        anyOf {
            branch 'main'
            branch 'release/*'
            expression { 
                return env.CHANGE_TARGET == 'main' && 
                       currentBuild.result == 'SUCCESS'
            }
        }
    }
    steps {
        script {
            if (env.BRANCH_NAME.startsWith('feature/')) {
                // Для feature-бранчей - деплой в изолированное окружение
                deployToPreviewEnvironment()
            } else if (env.BRANCH_NAME == 'main') {
                // Для main - полный конвейер до production
                deployToProductionWithCanary()
            }
        }
    }
}

Хороший CI/CD — это самообучающаяся система, которая:

1. Предотвращает проблемы через раннее тестирование
2. Минимизирует время восстановления при сбоях
3. Ускоряет обратную связь для разработчиков
4. Обеспечивает аудит всех изменений
5. Снижает когнитивную нагрузку на команду

Такой подход превращает деплой из редкого стрессового события в рутинную безопасную операцию, выполняемую несколько раз в день.