Варианты настройки системы CI

Неважно, какую именно систему CI (Continuous Integration) вы используете — Jenkins, TeamCity, или какую-то другую. Для всех них можно использовать варианты настройки:

• от операционной системы
• от плагинов

От операционной системы

Мы подготавливаем операционную систему машины, на которой будут гоняться автотесты.

Вот, скажем, в официальной инструкции Postman-а есть статья «Integration with Jenkins». Что нужно сделать, чтобы запустить тесты в Jenkins:

• Установить Jenkins
• Установить на ту же машину NodeJS и npm
• Установить на ту же машину newman

Установили? Теперь очень легко конфигурировать задачи — добавил shell-команду, а внутри нее вызов newman. И всё, ничего лишнего!

Это как раз вариант настройки от операционной системы. Если не установить newman на операционную систему, то задача в дженкинсе упадет с ошибкой:

newman: command not found

См также: причины ошибки «newman: command not found», если вроде все установил

Такой вариант настройки хорош как раз для автоматизации тестов из Postman-а. Если у вас нет CI, но очень хочется начать — вариант идеальный. Jenkins можно развернуть даже на своей машине! Хотя лучше попросить администратора выделить отдельную виртуалку. Вам ее хватит за глаза.

Подход работает плохо, если вы много чего делаете в системе CI:

• собираете билд;
• гоняете тесты, внутри которые есть зависимости;
• деплоите билд — поднимаете его на каком-то окружении.

Если задач становится много, нужно увеличивать количество агентов — машин, на которых гоняются автотесты. И каждую нужно настраивать. Если первые машины настроивались постепенно, врядли остались записи, что надо установить. Поэтому разработчики прикидывают:

— Так, для сборки надо это. Для автотестов то. Вроде все.

А потом начинается «тестирование в продакшене». То есть вроде настроили машину, и начинаем гонять на ней все виды сборок. Смотреть, что развалилось, и донастраивать машину.

В хорошем варианте при этом создается чек-лист «что нужно установить на билд-агент». В плохом думаем «А-а-а-а, ладно, нам этого надолго хватит». Поэтому когда через полгода-год купят новую машину, придется снова несколько дней собирать старые грабли.

И даже когда есть чек-лист настройки, бывают фейлы. Особенно если он большой — что-то просто забудем настроить. А потом придется ломать голову, почему на новом агенте сборка не собирается, чего ему не зватает.

Итого 

• Плюсы подхода — легко начать, удобен для первых автотестов
• Минусы — плохо масштабируется. Каждый новый билд-агент приходится настраивать заново с нуля, ничего не забыв при этом.

Отлично применим для первого опыта знакомства с CI.

От плагинов

Операционную систему мы не настраиваем. Хотя обычно есть план-минимум. У нас, например, админ ставит на новые билд-агенты java. На этом всё.

Всю остальную работу выполняет сервер CI. Если вернуться к примеру с автотестами Postman-а, то внутри задачи мы не просто пишем:

newman run collection.json

Мы сначала устанавливаем этот самый newman на машину! Прямо внутри задачи. Для этого мы пишем более сложный скрипт. В Jenkins используется Pipeline — скриптовый язык для настройки задач. В TeamCity другой настройщик, но сути это не меняет.

В скрипте мы сначала подготавливаем окружение:

• Устанавливаем все, что нужно
• Изменяем параметры машины под наши нужды
• ...

А потом уже запускаем тест. Или сборку.

Почему вариант называется «от плагинов»? Потому что вам потребуется установить всяко-разные плагины в вашу систему CI, которые помогут вам в настройке окружения. 

Пример настройки автотестов  Postman-а в этом варианте можно посмотреть в статье «Postman and CI». Там уже выполняется чуть больше действий. Зато автотесты лежат в репозитории!

Этот вариант отлично масштабируется — да, придется повозиться с настройкой задач. Но это не так долго, ведь нам не надо страдать с КАЖДОЙ задачей. Скорее, с каждой новой задачей. А однотипные мы настраиваем по шаблону — копируем уже работающий вариант и немного изменяем.

Один раз настроили:

• сборку билда
• прогон unit-тестов
• прогон api-тестов
• прогон api-тестов в Postman-е

А потом уже делаем по аналогии. Зато мы один раз настроили — и вообще не паримся, сколько у нас билд-агентов. Админ докупил парочку новых? Не проблема, их можно использовать сразу же. Никакой настройки, или минимальная настройка — и всё работает.

Итого

• Плюсы подход — отлично масштабируется, вообще никакой зависимости от компьютера, на котором будет проводиться сборка
• Минусы — сложнее в настройке, особенно в первый раз

Подход применяется в реальной работе, где куча самых разных задач выполняется. А отсюда вытекает много требований к машине, на которой выполняется задача. Лучше их все один раз прописать, чем много раз геммороиться с настройкой.


PS — статья написана в помощь студентам моего курса по автоматизации в Postman-е