Team foundation server что это
что такое система управления версиями 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.
Работа с Visual Studio Team Foundation Server 2010
Данная статья будет полезна тем, кто не устанавливал и не использовал Visual Studio Team Foundation Server раньше. TFS может быть частью очень сложной инфраструктуры, которая включает отчеты, интеграцию с SharePoint, множественные домены, распределенные базы данных и т.д., но я не собираюсь затрагивать эти области. Моя основная задача – это помочь разобраться с базовыми элементами TFS (система контроля версий, система отслеживания ошибок и заданий и система автоматических сборок) и начать использовать данную систему.
Предисловие
Для начала давайте рассмотрим, почему именно Team Foundation Server? TFS создана с целью интегрировать средства разработки для более быстрой и комфортной работы. Вы можете сами интегрировать разные системы вместе:
В этом случае каждая система имеет собственно хранилище данных, собственный набор идентификационных данных, собственные команды и инструменты. Конечно, это возможно, но при работе с такой системой будет уходить много времени на переключение между компонентами и поддержку.
TFS представляет собой систему, которая интегрирует все необходимые компоненты вместе.
Такая интеграция охватывает наиболее общие сценарии. В обычный день я буду добавлять и править исходный код, делать сборки, тестировать их, заносить найденные ошибки в журнал и исправлять их. Когда весь рабочий процесс происходит в одной интегральной среде, то каждый из элементов процесса может быть связан. Например, если я копирую файлы в репозиторий, в которых я исправил ошибку, то я сразу хочу сделать отметку об этом в отчете. TFS, установленная в “Basic” конфигурации, позволяет делать все, что было описано выше. Полная версия TFS включает: автоматическое тестирование, развертывание виртуальной лаборатории и проверка архитектуры приложения:
В зависимости от необходимости, вы можете использовать только часть компонентов.
Существует множество способов для получения доступа к функционалу TFS. Если вы программист, то вероятно вы будете себя комфортно чувствовать, используя Visual Studio. Если вы тестировщик, вы можете использовать новый Team Explorer в качестве клиента, без необходимости устанавливать Visual Studio. Если вы руководитель проекта, то вы можете получить доступ к информации через web браузер или Excel, Microsoft Project или даже MOSS.
Установка TFS 2010
Забегая вперед, скажу, что этот процесс стал, как ни когда простым. Поэтому я решил не публиковать подробную инструкцию по установке (если же с установкой возникнут проблемы, рекомендую прочитать статью Установка Visual Studio Team Foundation Server 2010), а ограничиться лишь теоретическими знаниями.
Рассмотрим основные преимущества, которые предлагает новая версия TFS.
После установки 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. На этой вкладке вы можете задать события, на основе которых будут собираться сборки:
При таком богатом наборе вариантов, вы можете создавать всевозможные виды сборок исходя из ваших потребностей.
Следующей важной вкладкой при настройке сборки является вкладка — Build Defaults. Здесь необходимо указать папку, в которую будет помещен результат после сборки.
Теперь вы можете сохранить параметры сборки и убедиться, что она стала доступна в панели Team Explorer. Давайте добавим новую сборку в очередь на выполнение.
Если вы дважды кликните по сборке в очередь, то увидите подробную информацию о выполнении.
Через некоторое время появится и результат.
В моем случае результат оказался не утешительным, но это сейчас не имеет значения. Надеюсь, что у вас будет все в порядке! Данный отчет предоставляет подробную информацию обо всех ошибках и предупреждениях, которые были найдены, так что из этого отчета сразу можно перейти к коду, который вызвал ошибку.
И так, мы рассмотрели инструменты, которые предлагает TFS для создания сборок. Теперь вы полностью готовы обеспечить минимальный жизненный цикл вашему продукту, используя TFS.
На этом я заканчиваю статью посвященную 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 шага сборки:
В простейшем случае мастер-сборка состоит всего из двух шагов:
расширение работает и в облачном 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 бесплатно, то он может быть инструментом не только для корпораций, но и для «стартапов».
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Team Foundation Server
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]
Функции
В Team Foundation Server включены следующие основные функции:
Архитектура
Чтобы лучше планировать и управлять развертыванием, надо сначала понять базовую архитектуру 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 Build Web-сервис
Веб-сервис управления лабораторией
Веб-сервис администрирования VMM
Веб-сервис контроллера тестового агента
Server-level services
Службы уровня сервера (также известные как службы уровня приложения) предоставляют функциональные возможности для операций Team Foundation Server в качестве программного приложения. С помощью некоторых из этих служб можно создавать приложения, расширяющие Team Foundation Server: [Источник 3]
Сервисы Team Foundation Framework
Уровень данных
Уровень данных включает в себя данные, хранимые процедуры и другую связанную логику. Когда вы используете Visual Studio Online, уровень данных размещается с помощью SQL Server Azure. При локальном развертывании TFS логический уровень данных состоит из следующих операционных хранилищ в SQL Server. Эти хранилища могут быть расположены на одном физическом сервере или распределены по многим серверам. С помощью некоторых из этих операционных хранилищ можно создавать приложения, расширяющие Team Foundation Server:
Уровень клиента
Уровень клиента связывается с уровнем приложения через объектную модель сервера и использует те же веб-службы, которые перечислены для этого уровня. Это верно при локальном развертывании 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 могут храниться в любом из следующих расположений: