Процесс тестирования можно построить разными способами. Один из эффективных методов автоматизации процесса тестирования это непрерывное тестирование в рамках непрерывной поставки ПО. Непрерывное тестирование позволяет стабилизировать и улучшить качество кода. Т.к. любое приложение начинается с разработки, то необходимо внедрять полноценное тестирование в циклы разработки.
Основная идея непрерывной поставки в том, чтобы построить конвейер (Deployment Pipeline), позволяющий каждому изменению в системе контроля версий попасть в боевое окружение стандартным и полностью автоматизированным способом.
Пример построения Deployment Pipeline на Jenkins для первой части:
1. Создание pipeline проекта
1.1. “Создать item” — ввести название и выбрать конфигурацию pipeline
1.2. В поле “GitHub project” ввести адрес до репозитория
1.3. Выбрать чекбокс “Опрашивать SCM об изменениях” и настроить расписание на проверку репозитория каждую минуту “* * * * *”
1.4. В поле “Pipeline script” ввести шаги проекта
node{
stage 'Deploy'
build 'Deploy_CHECK'
stage 'Sonar_analysis'
build job: 'Sonar_analysis', parameters: [string(name: 'STAND', value: 'CHECK')]
stage 'Unit tests'
build job: 'Unit_tests', parameters: [string(name: 'STAND', value: 'CHECK')]
stage 'Deploy DEV'
build 'Deploy_DEV'
stage 'Unit tests'
build job: 'Unit_tests', parameters: [string(name: 'STAND', value: 'DEV')]
stage 'Acceptance_test'
build 'Acceptance_test'
stage 'Smoke_tests'
build job: 'Smoke_tests', parameters: [string(name: '', value: 'DEV')]
}
2. Внести изменение в репозиторий
3. В течении минуты pipeline увидит новое изменение в репозитории и запустит проверку
Рис.1. Пример запуска проверок на CHECK и DEV окружениях.
Рис.2. Результат выполнения одного из этапов проверок.
Рис.3. Обнаружение ошибки на одном из шагов выполнения работы
Пример построения Deployment Pipeline на Jenkins для второй части:
1. Создание pipeline проекта
1.1. “Создать item” — ввести название и выбрать конфигурацию pipeline
1.2. В поле “GitHub project” ввести адрес до репозитория
1.3. Выбрать чекбокс “Опрашивать SCM об изменениях” и настроить расписание на проверку репозитория каждую минуту “* * * * *”
1.4. В поле “Pipeline script” ввести шаги проекта
node{
stage 'Deploy QA'
build 'Deploy_QA'
stage 'Compliance tests'
build job: 'chef-compliance', parameters: [string(name: 'STAND', value: 'QA')]
stage 'Functional tests'
build job: 'Tempest', parameters: [string(name: 'STAND', value: 'QA')]
stage 'Performance tests'
build 'Rally'
stage 'Deploy PROD'
build 'Deploy_PROD'
stage 'Smoke tests PROD'
build 'Smoke_tests_PROD'
}
2. Если merge request закрыт успешно, то
2.1. Отрезать ветку develop как release 2.2. Pipeline видит изменения в ветке release*
2.3. Запускается pipeline с проверками
Рис.4. Процесс выполнения pipeline для QA и PRODUCTION окружения
Рис.5. Результат успешного выполнения pipeline с развертыванием и запуском тестов на QA и PRODUCTION окружениях
Рис.6. Результат не успешного выполнения pipeline с развертыванием и запуском тестов на QA и PRODUCTION окружениях
3. Если merge request закрыт с неуспехом, то
3.1. Разработчику, которого изменения были затронуты, отправляется уведомление с указанием ошибки
https://habrahabr.ru/post/331690/
