Новое открытие TFS
Какая первая ассоциация возникает, когда слышишь словосочетание Microsoft TFS? Что-то большое, неповоротливое и корпоративное. Именно так и было до появления Visual Studio Team Services и выхода MS TFS 2015. Первый — это облачная версия Team Foundation Server, которая опережает в развитии частную (private) версию примерно на три месяца. Одним из главным нововведений обновленного TFS/VSTS стала новая система сборок. Эта система позволяет достаточно просто писать свои шаги сборок, которые могут делать что угодно — от собственно сборки проекта до автоматического заведения дефектров и рассылки нотификаций. Кроме этого новая версия предоставляет развитый REST API для манипулирования задачами, дефектами и практически любыми сущностями в базе данных TFS.
Именно поэтому когда перед нами встал выбор новой системы управления жизненным циклом разработки, мы остановились именно на этой новой версии MS TFS. Мы используем TFS для полного цикла — планирование-разработка-тестирование-развертывание, и, поначалу все шло достаточно гладко. С ростом сложности задач, которые мы ставили перед системой сборки, появлялись и проблемы. К счастью, REST API и собственные шаги сборки позволили их с успехом решить. Далее я расскажу о проблемах и о том, как мы их решили.
Как не выйти в окно, когда нужно больше тестов
Нам нужна была сборка, которая запускает автотесты. Просто? Но идея была в том, чтобы объединить в нее несколько тестовых запусков по разным системам и отображать единый отчет о прохождении теста. Решение — сделать сборку с несколькими тестовыми запусками. Все было хорошо, пока мы не начали вылезать за пределы временного окна — тестовые запуски выполнялись последовательно один за другим. И не существовало решения "из коробки" для распараллеливания сборок. И пришла простая идея — мастер-сборка:
- запускает отдельные сборки на других агентах (параллельно)
- ожидает их завершения
- забирает себе их тестовые результаты, если есть
Из реализации этой идеи и родилось расширение Parallel Builds
Для обеспечения параллелльности в расширении содержится 2 шага сборки:
- Starter — запускает перечисленные определения сборок. Каждая сборка запускается со своими настройками. Это позволяет полностью изолировать разные сборки, использовать разные агенты и разные переменные окружения.
- Awaiter — ожидает выполнения запущенных сборок и собирает их тестовые результаты. Кроме этого он добавляет на страницу Summary текущей сборки ссылки на "оригинальные" сборки. Это нужно в первую очередь для того, чтобы можно было просмотреть консольный вывод и логи этих сборок в случае возникновения проблем.
В простейшем случае мастер-сборка состоит всего из двух шагов:
расширение работает и в облачном VSTS и в частном TFS. Написано на typescript поэтому требует агента версии 2.0.
Пусть дефекты создает робот — он железный
Автоматизация тестирования, она не в количестве автотестов, а в головах. Поэтому после третьего подряд разбора провалившихся тестов в тестовых запусках было решено переложить этот "интеллектуальный" труд на робота. Еще одно расширение? Именно так. Идея была в следующем:
- взять результаты прохождения тестовых запусков
- получить имя провального теста
- получить сообщение об ошибке
- создать дефект и назначить его на ответственного за этот тестовый запуск
Так в составе расширения Parallel Builds появился шаг — AutoDefects.
Автоматическое создание дефектов позволяет обеспечить обязательность реакции на провал теста, отследить жизненный цикл и собирать статистику о типе провала — дефект автотеста, развертывания среды или функциональный дефект тестируемой системы.
Jenkins не делится результатами — исправим
Разработка у нас ведется в кросс-функциональных командах и процесс разработки допускает использование командами своих инструментов разработки. С одним условием — они должны быть интегрированы с TFS. Некоторые команды по разным причинам используют для сборки Jenkins. Текущая версия интеграции TFS и Jenkins позволяет запустить сборку на Jenkins и дождаться ее выполнения. Но, к сожалению, не импортирует результаты выполнения тестов в этой сборке.
К счастью, с недавнего времени Microsoft поддерживает движение свободного ПО и публикует некоторые свои разработки на GitHub. Сборочные задачи для TFS в их числе
И вот pull request, который добавляет к JenkinsQueueJob функциональность импорта результатов из Jenkins. Кроме этого он позволяет добавить ссылки (относительные задачи в Jenkins) на Build Summary page в TFS. Например, можно добавить ссылку на артефакты этой сборки, которые хранятся на Jenkins сервере или дополнительные отчеты, например, Yandex.Allure
Новая версия TFS/VSTS позволяет настроить себя под совершенно разнообразные задачи и уже не похоже на того монстра, каким представлялся TFS раньше. А учитывая, что для небольших команд использование VSTS бесплатно, то он может быть инструментом не только для корпораций, но и для "стартапов".
Как всегда исходный код доступен на GitHub
Автор: qualife
