какую особенность обеспечивает веб интерфейс team foundation server

Как мы заново открыли 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 шага сборки:

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

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

Источник

что такое система управления версиями Team Foundation

Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | VS 2017 | VS 2015 | VS 2013

Независимо от того, является ли проект вашего программного обеспечения большим или малым, рекомендуется как можно скорее использовать контроль версий. Системы управления версиями — это программное обеспечение, помогающее отслеживанию изменений, внесенных в код с течением времени. При редактировании кода система контроля версий сообщает системе управления версиями о необходимости создать моментальный снимок файлов. Этот снимок навсегда сохраняется в системе, благодаря чему вы можете повторно вызвать его в любое время.

Azure DevOps Services и TFS предоставляют две модели управления версиями: Git, который является распределенным управлением версиями, и система управления версиями Team Foundation (TFVC), который является централизованным контролем версий. в этой статье приводятся общие сведения и начальная точка для использования система управления версиями Team Foundation. если вы решаете, какой тип Azure DevOps Services/тфс систему управления версиями, см. раздел выбор подходящего контроля версий для проекта.

Зачем использовать систему управления версиями?

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

Системы управления версиями предоставляют следующие преимущества.

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

Team Foundation (подсистема контроля версий)

Подсистема контроля версий Team Foundation (TFVC) — это централизованная система управления версиями. Как правило, члены команды имеют на своих компьютерах разработки только одну версию каждого файла. Исторические данные ведутся только на сервере. Ветви основаны на путях и создаются на сервере.

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

Краткие руководства

Начните с создания проекта, настройки рабочей области и просмотра и совместного использования кода. Можно использовать любой из этих клиентов или IDE:

Пошаговые инструкции

изучите основы работы в TFVC с помощью следующего руководства, в котором показан день жизни разработчика devops с использованием Visual Studio и TFVC.

Выберите действие

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

Серверные рабочие области — перед внесением изменений члены группы выверяют файлы в общедоступном виде. Большинство операций требуют подключения разработчиков к серверу. Эта система упрощает блокировку рабочих процессов. Другие системы, работающие таким образом, включают Visual Source Safe, Perforce и CVS. С помощью серверных рабочих областей можно масштабировать до очень больших баз кода с миллионами файлов на каждую ветвь и большие двоичные файлы.

Локальные рабочие области — каждый член команды берет на себя копию последней версии базы кода и работает в автономном режиме по мере необходимости. Разработчики возвращают свои изменения и при необходимости разрешают конфликты. Еще одна система, которая работает таким образом, — это Subversion.

В большинстве случаев вам не придется думать об управлении версиями. Система понимает вносимые вами изменения и помогает управлять ими.

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

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

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

Одно из преимуществ системы управления версиями состоит в том, что она позволяет заглянуть в прошлое и получить подробные сведения об изменениях, внесенных в файлы.

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

Большим преимуществом использования управления версиями является то, что над одним файлом могут одновременно работать несколько пользователей. Один из недостатков, однако, состоит в том, что иногда приходится разрешать конфликты. Хотя сталкиваться с конфликтами достаточно неприятно, система предоставляет сведения и средства, помогающие понять и разрешить конфликты.

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

Связанные разделы

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

Сведения о соглашениях об именовании, синтаксисе и ограничениях именования.

В настоящее время мы не повторяем публикацию следующих разделов. Однако вы можете прочитать версию этого руководства для Visual Studio 2010.

Источник

Настройка Team Foundation Server для веб-развертывания

В этом учебнике показано, как настроить Team Foundation Server (TFS) 2010 для создания решений и развертывания веб-содержимого в различных целевых средах. Сюда входят сценарии непрерывной интеграции (CI), в которых содержимое развертывается автоматически каждый раз, когда разработчик вносит изменения. Он также может включать сценарии триггера вручную, где администратор может активировать развертывание определенной сборки в промежуточной среде после проверки и проверки сборки в тестовой среде. Подразделы этого руководства помогут выполнить весь процесс настройки, в том числе:

Для итальянского перевода этих руководств посетите http://www.lucamorelli.it.

В этом руководстве предполагается, что вы установили TFS 2010 и создали коллекцию командных проектов в процессе начальной настройки. Руководство по установке Team Foundation для Visual Studio 2010 предоставляет исчерпывающие рекомендации по этим задачам.

Контекст

Эта форма является частью серии руководств, основанных на требованиях Enterprise к развертыванию вымышленной компании Fabrikam, Inc. В этой серии руководств используется пример решения— диспетчера контактов —для представления веб-приложения с реалистичным уровнем сложности, включая приложение ASP.NET MVC 3, службу Windows Communication Foundation (WCF) и проект базы данных.

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

Общие сведения о сценарии

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

Как использовать этот учебник

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

Ключевые технологии

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

Учебник также касается использования Windows Server 2008 R2, IIS 7,5, SQL Server 2008 R2, ASP.NET 4,0 и ASP.NET MVC 3.

Другие учебники в этой серии

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

Источник

Архитектура и функциональные возможности Visual Studio Team Foundation Server

Получить представление об архитектуре и функциональных возможностях TeamFoundationServer 2012

Введение

MicrosoftVisualStudio TeamFoundationServer(TFS) предназначен для обеспечения совместной работы команд разработчиков программного обеспечения. TeamFoundationServer предоставляет следующие функциональные возможности [29]:

Клиентский уровень может реализовываться в оболочке VisualStudioи веб-браузере. Клиентский уровень взаимодействует с уровнем приложений через серверную объектную модель и использует веб-службы. Кроме того, клиентский уровень включает интеграцию с Microsoft Office.

Развертывание Team Foundation Server

Для Team Foundation Server можно выполнить развертывание несколькими способами: на одном сервере; на нескольких серверах; в одном домене, рабочей группе или в нескольких доменах [31].

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

Шаблоны командных проектов

Командный проект представляет коллекцию рабочих элементов, кода, тестов и построений, которые охватывают все артефакты, используемые в жизненном цикле программного проекта [32]. Командный проект строится на основе шаблона, который представляет набор XML-файлов, содержащих детали того, как должен осуществляться процесс. В TFS 2012 имеются следующие шаблоны проектов:

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

Рабочими элементами в TeamFoundationServer являются: пользовательское описание функциональности, задачи, тестовые случаи, ошибки и препятствия. Этими элементами нужно управлять для выполнения программного проекта. Система отслеживания рабочих элементов позволяет создавать рабочие элементы, отслеживать их состояние, формировать историю их изменения. Все данные по рабочим элементам сохраняются в базе данных TFS.

TeamFoundationServer включает централизованную систему контроля версий. Система контроля версий TFS предоставляет следующие возможности:

Разработчик имеет возможность взаимодействовать с ключевыми службами TeamFoundationServer посредством:

Ключевые термины

Краткие итоги

Источник

Team Foundation Server

Содержание

Архитектура [ ]

3-уровневая архитектура Team Foundation Server

Любой Team Foundation Server содержит один или более Совместный проект (Team Projects), состоящий из решений на базе Visual Studio, конфигурационных файлов для Team Build и Team Load Test Agents, и единый репозиторий на базе SharePoint, содержащий связанную с проектом документацию. Совместный проект включает в себя пользовательские рабочие элементы, версии (ветки) исходного кода, отчёты, управляемые TFS. TFS обеспечивает возможности для управления этими проектами. При создании нового проекта нужно выбирать фреймворк программной разработки, который впоследствии сменить нельзя. TFS включает в себя несколько наиболее распространённых шаблонов, среди которых присутствуют как методики гибкой разработки, так и формальные. Выбор фреймворка наполняет проект заранее предопределенными элементами, как например, роли и полномочия, а также прочую документацию, например, стратегию развития проекта (project roadmap), шаблоны документов, заготовки отчётов. Эти элементы могут быть связаны с рабочими элементами. Статус определенных элементов проекта может автоматически обновляться при изменении рабочих элементов. TFS можно интегрировать с Microsoft Excel для создания и отслеживания элементов проекта. Статус элементов в этом случае можно указывать и редактировать непосредственно в Excel, а итоговые таблицы могут обрабатываться TFS, который будет импортировать данные с учётом особенностей управления данным проектом. Кроме того, его также можно интегрировать с Microsoft Project (например, Microsoft Project 2003, но не Project Server!) в качестве клиентской части управления проектом. Элементы проекта можно экспортировать как документы Excel для дальнейшего анализа данных.

Контроль исходного кода (Source control) [ ]

TFVC поддерживает ветвление на всех уровнях исходного кода, а также для отдельных файлов и каталогов, причём каждая ветвь поддерживается отдельно. Несколько ветвей можно объединить в одну с указанием порядка (алгоритма) разрешения конфликтов при слиянии изменений двух ветвей одного файла, тогда программа сама автоматически согласует различия или отметит их для ручной проверки, если сама с ними не справится. Слияние может быть выполнено и на уровне набора изменений («changeset»), вместо уровня ветвления. Успешное слияние автоматически отмечается (check out) в репозитории контроля кода.

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

Отчётность (Reporting) [ ]

Портал проекта (Project portal) [ ]

Исходя из проектной основы, TFS также создает SharePoint-сайт для проекта, который может использоваться для отслеживания прогресса проекта, наблюдения за рабочими элементами и документами, представленными в библиотеке проекта. На сайте также можно просматривать созданные отчёты. TFS можно применять в качестве центра связи, то есть пользователи, связанные с определенным проектом, могут использовать сайт для общения или взаимодействия друг с другом. Комментарии могут связываться с различными элементами. Для каждого проекта, в зависимости от его свойств, TFS использует заранее предопределенные шаблоны, указываемые при создании сайта. Такие шаблоны могут настраивать (редактировать) администраторы TFS.

Shared services [ ]

Team build [ ]

Team Build — сервер сборки, входящий в состав Team Foundation Server, и который может быть установлен практически на любой машине, поддерживающей Visual Studio. Машины, сконфигурированные под Team Build, могут использоваться разработчиками для выполнения полной сборки большинства последних версий программного обеспечения, используемых в контроле кода. Записи каждой сборки сохраняются вне зависимости от её успешности или неуспешности, так что разработчики и администраторы сборок могут отслеживать прогресс проекта. Если сборка происходит последовательно, то анализируются изменения, сделанные в исходном коде после последней успешной сборки, а обновление рабочих элементов указывает на определенный прогресс. Например, если тестировщик заводит рабочий элемент, посвящённый конкретной ошибке в сборке #15, а разработчик вносит изменения чуть ранее, чем была создана сборка #18, то элемент «ошибка» обновится до статуса, указывающего, что ошибка исправлена. Тестировщик может как подтвердить, так и опровергнуть то, что ошибка была успешно исправлена.

На данный момент существуют две версии TeamBuild, причём каждая версия соответствует устанавливаемой версии TFS. Впрочем, они вполне легко настраиваются.

Ссылки [ ]

См. также [ ]

Дополнительные источники [ ]

Шаблон:Нет источников Шаблон:Программное обеспечение для управления проектами

Источник