Как мы заново открыли TFS

    Новое открытие 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 шага сборки:


    1. Starter — запускает перечисленные определения сборок. Каждая сборка запускается со своими настройками. Это позволяет полностью изолировать разные сборки, использовать разные агенты и разные переменные окружения.
    2. 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

    Поделиться публикацией

    Похожие публикации

    Комментарии 14

      0
      И всё равно, меня смущает, что Microsoft использует Jenkins для сборки .Net
        0
        TFS наружу не выставляется, а билды должны быть публичными.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            С чего бы? TFS не заточен на то, что бы к нему имели неограниченный публичный доступ — это внутренняя система.
            AFAIK для GitHub у них написан бот, который синхронизирует все с внутренним TFS.
          –2

          На TeamCity, им денег наверное жалко...

            0
            Было бы правильно сказать, не Microsoft, а конкретно командой dotnet. Jenkins там обсуловлен кроссплатформой прежде всего, и только во-вторых — ориентацией на столь разношерстную аудиторию столь крупного открытого проекта.
              +1

              Думаю дело в том, что:


              • это разные команды, а Сатья Наделла проповедует интеграцию вместо унификации.
              • Дженкинс начали использовать до того как в тфс появилась новая система сборки и линукс агенты.
              0
              Новая схема, к сожалению, не подходит для больших проектов (тут спорно, конечно, смотря каких), т.к. она не даёт той гибкости, которой давала предыдущая схема сборок (основанная на xaml).
                0
                Powershell? Какие кейсы с XAML нельзя сделать обычным билд скриптом?
                  0
                  Обработка результатов других тасок в vnext? Кастомные типы в параметрах сборок. .Net Api (да есть rest api, но...)
                  В своё время так и не нашёл способ, как это нормально сделать. Это как пример.
                    0
                    Результат выполнения cli утилит?

                    Вы передаете в параметры билд процесса типы? :)

                    Если надо вызвать .Net Api — Add-Type -AssemblyName «Your.Assembly.Name». Для REST Добавили еще аутентификацию по токену, который можно использовать в скрипте.

                    У меня два базовых скрипта Pre и Post build, они в свою очередь дергают все остальные активности, которые то же цепляются через PS. Это все вызывает SemVer скрипты, WebPack, собирает пакеты и пушит все в npm и nuget.
                      +1
                      По порядку.

                      Под .Net API я подразумевал API для vnext сборок, что-то вроде Microsoft.TeamFoundation.*

                      Например, в билде несколько тасок, одна у меня идёт последней и должна обрабатывать результаты предыдущих (грубо говоря). Чтобы она выполнилась, у других я выставляю «Continue on error». Но вопрос, как получить результаты других тасок через API?

                      PS: Чтобы не флеймить тут, можно перенести разговор в личку или обменяться контактами.
                        0

                        Прошу прощения, что влезаю, но это можно сделать и через REST API.


                        GET _apis/build/builds//timeline
                        Пример

                0
                *deleted*

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое