26.06.2017 13:27
Ilusa 3 899 Источник
Процесс тестирования можно построить разными способами. Один из эффективных методов автоматизации процесса тестирования это непрерывное тестирование в рамках непрерывной поставки ПО. Непрерывное тестирование позволяет стабилизировать и улучшить качество кода. Т.к. любое приложение начинается с разработки, то необходимо внедрять полноценное тестирование в циклы разработки.

Основная идея непрерывной поставки в том, чтобы построить конвейер (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 окружениях.
image

Рис.2. Результат выполнения одного из этапов проверок.
image

Рис.3. Обнаружение ошибки на одном из шагов выполнения работы
image

Пример построения 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 окружения
image

Рис.5. Результат успешного выполнения pipeline с развертыванием и запуском тестов на QA и PRODUCTION окружениях
image

Рис.6. Результат не успешного выполнения pipeline с развертыванием и запуском тестов на QA и PRODUCTION окружениях
image

3. Если merge request закрыт с неуспехом, то
3.1. Разработчику, которого изменения были затронуты, отправляется уведомление с указанием ошибки
Поделиться с друзьями
-->

Комментарии (3)


  1. SyrexS
    26.06.2017 16:37
    #10283628

    Если я правильно понимаю, то Deploy Prod — это выкладка бинарников в Production
    А если Smoke тесты не прошли — то неверный код так и остается в PROD?


    1. Ilusa
      26.06.2017 17:17
      #10283746

      Добрый день!
      Да, если smoke тесты не прошли, то откат до старой версии не происходит. В данном случае все чинится хотфиксом.
      В smoke тесты, которые запускаются на PROD, стоит добавлять только самые основные сценарии. Раз на CHECK, DEV и QA стендах наборы тестов прошли успешно, а на проде завалились, то скорее всего дело обстоит с конфигурациями.


  1. EreminD
    26.06.2017 23:42
    #10284368

    При всем уважении к автору статьи: а про то статья то?
    Безусловно, тестирование — важный этап. Автотесты теряют в цене, если они не запускаются автоматически, а ждут, когда кто-то нажмет кнопку. Они должен быть неотъемлемой частью CI/CD-процессов. И да, нам может подойти Jenkins для этого. Но все это — академические знания, которые мало оспариваются.
    Но очень много вопросов:

    • а зачем вам pipeline? вы могли сделать простую джобу и там описать там щаги тестирования и деплоя. Pipeline в данном примере (в том виде, в котором мы его видим) — просто перечисление шагов
    • очень хочется увидеть технических подробностей. Как у вас выглядит деплой на тест и на прод? Как вы менеджерите конфигурации? Как запускаете тесты и с помощью чего смотрите результаты? Это какое-то классическое решение или вы, учитывая особенности вашего проекта и тестов, собрали свой велоосипед? Расскажите про велосипед. Это всегда интересно!
    • как вы научили дженкинс отслеживать, закрыт ли мердж реквест, чтобы он слал уведомления?

    CD — сложный и тернистый путь, он всегда начинается с найденного в интернете успешного похожего примера, а заканчивается пачкой прикрученных плагинов, скриптов и самописных решений.
    Я не могу быть уверен, но думаю, что все те минусы, что стоят к этой статье отчасти появились по этим причинам
    Еще раз выражаю уважение коллеге и надеюсь, в дальнейшем, прочитать технически-обогащенные рассказы о своих победах в работе
    Спасибо