Расскажи о основных этапах CI/CD.

Концептуально CI/CD делится на два основных этапа:

1. Continuous Integration (CI):

   • Commit (Фиксация изменений): Разработчики фиксируют изменения в общем репозитории кода (например, Git).
   • Build (Сборка): Автоматически запускается сборка приложения из исходного кода.
   • Test (Тестирование): Прогоняются автоматизированные тесты (юнит, интеграционные, статические анализаторы).

2. Continuous Delivery/Deployment (CD):

   • Deploy to Staging (Развертывание на Stage): Успешно собранный и протестированный артефакт развертывается в промежуточной среде (Stage), имитирующей продакшен.
   • Automated Acceptance Testing (Автоматическое приемочное тестирование): На Stage-среде выполняются автоматизированные приемочные тесты для проверки бизнес-логики.
   • Manual Testing/Exploratory Testing (Ручное/Исследовательское тестирование): При необходимости проводится ручное тестирование на Stage.
   • Deploy to Production (Развертывание в Production): При успешном прохождении всех предыдущих этапов артефакт развертывается в продакшен-среде. В случае Continuous Deployment этот этап полностью автоматизирован. В случае Continuous Delivery, может требоваться ручное подтверждение.
   • Monitoring and Feedback (Мониторинг и Обратная связь): После развертывания ведется мониторинг работы приложения в продакшене для выявления проблем и сбора обратной связи.

Вот пример пайплайна в Jenkinsfile:

// Jenkinsfile
pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install -DskipTests' // Пример сборки Maven, пропуск тестов на этом этапе
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test' // Запуск юнит- и интеграционных тестов
            }
            post {
                always {
                    junit '**/TEST-*.xml' // Публикация результатов тестов
                }
            }
        }
        stage('Static Analysis') {
           steps {
               sh 'mvn sonar:sonar' // Пример статического анализа с SonarQube
           }
        }
        stage('Build Docker Image') {
            steps {
                script {
                    docker.build("my-app:${env.BUILD_NUMBER}") // Сборка Docker-образа с тегом по номеру сборки
                }
            }
        }
        stage('Deploy to Stage') {
            steps {
                sh 'ssh user@stage-server "deploy_script.sh my-app:${env.BUILD_NUMBER}"' // Пример развертывания на Stage по SSH
            }
        }
        stage('Acceptance Tests') {
            steps {
                sh 'run_acceptance_tests.sh' // Запуск автоматических приемочных тестов на Stage
            }
        }
        stage('Deploy to Production') {
            when {
                environment name: 'CONTINUOUS_DEPLOYMENT', value: 'true' // Пример условия для автоматического развертывания в Production
            }
            steps {
                sh 'ssh user@prod-server "deploy_script.sh my-app:${env.BUILD_NUMBER}"' // Развертывание в Production
            }
        }
        stage('Manual Approval for Production') { // Этот этап может быть включен для Continuous Delivery
           when {
              environment name: 'CONTINUOUS_DEPLOYMENT', value: 'false'
           }
           steps {
             input message: 'Deploy to Production?', ok: 'Deploy Now'
             sh 'ssh user@prod-server "deploy_script.sh my-app:${env.BUILD_NUMBER}"'
           }
        }
    }
    post {
        failure {
            mail to: 'devops@example.com', subject: "Build ${env.BUILD_NUMBER} Failed", body: "Build failed for ${env.JOB_NAME}" // Отправка уведомления о фейле
        }
        success {
            mail to: 'devops@example.com', subject: "Build ${env.BUILD_NUMBER} Succeeded", body: "Build succeeded for ${env.JOB_NAME}" // Отправка уведомления об успехе
        }
    }
}

Основные различия между Continuous Delivery и Continuous Deployment:

Каждый этап пайплайна должен быть автоматизирован и выполнять свою специфическую задачу.