ICL Services
Задать вопрос экспертам 8-800-333-98-70
Новости
16 Июля 2015
Новости

Готово!

Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook

Ok

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

Непрерывная интеграция (англ. Continuous Integration, далее CI) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения проблем интеграции результатов работы нескольких разработчиков.

Это не методика и не стандарт, это ПРАКТИКА, и она подразумевает постоянную работу и вовлеченность всех членов команды. Зачем? Да чтобы не дожидаться конца проекта для проведения интеграции и внезапного всемирного коллапса. Кроме того задача CI — обезопаситься от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры и кучи других непредвиденных или известных проблем.

С помощью интеграционных сборок можно избавиться от синдрома «не знаю, на моей машине всё работает». Также мы защищаемся от «плохого кода», часто повторяющихся багов, «кривых» слияний. CI увеличивает возможности обратной связи потому, что она позволяет следить за состоянием проекта в течение дня.


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

В нашей компании начался новый крупный ретейл-проект на .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.

Поделиться:

Новости по теме

    Свяжитесь с нами

    Контакты Пресс-службы
    Телефон 8 (800) 333-98-70

    pr@icl-services.com

    Будьте в курсе новостей

    Подпишитесь на рассылку и будьте в курсе наших последних новостей

    Подписаться на рассылку
    Спасибо, что подписались на рассылку новостей! Адрес подписки успешно добавлен! Ok
    Читайте нас на
    На сайтах icl-services.com используются cookie-файлы. Оставаясь на сайте, вы даете свое согласие на использование нами cookie-файлов. Если, прочитав данное сообщение, вы не согласны, просим вас покинуть сайт.