Как выкатывал stand в Jenkins

Мой опыт деплоя стендов с использованием Jenkins

Как Senior QA Engineer, я участвовал в настройке и поддержке CI/CD пайплайнов в Jenkins для деплоя тестовых стендов множеством способов, в зависимости от проекта, инфраструктуры и требований к тестированию. Основная цель — автоматизация, повторяемость и надежность развертывания.

Ключевые подходы и инструменты

В зависимости от архитектуры приложения и требований, использовались следующие методы:

• Деплой артефактов (JAR, WAR, Docker-образы): Пайплайн собирал приложение, создавал артефакт и с помощью плагинов (например, SSH, Deploy to container) или скриптов копировал его на целевой сервер.
• Деплой через Docker: После сборки и тегирования образа в пайплайне, стенд поднимался командами docker-compose или docker run либо на выделенном хосте, либо в оркестраторе (Kubernetes через kubectl).
• Инфраструктура как код (IaC): Для сложных стендов использовались инструменты вроде Ansible, Terraform или облачные SDK. Jenkins-задача запускала соответствующий плейбук или конфигурацию, чтобы "на лету" создавать или обновлять инфраструктуру и деплоить на нее приложение.
• Оркестрация в Kubernetes: Наиболее распространенный в моей последней практике подход. Пайплайн обновлял конфигурации (YAML-манифесты или Helm-чарты) и применял их к кластеру через kubectl или Helm.

Пример пайплайна (Jenkinsfile) для деплоя в Kubernetes

Ниже — упрощенная, но реальная структура declarative pipeline для деплоя микросервиса в K8s. Он включает этапы для сборки, упаковки в Docker, развертывания и даже простой smoke-проверки.

pipeline {
    agent any
    environment {
        DOCKER_IMAGE = 'my-registry.company.com/my-app'
        K8S_NAMESPACE = 'test-stand'
        HELM_CHART_PATH = './kubernetes/charts/my-app'
    }
    stages {
        stage('Checkout') {
            steps {
                git branch: 'develop', url: 'https://github.com/company/my-app.git'
            }
        }
        stage('Build & Unit Tests') {
            steps {
                sh 'mvn clean package'
            }
        }
       >>>> stage('Build Docker Image') {
            steps {
                script {
                    def imageTag = "${env.DOCKER_IMAGE}:${env.BUILD_NUMBER}"
                    docker.build(imageTag)
                }
            }
        }
        stage('Push Docker Image') {
            steps {
                script {
                    docker.withRegistry('https://my-registry.company.com', 'docker-hub-credentials') {
                        docker.image("${env.DOCKER_IMAGE}:${env.BUILD_NUMBER}").push()
                    }
                }
            }
        }
        stage('Deploy to Test Stand') {
            steps {
                script {
                    // Обновляем версию образа в Helm values или используем set
                    sh """
                        helm upgrade --install my-app ${HELM_CHART_PATH} \
                        --namespace ${K8S_NAMESPACE} \
                        --set image.tag=${env.BUILD_NUMBER} \
                        --set environment=test \
                        --wait
                    """
                }
            }
        }
        stage('Smoke Test') {
            steps {
                // Простейшая проверка, что приложение отвечает
                sh """
                    timeout 120 bash -c 'until curl -f http://my-app.${K8S_NAMESPACE}.svc.cluster.local:8080/health; do sleep 5; done'
                """
            }
        }
    }
    post {
        success {
            echo "Стенд успешно обновлен до версии ${env.BUILD_NUMBER}"
            // Можно отправить уведомление в Slack/Teams
        }
        failure {
            echo "Деплой неудачен! Требуется анализ логов."
            // Здесь же можно запустить скрипт отката (helm rollback)
        }
    }
}

Роль QA Engineer в этом процессе

Моя ответственность выходила далеко за рамки простого запуска джобы:

1. Участие в проектировании пайплайна: Я помогал определять необходимые этапы проверок (линтеры, security-сканы), точку вставки автотестов и критерии успешного деплоя.
2. Конфигурация и параметризация: Настройка переменных окружения в Jenkins для разных стендов (test, stage), работа с Credentials для безопасного доступа к registry и кластерам.
3. Внедрение гарантий качества в CI/CD:

    *   **Запуск автотестов:** Интеграция этапов запуска **API**, **интеграционных** или **нагрузочных** тестов после деплоя. Пайплайн не считался успешным, если тесты не проходили.
    *   **Проверка конфигурации:** Верификация корректности примененных конфигов (например, через `kubectl get pods -n test-stand` и проверка статусов).
    *   **Smoke/Sanity проверки:** Как в примере выше — быстрая проверка жизнеспособности развернутого приложения.

1. Обеспечение возможности отката (Rollback): Участие в проектировании и тестировании процедуры быстрого отката на предыдущую стабильную версию (через helm rollback, tags в Git).
2. Мониторинг и анализ: После деплоя я анализировал логи приложения (часто через Kibana или Grafana), чтобы убедиться в отсутствии критических ошибок, прежде чем объявлять стенд готовым к тестированию.

Вывод

Для меня, как для QA, Jenkins был не просто "кнопкой для деплоя", а центральным инструментом, обеспечивающим стабильность и предсказуемость тестовой среды. Умение настроить, адаптировать и отладить пайплайн деплоя — критически важный навык для современного инженера по качеству, работающего в DevOps-культуре. Это напрямую влияет на скорость получения фидбека и, как следствие, на качество конечного продукта.