Team foundation server что это

Обновлено: 04.07.2024

Microsoft Visual Studio Team Foundation Server — это основа решения Microsoft для управления жизненным циклом приложения (ALM), предоставляющая базовые службы: контроль версий, отслеживание рабочих элементов, отчетность и автоматизированные построения.

Foundation Server помогает организациям эффективнее взаимодействовать и сотрудничать в процессе проектирования, разработки, тестирования и развертывания программного обеспечения. Это в конечном итоге приводит к повышению производительности и эффективности работы команды, улучшению качества и повышению прозрачности жизненного цикла приложения.

Корпорация Microsoft лицензирует Team Foundation Server в рамках модели лицензирования «сервер — клиент», следовательно организации должны иметь лицензии на каждый запущенный экземпляр Team Foundation Server (то есть на каждый сервер) и, с некоторыми исключениями, лицензии клиентского доступа на Team Foundation Server 2012 для каждого пользователя или устройства, обращающегося к Team Foundation Server. [Источник 1]

История

TFS существует уже более десятилетия и развивается с момента его создания в 2005 году. В отрасли есть профессионалы, чья карьера полностью посвящена управлению Microsoft TFS. Практическое руководство необходимо для работы с изменениями базы данных и пакетами обновлений, которые добавляют множество новых функций. Также в 2005 году TFS было трудно использовать, потому что он был создан, когда пользовательский интерфейс (UX) не был главным приоритетом для Microsoft.

В 2012 году TFS превратился в инструмент, помогающий командам управлять проектами разработки ПО с использованием Agile. Одной из главных причин популярности Agile стало то, что компании уже имели лицензии Microsoft. Это был простой выбор.

Чтобы помочь командам управлять требованиями и ошибками, TFS создал специальный инструмент ALM. Этот легкий инструмент может управлять некоторыми требованиями, но не имеет надежной и гибкой модели, которая может поддерживать крупномасштабные глобальные команды. Когда дело доходит до тестирования, TFS не дает видимости шагов тестирования и не определяет четкой связи между ошибками и неудачными тестами.

Что касается контроля версий, у TFS было несколько разных подходов. Team Version Version Control (TFVC) была одной централизованной системой контроля версий. Эта система сохраняла исторические данные с использованием ветвей на основе маршрутов, созданных и поддерживаемых на сервере Windows. [Источник 2]

Пусть дефекты создает робот — он железный

Автоматизация тестирования, она не в количестве автотестов, а в головах. Поэтому после третьего подряд разбора провалившихся тестов в тестовых запусках было решено переложить этот "интеллектуальный" труд на робота. Еще одно расширение? Именно так. Идея была в следующем:

Так в составе расширения Parallel Builds появился шаг — AutoDefects.

Автоматическое создание дефектов позволяет обеспечить обязательность реакции на провал теста, отследить жизненный цикл и собирать статистику о типе провала — дефект автотеста, развертывания среды или функциональный дефект тестируемой системы.

Работа с Visual Studio Team Foundation Server 2010

Данная статья будет полезна тем, кто не устанавливал и не использовал Visual Studio Team Foundation Server раньше. TFS может быть частью очень сложной инфраструктуры, которая включает отчеты, интеграцию с SharePoint, множественные домены, распределенные базы данных и т.д., но я не собираюсь затрагивать эти области. Моя основная задача – это помочь разобраться с базовыми элементами TFS (система контроля версий, система отслеживания ошибок и заданий и система автоматических сборок) и начать использовать данную систему.

Предисловие

Для начала давайте рассмотрим, почему именно Team Foundation Server? TFS создана с целью интегрировать средства разработки для более быстрой и комфортной работы. Вы можете сами интегрировать разные системы вместе:

В этом случае каждая система имеет собственно хранилище данных, собственный набор идентификационных данных, собственные команды и инструменты. Конечно, это возможно, но при работе с такой системой будет уходить много времени на переключение между компонентами и поддержку.

TFS представляет собой систему, которая интегрирует все необходимые компоненты вместе.

В зависимости от необходимости, вы можете использовать только часть компонентов.

Существует множество способов для получения доступа к функционалу TFS. Если вы программист, то вероятно вы будете себя комфортно чувствовать, используя Visual Studio. Если вы тестировщик, вы можете использовать новый Team Explorer в качестве клиента, без необходимости устанавливать Visual Studio. Если вы руководитель проекта, то вы можете получить доступ к информации через web браузер или Excel, Microsoft Project или даже MOSS.

Установка TFS 2010

Забегая вперед, скажу, что этот процесс стал, как ни когда простым. Поэтому я решил не публиковать подробную инструкцию по установке (если же с установкой возникнут проблемы, рекомендую прочитать статью Установка Visual Studio Team Foundation Server 2010), а ограничиться лишь теоретическими знаниями.
Рассмотрим основные преимущества, которые предлагает новая версия TFS.

TFS 2010 может быть установлен на контроллере домена. Разработчики TFS поняли, что многие небольшие организации не имеют возможность использовать выделенные серверы. Теперь если у вас есть только один сервер, который является контроллером домена, сервером электронной почты и т.п., появилась возможность установить на этот сервер и TFS 2010.
TFS 2010 может быть установлен на персональные операционные системы – TFS 2010 устанавливается на Vista и Windows 7 Home Premium и выше. Ну и конечно, поддерживаются серверные операционные системы (Windows 2003, Windows 2008 и Windows 2008 R2). Теперь у вас появилась возможность запустить сервер управления версиями прямо на вашем рабочем ноутбуке.
TFS 2010 может работать и на 32 и на 64 битной операционной системе!

После установки TFS в «Basic» режиме вы получаете: систему управлениями версиями, систему отслеживания ошибок и систему автоматизации сборок (непрерывное интегрирование – проще простого!). Для полного комплекта не хватает компонентов: SharePoint и системы отчетов. Данные элементы присутствуют в режиме “Standard”. Еще одна хорошая новость в том, что вы уже установили TFS 2010 “Basic” и теперь вы можете просто добавить компоненты по мере необходимости, без полной переустановки системы.

Система контроля версий в TFS 2010

И так после того, как вы получили достаточный багаж теоретических знаний и установили TFS 2010 самое время приступить к работе. В данной главе я рассмотрю основы по использованию системы контроля версий, которые предоставляет TFS 2010.

Предполагается, что у вас на компьютере уже установлен TFS 2010 и имеется Visual Studio 2010.

И так, первое что нам необходимо сделать, это подключить Visual Studio к TFS. Для этого воспользуйтесь главным меню (Team) или ссылкой на домашней странице:

Система попросит указать адрес существующего TFS. В моем случае мой Windows 7 ноутбук называется dionnis-pc.

После этого, окно Team Explorer должно содержать название соединения с сервером и DefaultCollection. Но на текущий момент у нас нет не одного добавленного проекта.

В поем случае, для примера я использую код Enterprise Library, но на самом деле, можно было ограничиться стандартным приложением (File, New Project, Windows Forms). Если вы сейчас попробуете добавить проект в репозиторий системы контроля версий, то Visual Studio выдаст ошибку:

Ошибка означает, что вам необходимо создать проект в TFS, который будет все компоненты необходимые для вашей работы. И так, нам сначала необходимо создать новый проект:

В следующем диалоговом окне необходимо указать название проекта и краткое его описание:

Теперь Visual Studio просит указать методологию, которую мы будем использовать при разработке нашего приложения. По умолчанию – Agile (гибкая методология разработки), но так же можно выбрать и CMMI. Для дополнительной информации по методологиям я рекомендую почитать MSDN. Я рекомендую остановиться на Agile, если вы не знаете что именно для вас подходит или если вы используете одну из гибкий методологий разработки (например TDD).

И так, наконец, Team Explorer отображает элементы текущего проекта: Work Items, Builds и Source Control.

Теперь вы можете добавить ваш проект в репозиторий.

Сейчас необходимо указать папку, в которой будет храниться наши данные.

При успешном завершения работы, Solution Explorer пометит файлы, которые претендуют на помещение в репозиторий символом “+”. Так же вы увидите список действий, которые необходимо выполнить для того, что бы поместить ваше приложение в репозиторий. Просто добавьте комментарий и нажмите Check-In:

Процесс добавления файлов в репозиторий необходимо подтвердить:

И так, поздравляю! Вы добавили свой проект в репозиторий!

Cистема отслеживания ошибок в TFS 2010

После того, как мы разобрались, как работать с системой контроля версий, самое время рассмотреть принцип работы системы отслеживания ошибок.

Записи об ошибках и заданиях в Visual Studio относятся к рабочим элементам (work items). Создать один из видов рабочих элементов можно непосредственно из панели Team Explorer в Visual Studio. Это же можно сделать, используя web интерфейс или инструменты Visual Studio Test и Lab Management. В нашем случае я использую панель Team Explorer:

Поскольку мы только начали работу над проектом, то в списке не должно быть никаких записей.

Теперь если обновить список ошибок, то можно увидеть только что созданную запись.

Если все прошло гладко, то файл будет содержать отметку, о доступности для редактирования.

После редактирования, панель Pending Changes в Visual Studio сама покажет список файлов, которые претерпели изменения.

Поскольку мы исправляли ошибку, необходимо сделать запись об этом:

После того как отметили исправленную ошибку и добавили комментарий, можно смело копировать файлы в репозиторий:

Теперь можно убедиться, что статус ошибки изменен, и получить дополнительную информацию о подробностях исправления.

Еще один способ работать с TFS

Получить доступ к рабочим элементам проекта, можно используя web интерфейс. Для этого необходимо просто использовать адрес вашего сервера:

Данный метод может оказаться наиболее эффективным для людей, которые не привыкли работать с Visual Studio. Так же есть возможность использовать Excel и Microsoft Project.

Сборки в TFS 2010

Для полного (минимального) комплекта не хватает только научиться работать со сборками. С этим пробелом и призвана бороться данная глава статьи.

Для начало необходимо определить параметры сборки. Для этого воспользуемся уже знакомой панелью Team Explorer в Visual Studio.

Тут я хочу немного рассмотреть возможные параметры.

Особый интерес представляет вкладка Trigger. На этой вкладке вы можете задать события, на основе которых будут собираться сборки:

Manual – сборка задается вручную, по требованию.
Continuous Integration – сборка происходит сразу после check-in’а (после копирования файлов в репозиторий). Данный метод очень эффективен, если вы хотите делать сборки не дожидаясь объединения изменений.
Rolling builds – метод, при котором все изменения будут собираться пока выполняется предыдущая сборка. Данный метод рекомендуется использовать, если у вас очень большой проект и сборка занимает много времени (больше, чем скорость с которой вносятся изменения).
Gated Check-in – данный метод позволяет быть уверенным, что все изменения корректно компилируются, до того как файлы попадут в основной репозиторий.
Scheduled – метод, при котором вы задаете расписание, по которому происходят сборки. Например, во многих компаниях хорошей практикой является создание ежедневных сборок.

При таком богатом наборе вариантов, вы можете создавать всевозможные виды сборок исходя из ваших потребностей.

Следующей важной вкладкой при настройке сборки является вкладка — Build Defaults. Здесь необходимо указать папку, в которую будет помещен результат после сборки.

Теперь вы можете сохранить параметры сборки и убедиться, что она стала доступна в панели Team Explorer. Давайте добавим новую сборку в очередь на выполнение.

Если вы дважды кликните по сборке в очередь, то увидите подробную информацию о выполнении.

Через некоторое время появится и результат.

В моем случае результат оказался не утешительным, но это сейчас не имеет значения. Надеюсь, что у вас будет все в порядке! Данный отчет предоставляет подробную информацию обо всех ошибках и предупреждениях, которые были найдены, так что из этого отчета сразу можно перейти к коду, который вызвал ошибку.

И так, мы рассмотрели инструменты, которые предлагает TFS для создания сборок. Теперь вы полностью готовы обеспечить минимальный жизненный цикл вашему продукту, используя TFS.

На этом я заканчиваю статью посвященную TFS и желаю вам побольше интересных проектов!
И самое главное – не забывайте получать удовольствие от программирования!

Архитектура

Чтобы лучше планировать и управлять развертыванием, надо сначала понять базовую архитектуру Team Foundation Server (TFS) (См. Рисунок 1). Понимание архитектуры может помочь сохранить общую работоспособность развертывания и обеспечить доступность необходимых серверов и сервисов.

TFS можно развернуть несколькими способами: на одном сервере; на нескольких серверах; или в одном домене или рабочей группе или между доменами. В качестве альтернативы можно использовать Visual Studio Online, где все серверные элементы развертывания размещены самим Microsoft. Понимание архитектуры позволяет решить, какая топология наиболее соответствует определенным бизнес-потребностям и лучше управлять физическими и логическими требованиями.

Чтобы понять архитектуру TFS и то, как она влияет на развертывание, следует учесть следующее:

Логические уровни приложений, данных и клиентов Team Foundation.

Расположение физических или виртуальных серверов, на которых размещены эти уровни.

Team Foundation Build, а также количество и расположение компьютеров сборки, которые будут работать в среде, включая количество, которое может понадобиться для поддержки методов разработки.

Потенциальная потребность в Team Foundation ServerProxy.

Visual Studio Online

Microsoft предлагает вариант использования Visual Studio Online (См. Рисунок 2), где размещены все серверные аспекты развертывания. В облаке размещаются исходный код, рабочие элементы, конфигурации сборки и командные функции. С точки зрения архитектуры это значительно упрощает развертывание, поскольку единственными аспектами архитектуры, которые необходимо учитывать, являются клиентские компоненты и их доступ в Интернет.

При использовании службы для подключения к ней с помощью учетной записи Microsoft используется веб-браузер. Можно создавать командные проекты, добавлять участников в коллектив и работать так же, как при локально установленном развертывании, без дополнительных затрат на администрирование серверов. Уровень приложений, уровень данных и серверы построения размещаются в облаке с помощью платформы Microsoft Cloud и SQL Server Azure.

Модель объекта

Используя размещенную или локально развернутую архитектуру (См. Рисунок 3), можно расширить функции и возможности Team Foundation, написав приложение, основанное на объектной модели его сервера или клиента. Во всех типах развертывания можно создавать приложения, расширяющие возможности клиента. Однако если требуется расширить возможности сервера, приложение должно выполняться на сервере уровня приложений. Чтобы расширить возможности клиента, необходимо запустить приложение на том же компьютере, что и Team Explorer.

Веб-сервисы и базы данных для локальных развертываний

Team Foundation Server включает в себя набор веб-служб и баз данных, которые устанавливаются и настраиваются отдельно на сервере или серверах, на которых размещаются логические уровни приложений, данных и клиентов для Team Foundation. Некоторые функции, такие как доска задач и бэклог, основанные на командах, полностью веб-доступны и доступны исключительно через Team Web Access, веб-сервис на стороне клиента. Другие, такие как функции контроля версий, могут быть доступны через Team Web Access или через клиентское приложение.

Collection-level services

Сервисы уровня коллекции предоставляют функциональные возможности для операций на уровне коллекции командных проектов. С помощью некоторых из этих сервисов можно создавать приложения, расширяющие Team Foundation Server:

Сервисы Team Foundation Framework

Сервис реестра
Сервис регистрации (для совместимости с более ранними версиями Team Foundation Server)
Сервис недвижимости
Сервис событий
Сервис безопасности
Сервис определения местоположения
Сервис управления идентификацией

Веб-сервис контроля версий

Веб-сервис отслеживания рабочих элементов

Team Foundation Build Web-сервис

Веб-сервис управления лабораторией

Веб-сервис администрирования VMM

Веб-сервис контроллера тестового агента

Server-level services

Службы уровня сервера (также известные как службы уровня приложения) предоставляют функциональные возможности для операций Team Foundation Server в качестве программного приложения. С помощью некоторых из этих служб можно создавать приложения, расширяющие Team Foundation Server: [Источник 3]

Сервисы Team Foundation Framework

Сервис реестра
Обслуживание событий
Сервис Team Project Collection
Сервис недвижимости
Сервис безопасности
Сервис определения местоположения
Сервис управления идентификацией
Сервис администрирования
Сервис управления коллекциями
Сервис каталогов

Уровень данных

Уровень данных включает в себя данные, хранимые процедуры и другую связанную логику. Когда вы используете Visual Studio Online, уровень данных размещается с помощью SQL Server Azure. При локальном развертывании TFS логический уровень данных состоит из следующих операционных хранилищ в SQL Server. Эти хранилища могут быть расположены на одном физическом сервере или распределены по многим серверам. С помощью некоторых из этих операционных хранилищ можно создавать приложения, расширяющие Team Foundation Server:

База данных конфигурации (TFS_Configuration)
Склад приложений (TFS_Warehouse)
База данных служб аналитики (TFS_Analysis)
Базы данных для коллекций командных проектов (TFS_CollectionName)

Уровень клиента

Уровень клиента связывается с уровнем приложения через объектную модель сервера и использует те же веб-службы, которые перечислены для этого уровня. Это верно при локальном развертывании TFS или при использовании Visual Studio Onlineю. Помимо этой модели, клиентский уровень состоит из компонентов Visual Studio Industry Partners (VSIP), интеграции Microsoft Office, интерфейсов командной строки и платформы для правил регистрации.

Информация о конфигурации

Размещенная служба зависит от клиентских служб, развернутых локально, и подключения к Интернету для приложений и уровней данных, размещенных в облаке. Локальное развертывание Team Foundation Server зависит от SQL Server, служб IIS и операционной системы Windows. В зависимости от выбранной топологии Team Foundation Server также может зависеть от служб SQL Server Reporting Services или продуктов SharePoint. Таким образом, сведения о конфигурации Team Foundation Server могут храниться в любом из следующих расположений:

Функции

В Team Foundation Server включены следующие основные функции:

Контроль версий для управления исходным кодом и другими результатами, требующими управления версиями.
Отслеживание рабочих элементов для отслеживания таких вещей, как дефекты, требования, задачи и сценарии.
Функции управления проектами, которые позволяют формировать командный проект на основе пользовательского программного процесса и позволяют планировать и отслеживать с помощью Microsoft Excel и Microsoft Project.
Team build для обеспечения общего процесса создания исполняемых продуктов.
Сбор данных и отчетность, которые помогают в оценке состояния командного проекта на основе информации, полученной из инструментов Team Foundation Server.
Team Project Portal, который обеспечивает центральную точку коммуникации для командного проекта, упакованного как сайт Microsoft Windows SharePoint Services.
Team Foundation Shared Services, которые предоставляют ряд общих инфраструктурных услуг, которые невидимы для конечных пользователей, но важны для мастеров и расширителей.

С другой стороны, Team Foundation Server - это платформа, специально созданная для интеграции и расширяемости. Клиенты и партнеры могут настраивать элементы Team Foundation Server и дополнять его новыми функциями. Расширения могут варьироваться от очень простых до самых сложных. Они могут варьироваться от переименования поля в рабочем элементе до интеграции совершенно нового инструмента.

Как не выйти в окно, когда нужно больше тестов

Нам нужна была сборка, которая запускает автотесты. Просто? Но идея была в том, чтобы объединить в нее несколько тестовых запусков по разным системам и отображать единый отчет о прохождении теста. Решение — сделать сборку с несколькими тестовыми запусками. Все было хорошо, пока мы не начали вылезать за пределы временного окна — тестовые запуски выполнялись последовательно один за другим. И не существовало решения "из коробки" для распараллеливания сборок. И пришла простая идея — мастер-сборка:

запускает отдельные сборки на других агентах (параллельно)
ожидает их завершения
забирает себе их тестовые результаты, если есть

Из реализации этой идеи и родилось расширение Parallel Builds

Для обеспечения параллелльности в расширении содержится 2 шага сборки:

Starter — запускает перечисленные определения сборок. Каждая сборка запускается со своими настройками. Это позволяет полностью изолировать разные сборки, использовать разные агенты и разные переменные окружения.
Awaiter — ожидает выполнения запущенных сборок и собирает их тестовые результаты. Кроме этого он добавляет на страницу Summary текущей сборки ссылки на "оригинальные" сборки. Это нужно в первую очередь для того, чтобы можно было просмотреть консольный вывод и логи этих сборок в случае возникновения проблем.

В простейшем случае мастер-сборка состоит всего из двух шагов:

расширение работает и в облачном VSTS и в частном TFS. Написано на typescript поэтому требует агента версии 2.0.

Работа с Visual Studio Team Foundation Server 2010

Предисловие

TFS представляет собой систему, которая интегрирует все необходимые компоненты вместе.

В зависимости от необходимости, вы можете использовать только часть компонентов.

Установка TFS 2010

TFS 2010 может быть установлен на контроллере домена. Разработчики TFS поняли, что многие небольшие организации не имеют возможность использовать выделенные серверы. Теперь если у вас есть только один сервер, который является контроллером домена, сервером электронной почты и т.п., появилась возможность установить на этот сервер и TFS 2010.
TFS 2010 может быть установлен на персональные операционные системы – TFS 2010 устанавливается на Vista и Windows 7 Home Premium и выше. Ну и конечно, поддерживаются серверные операционные системы (Windows 2003, Windows 2008 и Windows 2008 R2). Теперь у вас появилась возможность запустить сервер управления версиями прямо на вашем рабочем ноутбуке.
TFS 2010 может работать и на 32 и на 64 битной операционной системе!

Система контроля версий в TFS 2010

Предполагается, что у вас на компьютере уже установлен TFS 2010 и имеется Visual Studio 2010.

Система попросит указать адрес существующего TFS. В моем случае мой Windows 7 ноутбук называется dionnis-pc.

В следующем диалоговом окне необходимо указать название проекта и краткое его описание:

И так, наконец, Team Explorer отображает элементы текущего проекта: Work Items, Builds и Source Control.

Теперь вы можете добавить ваш проект в репозиторий.

Сейчас необходимо указать папку, в которой будет храниться наши данные.

Процесс добавления файлов в репозиторий необходимо подтвердить:

И так, поздравляю! Вы добавили свой проект в репозиторий!

Cистема отслеживания ошибок в TFS 2010

Поскольку мы только начали работу над проектом, то в списке не должно быть никаких записей.

Теперь если обновить список ошибок, то можно увидеть только что созданную запись.

Если все прошло гладко, то файл будет содержать отметку, о доступности для редактирования.

После редактирования, панель Pending Changes в Visual Studio сама покажет список файлов, которые претерпели изменения.

Поскольку мы исправляли ошибку, необходимо сделать запись об этом:

Еще один способ работать с TFS

Сборки в TFS 2010

Тут я хочу немного рассмотреть возможные параметры.

Manual – сборка задается вручную, по требованию.
Continuous Integration – сборка происходит сразу после check-in’а (после копирования файлов в репозиторий). Данный метод очень эффективен, если вы хотите делать сборки не дожидаясь объединения изменений.
Rolling builds – метод, при котором все изменения будут собираться пока выполняется предыдущая сборка. Данный метод рекомендуется использовать, если у вас очень большой проект и сборка занимает много времени (больше, чем скорость с которой вносятся изменения).
Gated Check-in – данный метод позволяет быть уверенным, что все изменения корректно компилируются, до того как файлы попадут в основной репозиторий.
Scheduled – метод, при котором вы задаете расписание, по которому происходят сборки. Например, во многих компаниях хорошей практикой является создание ежедневных сборок.

Если вы дважды кликните по сборке в очередь, то увидите подробную информацию о выполнении.

Через некоторое время появится и результат.

Содержание

Новое открытие TFS

Какая первая ассоциация возникает, когда слышишь словосочетание Microsoft TFS? Что-то большое, неповоротливое и корпоративное. Именно так и было до появления Visual Studio Team Services и выхода MS TFS 2015. Первый — это облачная версия Team Foundation Server, которая опережает в развитии частную (private) версию примерно на три месяца. Одним из главным нововведений обновленного TFS/VSTS стала новая система сборок. Эта система позволяет достаточно просто писать свои шаги сборок, которые могут делать что угодно — от собственно сборки проекта до автоматического заведения дефектов и рассылки нотификаций. Кроме этого новая версия предоставляет развитый REST API для манипулирования задачами, дефектами и практически любыми сущностями в базе данных TFS.

Именно поэтому когда перед нами встал выбор новой системы управления жизненным циклом разработки, мы остановились именно на этой новой версии MS TFS. Мы используем TFS для полного цикла — планирование-разработка-тестирование-развертывание, и, поначалу все шло достаточно гладко. С ростом сложности задач, которые мы ставили перед системой сборки, появлялись и проблемы. К счастью, REST API и собственные шаги сборки позволили их с успехом решить. Далее я расскажу о проблемах и о том, как мы их решили.

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 бесплатно, то он может быть инструментом не только для корпораций, но и для "стартапов".

Читайте также: