Build-Deploy-Test. Непрерывная интеграция

Как мы пришли к непрерывности

В нашей компании начался новый крупный ретейл-проект на .NET с использованием различных новомодных технологий, SOA. Разработка велась полностью с нуля, с постепенной интеграцией между компонентами. Разработка и тестирование компонентов проходили на разных материках.

Мы разрабатывали ядро, сервисные компоненты. Кроме того, нужно было протестировать производительность и установку-удаление компонентов. А также было требование к разработке — 100% покрытие кода юнит-тестами. В итоге у нас: автотесты, юнит-тесты, 4 тестовые среды, частично реализованные компоненты, «падающие» сборки и баги (куда без них?) и один тестировщик на 14 разработчиков. А хочется, чтобы всё само собиралось, устанавливалось, тестировалось и удалялось. И, конечно, очень хочется отдавать максимально стабильный и качественный результат основной команде тестирования.

Тестировать одному на 4-х системах, когда только у нас в команде 15 человек — мягко говоря, затруднительно. Поэтому мы решили попробовать подход Microsoft — Build-Deploy-Test. А успевать за разработкой тестировщику помогали следующие инструменты: TFS 2012, MSTest Manager 2012, Visual Studio 2012 Ultimate. Со временем перешли на 2013.

Мы решили сделать 2 CI сервера: Jenkins и TFS сервер. На первом у нас все собиралось раз в час в отладочном режиме (дебаг режиме). Затем происходила установка на сервер, прогон дымовых тестов (тесты, что приложение запускается) и после этого уже начиналась деинсталляция. Sonar запускал все модульные и интеграционные тесты раз в день, по ночам. Это решало проблему с нестабильностью сборки и скорейшего оповещения разработчиков о проблемах. На втором CI сервере (TFS build server) у нас сборка так же осуществлялась в отладочном режиме. Затем осуществлялась установка на тестовую машину и запуск функциональных автотестов. После того, как все тесты завершились (не важно, успешно или нет) происходила деинсталляция.

Мы решили сделать 2 сервера CI, чтобы отделить тесты разработчиков (модульные и интеграционные) от функциональных тестов тестировщиков. Сборки на Jenkins делались существенно чаще, чтобы реагировать на падающие тесты сразу. А сборки на TFS осуществлялись тестировщиком при необходимости и ежедневно по ночам, поскольку полный цикл функционального тестирования занимает много времени. Кроме того, чтобы всё строилось в Release конфигурации и код, как минимум, был всегда компилируемым, мы ввели Gated Check-in сборку. Когда программисты или тестировщик заливают изменения в TFS, сначала происходит сборка всей системы в Release конфигурации и изменения попадают в TFS только при условии его успешности. Если же есть проблема — изменения не применяются и сборка в TFS остается работающей.

Автоматизацию функциональных тестов мы начали с выбора их типов. Microsoft предлагает следующие:

• Модульные тесты (unit test), которые пишут программисты.
• Coded Ui Test — вид тестов, предназначенный для автоматизации функциональных тестов и тестирования пользовательского интерфейса.
• Web Performance Test — функциональное тестирование веб-приложений в рамках организации нагрузочных тестов (Load Test).
• Load Test — тесты для проведения нагрузочного тестирования веб-приложений.
• Generic Test — специальный вид тестов, который позволяет выполнять внешние тестирующие приложения.
• Ordered Test — позволяет организовать выполнение всех написанных автоматических тестов в определенном порядке.

В итоге, поразмыслив, мы решили, что нам больше подойдут generic и ordered тесты.

Generic тесту нужно указать *.exe файл и параметры, которые ему надо скормить. Каждый тест-кейс в TFS был связан с generic тестом. Для автотестов у нас было по одному проекту на каждый компонент и при запуске автотеста из TM, вызывается generic тест, который передает нужному *.exe файлу номер текущего автотеста, а дальше выполняется необходимый метод.

Далее на портале Хабрахабр более подробно о процессе Build-Deploy-Test.