Downloaded 12 times
Uploaded bySQALab
CI: Автоматизация сборки, развёртывания и тестирования
Документ описывает автоматизацию сборки, развертывания и тестирования для крупного розничного проекта на платформе .NET, разрабатываемого с нуля. Он включает в себя использование различных инструментов, таких как Microsoft TFS и Jenkins, для обеспечения непрерывной интеграции и автоматизированного тестирования. В документе также подчеркиваются важные аспекты, такие как раннее обнаружение ошибок и подход к тестированию компонентов, разрабатываемых в нескольких странах.
More Related Content
Similar to CI: Автоматизация сборки, развёртывания и тестирования
CI: Автоматизация сборки, развёртывания и тестирования
- 1. Сарварова Руфина, RussiaGDC, Kaзань CI: Автоматизация сборки, развёртывания и тестирования 1
- 2. Непрерывность? Раннее обнаружениеи устранение ошибок и противоречий Мир за пределами рабочей среды разработчика Постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т. п. Быстрая обратная связь 2
- 3. А почему быи нет? Крупный Retail проект на платформе .NET Разрабатывается с нуля Разработка компонентов для него происходит в Италии, Финляндии, в России, Америке, Австралии. Тестирование проходит в России, Америке, Филиппинах. Автоматизированное тестирование Тестирование установки 100% покрытие кода юниттестами 3
- 4. И понеслась.. Есть: •Автотесты, юнит тесты • 4 тестовые среды • Частично реализованные компоненты • «падающие» билды Должно быть: • Сборка последних исходников • Установка на «чистые» системы • Тестирование • Удаление, чистка тестовой системы 4
- 5. Бог в помощь! Инструменты: Microsoft TFS 2012, TFS Build, Microsoft Test Manager Build-Deploy-Test подход 2 CI сервера: Jenkins (для юниттестов) и TFS (для функциональных автотестов) Gated Check-in build 5
- 6. Виды автотестов UnitTesting: Basic Unit Test Unit Test Unit Test Wizard Database Unit Test Coded UI Test Web Performance Test Load Test Generic Test Ordered Test 6
- 7. А как? Microsoft Test Manager TA Результатытестирования Scheduled For Test System X Scheduled For Test System Y TC Team Foundation Server Test Environment Y Параметры запуска TA BC BA Build Server 7 Test Environment X
- 8. Конфигурации Deploy.bat Test System Clean.bat tmp tests Test Controller Base configurations NewConfiguration Call Deploy.bat Call Clean.bat Deploy.bat Clean.bat Drop Folder tests Base configurations Build Server 8
- 9. Всѐ идѐт поплану Scheduled Build for X Test Settings A Test Environment A’ Test machine X TC TA Test Environment A’ Continuous Integration Test Plan Scheduled Build for YZ TA Test Settings B Test Environment B’ Test machine Y Test Environment B’ TC 9 TA Test machine Z
- 10. Выконфигурировали! Проблемы сTest Manager Копирование библиотек Установка, удаление msi пакетов Полная автоматизация установки, удаления 10
- 11. А пока тестируется… Анализ результатов Баг-трекинг и верификация Тест дизайн Поддержка и разработка Запуск регресс тестов 11
- 12. А пока тестируется… И пьѐм кофе 12
- 13. А у другихкак? 13
- 14.
- 15.
- 16.
Editor's Notes
- #3 Непрерывная интеграция — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Так гласит википедия.Подчеркну что это не методика и не стандарт, это ПРАКТИКА, и она подразумевает постоянную работу. Зачем? Да чтобы не дожидаться конца проекта для проведения интеграции и внезапного всемирного коллапса. Кроме того задача CI — обезопасится от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры.С помощью интеграционных сборок можно избавиться от синдрома «не знаю, на моей машине всё работает». Также мы защищаемся от “плохого кода”, часто повторяющихся багов, “кривых” merge. CI увеличивает возможности обратной связи потому, что она позволяет следить за состоянием проекта в течение дня.
- #4 И как же я дошла до такой жизни. У нас начался новый мега-крупный ритейл проект на .NET с использованием различных супер-пупер новых технологий, разработка ведётся полностью с нуля, с постепенной интеграцией между компонентами. Разработка и тестирование проходят на разных материках. Все компоненты взаимосвязаны.И я отвечаю за тестирование компонентов, которые разрабатываются у нас в казани. Зачастую эти компоненты без UI вообще. Кроме того, нужно было протестировать производитьльность и установку-удаление компонент. И ещё было требование – 100% покрытие кода юнит-тестами.
- #5 В итоге у насимеются: автотесты, юнит тесты, 4 тестовые среды, частично реализованные компоненты, падающие билды и баги. Куда без них.А хочется чтобы всё собиралось, ставилось, тестировалось и удалялось.
- #6 Тестировать единственномутестировщику на 4х системах, когда только у нас в команде 15 человек… мягко говоря … затруднительноЗаоснову мы взяли подход MS – Build, Deploy, Test.А успевать за всеми разработчиками тестировщику помогали следующие инструменты:TFS 2012, MSTest Manager 2012, Visual Studio 2012 Ultimate.Мы решили сделать 2 CI сервера : Jenkins и TFS. На первом у нас раз в час происходит билд в Debug режиме, установка, прогон всех юнит тестов, деинсталляция.Эторешает проблему с нестабильностью билдов и юнит тестов и скорейшее оповещение о возможых проблемах.На втором у нас сборка так же осуществляется в дебаге, происходит установка, запуск функциональных автотестов и деинсталляция.Кроме того, чтобы всёбилдилось в Release и код как минимум был всегда стабильно компилированный, мы ввели Gated Check-inбилд. Когда программисты или тестировщик заливает изменения в TFS, сначала происходит билд всей системы в Release конфигурации и изменения попадают в TFS, только при условии его успешности.
- #7 Начали мы с выбора типа автоматизации. MS предлагает несколько типов тестов :Модульные тесты, на которых мы останавливаться даже не будем, это удел программистов.CodedUiTest – вид тестов предназначенный для автоматизации функциональных тестов и тестирования пользовательского интерфейса;WebPerformanceTest – функциональное тестирование веб-приложений в рамках организации нагрузочных тестов (LoadTest);LoadTest – тесты для проведения нагрузочного тестирования веб-приложений;GenericTest – специальный вид тестов, который позволяет выполнять внешние тестирующие приложения;OrderedTest – позволяют организовать выполнение всех написанных автоматических тестов в определенном порядке;мы выбрали generic и ordered тесты. Просто потому что только они нам подходят.Но дабы не плодить кучу ехе-шек для каждого теста, мы сделали по одному проекту на каждый компонент и при запуске автотеста из TM, вызывается generic тест, который передает нужному exe файлу номер текущего автотеста.
- #8 Процесс Build-Deploy-Test в целом выглядит следующим образом: Разработчики делают изменения, перед заливкой изменений Build Server билдит всё в debug конфигурации и если билд проходит, изменения заливаются на сервер.По Build-Deploy-Test подходу имеется 3 роли – Build Controller, Test Controller и Test Agent. У нас Build Controller совпадает с казанским Build Server и c Test Controller.Build Controller следит за билдами проекта, он собирает бинарники в папку билда (Gated Check In тут не подходит, для тестирования были отдельные билд конфигурации). Тест контроллер нужен для управлением запусками, хранения результатов тестирования. А тест агент получает команду от ТС о запуске набора тестов, команду на деплой и все параметры запуска, в том числе набор generic тестов.Тестировщик открывает TM, выбирает там тест план, который ей нужен, выбирает конфигурацию для запуска, билд, который будет использоваться, и тестовую среду. И всё. Всё остальное делает ТС. Он получает набор параметров для тестового запуска (включая расположение папки с бинарниками). Запускает на тестовой среде установку.После того, как отработает скрипт деплоя, ТА запускает поочерёдно все выбранные тесты. После выполнения всех тестов запускается скрипт очистки, который удаляет приложение и подчищает за собой тестовую систему.Далее ТА передаёт управление ТС, сообщая ему о своей готовности. ТС забирает все временные папки тестового запуска, помещает результаты в TFS – их потом можно посмотреть через TM и отображает результат тестов в TM – успешно выполненные тесты и зафейленные тесты.
- #9 Рассмотрим подробнее, что происходит на тестовой системе.Изначально у нас есть билд сервер в которой хранится билд в директории. В ней же находятся и generic тесты.После запуска TC создаёт на тестовой машине временную папку, куда копирует generic тесты и создаёт свой deploy.bat и clean.bat. Эти скрипты состоят из 2х частей – первая это определение всех переменных запуска, в том числе и название директории билда, а вторая часть – содержимое deploy файла, который мы указали для этих тестовых настроек.Таким образом, получается, что TC создаёт обертку для скрипта, который мы ему указали как deploy скрипт (назовём его Call Deploy скрипт).В нашем случае этот скрипт, выполняет копирование всей директории билда на тестовую машину, затем он вызывает другой скрипт установки – Deploy скрипт, который был в этом билде.Нам это нужно, чтобы скрипт деплоя имел версионность, чтобы он мог обновляться вместе с билдом. Этот скрипт уже выполняет все приготовления к установке, поскольку все скрипты выполняются в одной среде окружения, они имею доступ к переменным, которые передал им TC.Используя их, скрипт обновляет конфигурацию и выполняет установку приложения.После завершения Deploy, к работе приступает TC, который даёт задание TA о выполнении тестов (тех самых generic тестов, которые он положил во временную папку).Эти generic тесты вызывают exe файл по указанному им пути и передают программе в качестве параметра номер тест-кейса. Программа с автотестами устроена так, что в зависимости от полученного параметра, она вызывает определенный метод.После того, как все автотесты выполнены, TC начинает процесс очистки. Для этого он вызывает скрипт-обёртку, который создал вначале. Он определяет параметры и вызывает Call Clean скрипт, который лежит на всех тестовых системах. Call Clean запускает Clean скрипт, который выполняет деинсталляцию приложения, затем собирает все логи, архивирует их и перемещает их во временную папку запусков, созданную TC.После этого
- #10 У нас есть билды по расписанию, которые запускают Build-Deploy-Test подход. Для этого указывается специальный темплейт процесса в определении билда. Раз в неделю происходит запуск такого билда. В его настройке указано, какие тесты нужно выполнять и с какими настройками и на какой тестовой среде должны запускаться тесты. Весь процесс начинается с запуска Build Controller, который подает на Build Agent параметры для сборки (Какие проекты, в какой конфигурации) После того, как Build Agent соберёт всё, Build Controller передаёт управление Test Controller-у вместе с параметрами для запуска автотестов – это набор автотестов, какая тестовая среда и тестовые настройки. У нас для каждой тестовой среды используются свои тестовые настройки и соответсвенно свой билд.После запуска TC он начинает процесс деплоя, затем передает на TA тестирование и затем TC запускает скрипт очистки системы.Если тестовая среда состоит из 2х машин, то это должно быть указано в TM, для них создается одна тестовая среда, в которой будет 2 машины. На каждую машину ставится свой TA, для машин можно задать отдельную роль, к примеру Database Сервер и Клиент. В таком случае при запуске будет происходить то же самое, никто кроме TC не знает, что тестовая среда состоит из 2х машин.
- #11 Каждый этап отладки такого процесса имел свои сложности. Кто из вас работал с MTMподнимите руки? Чудесный инструмент, там есть отличные фичи по запуску на тестовых системах, по сбору логов, там есть возможность Exploratory testing – когда вы выполняете произвольную последовательность действий, а он записывает все ваши шаги, может даже с видео и аудио. А потом вы можете создать по сгенерированным им шагам баг или тесткейс или и то и другое.Однако и с ним проблем было достаточно.это и были проблемы с путями к билдам и конфигам , и использования power shell скриптов и sleep в батниках. Как оказалось, ps там просто не запускается, только cmd или bat. И более того, если задать ему использование батника и из батника вызывать ps скрипт, TM игнориует этот вызов. Точно так же он игнорирует и все sleep, wait и даже пинг несуществующего хоста с таймером. Приходилось даже для таких простых вещей писать отдельные тулзы, которые запускались из батника. По мере эволюции проекта, эволюционировали и тесты. Сначала это был набор библиотек, поэтому можно было в деплой скрипте просто копировать их и запускать тесты, а затем удалять их и все были счастливы.Затем наши доблесные разработчики обернули всё в msi-пакеты, которые надо было запускать с множеством параметров. И удалять соответственно. Здесь уже задача усложнилась с изменениями параметров, которые надо подавать. Для этого мы использовали те параметры, которые ТС передает ТА. Этого хватало.Потом появилось много msi-ек, которые надо ставить в определённой последовательности и с множеством параметров и конфигов. Для того чтобы конфигурация проходила в зависимости от тестовой системы, я написала специальную тулзу, которая подменяла все строки подключения с дефолтной на нужную, подменяла все пути, параметры и прочее.После установки мсаек нужно было запускать сервисы. И казалось бы, что тут сложного. Но нет, тут то я и столкнулась с проблемой TM. Сервисы зависели друг от друга. Поэтому сервисы нужно было запускать в определенном порядке и ставить некоторый период ожидания между запуском следующего сервиса.Как я уже говорила, ТМ при запуске deploy скрипта почему то игнорирует команды ожидания и просто выполняет следующие. Поэтому я добавила свою программку которая делает только Sleep но с перехватом управления от батника, поэтому он ждёт завершения её выполнения.Ещё нужно было сделать удаление – работа с MSMQ очередей. Простыми батниками эту задачу не решить, поэтому я написала на PS такой скрипт. Но тут меня ждал очередной подвох – ну не хочет MS работать со своим прославленным ps. Непонятно почему. Окай. я добавила ещё одну утилитку в виде всё того же ехе файла.Финальным (на данный момент) этапом установки стала одна единственная програмка с юзер интерфейсом, в которой выбираются нужные компоненты и параметры и она уже сама запускает все необходимые msi-ки с параметрами. Аналогично удаление.Здесь нужно было сделать так называемую unattended установку. К счастью, установщик имел такую опцию. Я подсовываю ему сконфигурированный xml файл с нужными мне параметрами (частично использую те, что могу передать с TC) для установки и удаления и он может ставить всё сам, без UI и заполнения полей. Всё остальное происходит так же. Итак, мы автоматизировали и поставили весь процесс. А что же делает тестировщик пока всё автоматизированно тестируется?
- #12 Анализирует результаты запусковавтотестов, заводит, обновляет баги, проводит верификацию багов, Пишет тест дизайн.Запускает регресс тестыПравда основное время занимает поддержка автотестов и конфигураций, а также создание новых автотестов.Ну и ещё..
- #13 Пить кофе с печенюшками
- #14 Итак, возвращаясь к CI, согласно статистике 50% проектов не использует CI. Для тех, кто использует существует множество как платных так и бесплатных CI серверов, пожалуй самый популярный из них Jenkins. Конечно средства достижения непрерывной интеграции могут значительно отличаться от проекта, от предпочтений, традиций и политики компании. И каждый должен сам для себя решить, нужно это на его проекте или нет. Мы для себя выбрали непрерывность.
- #15 А в результе мы получили то, что хотели, а не то, что получилось.