Введение в CI/CD и создание конвейера

CI/CD

1. Планирование (Plan). На этом этапе команды разработки определяют, какие изменения или новые функции необходимо реализовать. Планирование включает обсуждение требований, создание задач и распределение работы между разработчиками.
2. Написание кода (Code). Разработчики пишут код для новых функций или исправлений на локальных машинах.

Continuous Integration (CI)

1. Работа с системой контроля версий (Code). Разработчики фиксируют изменения кода в системе контроля версий — например, в Git. Это позволяет отслеживать изменения, управлять различными ветками разработки и координировать работу нескольких разработчиков.
2. Сборка (Build). Каждый раз, когда разработчик вносит изменения в код, эти изменения автоматически интегрируются в центральный репозиторий. После интеграции система CI автоматически запускает процесс сборки проекта. Это нужно, чтобы убедиться: новый код компилируется и работает вместе с остальной кодовой базой.
3. Автоматическое тестирование (Automated Testing). После сборки система CI запускает автоматические тесты, чтобы проверить корректность новых изменений. Это могут быть юнит-тесты, интеграционные тесты и другие виды тестирования. Тесты помогают выявить ошибки и дефекты на ранних этапах разработки.

Continuous Delivery (CD)

4. Подготовка к развёртыванию (Release). Когда все тесты прошли успешно, приложение нужно подготовить к развёртыванию. На этом этапе система может выполнить дополнительную проверку качества, а затем создаст сборки и пакеты, которые нужны для развёртывания.
5. Развёртывание в тестовые среды (Staging/Pre-production Deployment). Готовое приложение развёртывается в тестовых средах, где выполняются дополнительные проверки и тесты. Это помогает убедиться, что приложение работает корректно в условиях, близких к продакшн-среде.

Continuous Deployment

6. Автоматическое развёртывание (Production Deployment). Как только изменение прошло процессы CI и CD, система автоматически доставляет его конечным пользователям.

Pipeline as Code

• В основном — ручные процессы. Разработчики и администраторы выполняли команды сборки и развёртывания вручную. Из-за этого процессы были подвержены человеческим ошибкам и не всегда их можно было повторить точь-в-точь. Время выполнения и качество процесса полностью зависели от человеческого фактора. А документация была разрозненной и быстро устаревала.
• Скрипты и автоматизированные инструменты использовали точечно. Команды использовали отдельные скрипты, чтобы автоматизировать определённые шаги. Не было централизованного управления и координации процессов, а ещё версионирования и контроля изменений. Если в проекте было много микросервисов и команд, возникали проблемы с масштабированием и поддержкой приложений.

Преимущества Pipeline as Code

• Повторяемость. Автоматизированные конвейеры гарантируют, что каждый процесс сборки, тестирования и развёртывания выполняется одинаково. Риск человеческих ошибок минимизирован.
• Гибкость. Определение конвейеров в виде кода позволяет легко изменять их и настраивать под нужды проекта. Это особенно важно в быстро развивающихся компаниях, где требования могут часто меняться.
• Версионирование. Конвейеры хранятся в системе контроля версий — например, в Git. Поэтому любые изменения при необходимости можно отследить и восстановить.
• Прозрачность. Кодовые конвейеры предоставляют чёткую документацию процессов CI/CD. Так разработчикам проще понимать процессы и поддерживать их.
• Масштабируемость. Сочетание CI/CD и PaC позволяет бизнесу быстрее адаптироваться к изменениям на рынке и легко масштабировать систему под новые объёмы заказов.
• Подверженность ошибкам. Но самое важное — это, конечно, безопасность процессов. Автоматизация развёртывания и тестирования снижает риск человеческих ошибок, что делает развёртывания более предсказуемыми и безопасными. Меньше сбоев — меньше головной боли и больше доверия со стороны клиентов.

Когда стоит применять PaC

• Большие и сложные проекты. Проект состоит из множества микросервисов, и над ними работают множество разных команд. Всё это требует сложных процессов сборки, тестирования и развёртывания. PaC обеспечит централизованное управление и повторяемость этих процессов.
• Частые изменения и развёртывания. В проектах, где релизы и изменения происходят часто, PaC помогает автоматизировать и ускорить эти процессы. Подход снизит риск ошибок и повысит скорость доставки.
• Команды с высокой ротацией. В компаниях, где команды разработчиков часто меняются, PaC обеспечивает документацию и стандартизацию процессов CI/CD. С ним будет проще вводить в работу новых членов команды.
• Высокие требования к качеству и безопасности. PaC позволяет внедрять автоматизированные проверки качества и безопасности на каждом этапе конвейера. Это повышает надёжность продукта.
• Наличие инфраструктуры как кода (IaC). Если в компании уже используют IaC для управления инфраструктурой, PaC станет логичным продолжением этого подхода. Он обеспечит консистентность и автоматизацию на всех уровнях.

Когда PaC себя не оправдает

• Маленькие проекты. Для небольших проектов с минимальными требованиями к сборке и развёртыванию внедрение PaC избыточно. Процессы можно поддерживать вручную или с помощью простых скриптов.
• Редкие изменения и развёртывания. Если проект развивается медленно и развёртывания происходят редко, затраты на внедрение и поддержку PaC могут не окупиться. В таких случаях можно обойтись менее сложными решениями.
• Нет опыта и ресурсов. В компаниях, где нет специалистов по DevOps или CI/CD, внедрение PaC может потребовать значительных инвестиций в обучение команды и адаптацию процессов. В таких случаях стоит начать с более простых автоматизаций и переходить к PaC постепенно.
• Сложные интеграции. Если проект зависит от множества внешних систем и инструментов, интеграция всех этих компонентов в PaC может стать сложной и дорогой задачей. В таких случаях стоит тщательно оценить, какие части процесса можно автоматизировать с помощью PaC, а какие реализовать с помощью более простых подходов.

CI/CD, PaC и DevOps

CI/CD

Pipeline as Code

DevOps

Как настроить базовый CI/CD-конвейер

Популярные альтернативы Jenkins

• GitLab CI/CD — это инструмент для CI/CD, который интегрирован в GitLab. Он предлагает удобные и мощные функции для управления конвейерами.
• CircleCI — облачный сервис для CI/CD, который позволяет быстро настраивать и масштабировать конвейеры.
• Travis CI — ещё один облачный сервис для CI/CD, который легко интегрируется с GitHub и поддерживает множество языков программирования.
• Azure DevOps — инструмент от Microsoft, который интегрирован с другими сервисами Azure. Он предоставляет широкий спектр возможностей для CI/CD.
• GitHub Actions — инструмент для автоматизации рабочих процессов непосредственно в GitHub. Он поддерживает CI/CD и множество других задач.

Почему мы выбираем Jenkins?

1. Широкая популярность и активное сообщество. Jenkins — один из самых популярных инструментов для автоматизации. У него много плагинов и активное сообщество.
2. Гибкость и расширяемость. Jenkins предлагает множество плагинов для интеграции с разными инструментами и сервисами. Это делает его очень гибким.
3. Надёжность. Jenkins используют в промышленности уже много лет. Он доказал свою надёжность и эффективность в различных сценариях.

1. Установите и настройте Jenkins

2. Создайте Pipeline as Code в Jenkins

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/username/QuickDelivery.git'
            }
        }
        stage('Build') {
            steps {
                script {
                    docker.image('maven:3.6.3').inside {
                        sh 'mvn clean install'
                    }
                }
            }
        }
        stage('Test') {
            steps {
                script {
                    docker.image('maven:3.6.3').inside {
                        sh 'mvn test'
                    }
                }
            }
        }
        stage('Deploy') {
            steps {
                script {
                    docker.image('docker:latest').inside {
                        sh 'docker-compose up -d'
                    }
                }
            }
        }
    }

    post {
        always {
            junit 'target/surefire-reports/*.xml'
            archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
        }
    }
} 

• Checkout — этот этап клонирует репозиторий с исходным кодом.
• Build — использует Docker-образ с Maven для сборки проекта.
• Test — запускает тесты, используя тот же Docker-образ.
• Deploy — использует Docker Compose, чтобы развернуть приложение.

Что ещё можно автоматизировать?

1. Сборка (Build):
   • Компиляция исходного кода.
   • Сборка артефактов — например, JAR-файлов для Java, бинарных файлов для C++.
   • Выполнение статического анализа кода — например, линтинг.
   • Создание Docker-образов.
2. Тестирование (Testing):
   • Запуск юнит-тестов для проверки функциональности отдельных компонентов.
   • Запуск интеграционных тестов для проверки взаимодействия между компонентами.
   • Выполнение функциональных тестов для проверки всей системы.
   • Выполнение нагрузочного и производительного тестирования.
   • Выполнение тестирования безопасности — например, статический анализ кода на уязвимости.
3. Развёртывание (Deployment):
   • Развёртывание приложения в разных средах — development, staging, production.
   • Обновление существующих развёртываний.
   • Выполнение миграций баз данных.
   • Настройка инфраструктуры — например, развёртывание виртуальных машин или контейнеров.
   • Откат развёртываний в случае проблем.
4. Мониторинг и уведомления (Monitoring and Notifications):
   • Настройка мониторинга состояния приложений и инфраструктуры.
   • Уведомление команды о статусе выполнения задач — успех или сбой.
   • Отправка уведомлений на почту, в корпоративный мессенджер или в другие каналы связи.
5. Управление зависимостями (Dependency Management):
   • Установка и обновление зависимостей.
   • Проверка, насколько совместимы версии зависимостей.
   • Кэширование зависимостей для ускорения сборки.
6. Проверка кода (Code Review and Quality Assurance):
   • Автоматический код-ревью.
   • Запуск статического анализа кода.
   • Проверка соблюдения стандартов кодирования.
   • Генерация отчётов о качестве кода.
7. Безопасность (Security):
   • Выполнение сканирования на уязвимости.
   • Проверка безопасности зависимостей.
   • Управление секретами и ключами доступа.
8. Доставка (Delivery):

   • Публикация артефактов в репозитории — например, публикация библиотек в Maven Central или PyPI.
   • Отправка релизных уведомлений и выпусков.

Как автоматизировать CI/CD-конвейеры с помощью скриптов

1. Скрипты для управления зависимостями. Создайте скрипт install_dependencies.sh:

#!/bin/bash
apt-get update
apt-get install -y docker docker-compose 

2. Скрипты для сборки и тестирования. Создайте скрипт build_and_test.sh:

#!/bin/bash
mvn clean install
mvn test 

3. Скрипты для развёртывания. Создайте скрипт deploy.sh:

#!/bin/bash
docker-compose up -d 

4. Интеграция скриптов в Jenkins Pipeline. Обновите «Pipeline script», чтобы использовать созданные скрипты:

pipeline {
    agent any

    stages {
        stage('Install Dependencies') {
            steps {
                sh 'sh scripts/install_dependencies.sh'
            }
        }
        stage('Checkout') {
            steps {
                git 'https://github.com/username/QuickDelivery.git'
            }
        }
        stage('Build and Test') {
            steps {
                sh 'sh scripts/build_and_test.sh'
            }
        }
        stage('Deploy') {
            steps {
                sh 'sh scripts/deploy.sh'
            }
        }
    }

    post {
        always {
            junit 'target/surefire-reports/*.xml'
            archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
        }
    }
} 

Как настроить мониторинг CI/CD-конвейера

• Отслеживать статус выполнения сборок и развёртываний.
• Вовремя выявлять и устранять проблемы.
• Анализировать производительность и эффективность процессов.
• Получать уведомления о сбоях и проблемах.

Инструменты для мониторинга Jenkins

1. Built-in Jenkins Monitoring. Jenkins предоставляет базовые возможности мониторинга через веб-интерфейс. Здесь можно просматривать статус сборок, журнал событий и историю сборок.
2. Prometheus и Grafana. Для более продвинутого мониторинга можно использовать Prometheus и Grafana. Они позволяют собирать, анализировать и визуализировать метрики Jenkins.
3. Jenkins Monitoring Plugins:
   • Monitoring Plugin — это плагин для мониторинга метрик Jenkins. Например, он позволит отслеживать использование CPU, памяти и диска.
   • Prometheus Plugin — это плагин для экспорта метрик Jenkins в Prometheus.

Как настроить мониторинг с помощью с Prometheus и Grafana

1. Установите Prometheus и Grafana. Можете установить Prometheus и Grafana на сервере или использовать Docker-контейнеры для их развёртывания.
   Скопировать код

   BASH

    docker run -d --name prometheus -p 9090:9090 prom/prometheus
    docker run -d --name grafana -p 3000:3000 grafana/grafana
     
2. Установите Prometheus Plugin в Jenkins. Для этого перейдите в «Управление Jenkins» —> «Управление плагинами». В разделе «Доступные» найдите и установите «Prometheus Plugin».
3. Настройте Prometheus для сбора метрик Jenkins. Добавьте конфигурацию для сбора метрик Jenkins в Prometheus:
   Скопировать код

   YAML

    scrape_configs:
      - job_name: 'jenkins'
        static_configs:
          - targets: ['<jenkins_server_ip>:<jenkins_server_port>/prometheus']
     
4. Настройте Grafana для визуализации метрик Jenkins. Перейдите в интерфейс Grafana и добавьте Prometheus в качестве источника данных. Затем создайте новый дашборд и добавьте панели для визуализации метрик Jenkins — например, для статуса сборок, времени выполнения сборок, использования ресурсов и так далее.

Примеры метрик для мониторинга

• Количество успешных, неудачных и пропущенных сборок.
• Время выполнения сборок.
• Длительность отдельных этапов конвейера.

• Загрузка CPU.
• Использование памяти.
• Использование дискового пространства.

• Количество запущенных задач.
• Время ожидания задач в очереди.
• Ошибки и предупреждения в логах сборок.

Как настроить уведомления

1. Jenkins Email Notifications. В разделе конфигурации Jenkins добавьте «Email Extension Plugin». Затем настройте параметры SMTP-сервера и добавьте email-адреса для уведомлений.
2. Grafana Alerts. 2. В интерфейсе Grafana настройте правила алертинга для критических метрик. Затем добавьте каналы уведомлений — например, почту или корпоративный мессенджер. Туда будут падать оповещения.

Пример настройки уведомлений в Jenkins

pipeline {
    agent any

    tools {
        jdk 'JDK11'
    }

    environment {
        DOCKER_IMAGE = 'quickdelivery/app'
    }

    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/your-repo/quickdelivery.git'
            }
        }
        stage('Build') {
            steps {
                script {
                    docker.image('maven:3.6.3-jdk-11').inside {
                        sh 'mvn clean package'
                    }
                }
            }
        }
        stage('Test') {
            steps {
                script {
                    docker.image('maven:3.6.3-jdk-11').inside {
                        sh 'mvn test'
                    }
                }
            }
        }
        stage('Build Docker Image') {
            steps {
                script {
                    sh 'docker build -t ${DOCKER_IMAGE} .'
                }
            }
        }
        stage('Push Docker Image') {
            steps {
                script {
                    withCredentials([string(credentialsId: 'dockerhub-password', variable: 'DOCKERHUB_PASSWORD')]) {
                        sh 'echo $DOCKERHUB_PASSWORD | docker login -u your-dockerhub-username --password-stdin'
                        sh 'docker push ${DOCKER_IMAGE}'
                    }
                }
            }
        }
        stage('Deploy') {
            steps {
                script {
                    sh 'docker run -d -p 8080:8080 ${DOCKER_IMAGE}'
                }
            }
        }
    }

    post {
        always {
            emailext (
                subject: "Build ${currentBuild.fullDisplayName}",
                body: "Check console output at ${env.BUILD_URL} to view the results.",
                recipientProviders: [[$class: 'DevelopersRecipientProvider']]
            )
        }
        failure {
            emailext (
                subject: "Build ${currentBuild.fullDisplayName} FAILED",
                body: "Build failed. Check console output at ${env.BUILD_URL} to view the results.",
                recipientProviders: [[$class: 'DevelopersRecipientProvider']]
            )
        }
    }
} 

Итоги

• Continuous Integration (CI, непрерывная интеграция) — изменения автоматически заливаются в общий репозиторий, проект собирается, а затем запускаются автотесты.
• Continuous Delivery (CD, непрерывная доставка) — когда все тесты прошли успешно, приложение готовится к развёртыванию. Готовое приложение развёртывается в тестовых средах, где запускаются дополнительные проверки и тесты.
• Continuous Deployment (непрерывное развёртывание) — как только изменения проходят процессы CI и CD, система автоматически доставляет их на продакшн.