Tfs руководство пользователя

замечания

Установка или настройка

Подробные инструкции по настройке или установке tfs.

Что такое TFS и как данные хранятся в нем?

Team Foundation Server (обычно сокращенно TFS) является продуктом Microsoft, который обеспечивает управление исходным кодом (либо через Team Foundation Version Control, либо Git), отчетность, управление требованиями, управление проектами (как для гибкой разработки программного обеспечения, так и для команд водопада), автоматизированных сборок и управления лабораторией, тестирования и управления выпуском. Он охватывает весь жизненный цикл приложения. TFS может использоваться в качестве задней части для множества интегрированных сред разработки, но предназначен для Microsoft Visual Studio и Eclipse.

ПРЕИМУЩЕСТВА:

1. Team Foundation Server предоставляет набор инструментов совместной работы, которые работают с вашей существующей IDE или редактором, поэтому ваша команда может эффективно работать над проектами программного обеспечения всех форм и размеров.
2. Храните и сотрудничайте с кодом с неограниченными частными репозиториями. Используйте Git для управления распределенной версией, чтобы максимизировать сотрудничество или использовать контроль версий Team Foundation (TFVC) для централизованного контроля версий.
3. Поддержка методологии AGILE
4. Поддержка нескольких языков и IDE
5. Позволяет интегрировать сторонние плагины

ТИПЫ TFS:

1. онлайн
2. On-помещения

Интернет поддерживается облачной платформой Microsoft, Windows Azure и не требует какой-либо настройки. Пользователь регистрируется с использованием учетной записи Microsoft, чтобы начать настройку своей учетной записи, создание проектов и добавление членов команды. Новые функции, разработанные в трехнедельных циклах разработки, сначала добавляются в онлайн-версию. Эти функции переносятся на локальную версию в виде обновлений примерно через три месяца.

Team Foundation Server хранит все данные набора изменений в базе данных SQL Server. Он хранит код из самого последнего набора изменений целиком. Затем он сохраняет diff в предыдущей версии. Одним из преимуществ хранения всего этого в SQL Server является то, что он получает возможность сохранения «все или ничего», предоставляемую транзакциями. Архитектура TFS централизована. Это означает, что весь исходный код поддерживается в одном месте. В централизованной архитектуре сервер TFS сам по себе может считаться одной точкой отказа, но с решениями высокой доступности, доступными в операционной системе Windows Server, этого не должно быть. Аналогичным образом база данных SQL Server, хранящая фактические биты исходного кода, может быть зеркально отражена на нескольких серверах. Управление TFS было разработано для интеграции без проблем с последними версиями Microsoft Visual Studio. Однако это не означает, что вы не можете использовать контроль версий TFS с другими продуктами разработки программного обеспечения. Функциональность в TFS можно разделить на следующие области.  Базовая функциональность — проверка файлов входы и выходы  Блокировка — ограничение одновременных изменений  Ветвление и слияние — работа с разными версиями исходного кода  Безопасность — выбор того, кто может получить доступ к данным контроля версий и как

Базовая функциональность в любой системе управления версиями включает проверку и удаление файлов. Чтобы поддерживать параллелизм, TFS позволяет несколько проверок одного и того же файла, но при необходимости может быть отключена. Элементы также могут быть заблокированы исключительно, чтобы никто не мог проверять или удалять файл, пока он заблокирован. Если одновременные проверки отключены в настройках командного проекта, блокировка автоматически помещается в файл при проверке. Ветвление и слияние можно рассматривать как расширенные функции в TFS, но тем не менее они очень полезны. Основная идея ветвления состоит в том, чтобы взять набор файлов исходного кода и создать отличную версию из этих файлов. Разветвленный код может жить отдельно от исходных файлов. Например, если вы разрабатываете общее приложение, но вам нужно создать специализированную версию для определенного клиента, вы можете развернуть клиентские настройки из основного дерева управления версиями («trunk»). Если это необходимо позже, вы можете снова комбинировать код настройки с исходной линией управления версиями. Это называется слиянием. Все в TFS (кроме управления версиями прав пользователя Active Directory) хранятся в центральной базе данных SQL Server. Сюда входят настройки командного проекта, данные файла, детали набора изменений и т. Д. Поскольку почти все находится в центральном месте, обязательно убедитесь, что вы регулярно делаете резервные копии базы данных SQL и получаете план аварийного восстановления. Чтобы понять, как интегрирован элемент управления версиями в Microsoft Visual Studio, вам необходимо знать три отдельных окна (или панели в зависимости от вашей точки зрения): окна «Проводник управления версиями», «Обозреватель решений» и «Ожидающие изменения». Когда вы подключитесь к экземпляру Team Foundation Server, Solution Explorer позволит вам проверить и проверить файлы непосредственно из окна, щелкнув правой кнопкой мыши элементы. Однако по умолчанию проверка происходит просто при запуске редактирования файла в Visual Studio. Например, если вы откроете файл исходного кода C # в редакторе и начнете вводить текст, файл будет извлечен. Это часто самый удобный способ проверить файлы. Маленькие значки, отображаемые окном Solution Explorer, помогают различать заблокированные, извлеченные и добавленные файлы и т. Д. Значок синего замка указывает, что файл является частью контроля источника, но в настоящее время не проверен. Красная галочка указывает, что файл был извлечен, а знак «желтый плюс» указывает, что файл добавлен в проект. В TFS операция проверки и операция для получения последней версии отделены друг от друга. На практике это означает, что перед проверкой файла вы должны выполнить команду «Получить последний» в файле (файлах), который вы хотите проверить. Это можно сделать, просто щелкнув правой кнопкой мыши элемент в обозревателе решений и выбрав пункт «Получить последний». Чтобы изменить это поведение по умолчанию, вы можете выбрать команду меню инструментов / параметров Microsoft Visual Studio и перейти в раздел Source Control / Visual Studio Team Foundation Server. Здесь вы можете найти опцию «Получить последнюю версию элемента при регистрации». Окно управления версиями позволяет получить более целостное представление о дереве управления версиями. Ниже находится окно проводника управления источником (в настоящее время отключено).

Чтобы открыть окно, выберите команду меню View / Other Windows / Source Control Explorer или дважды щелкните узел Source Control в окне Team Explorer Visual Studio. Окно «Проводник управления версиями» позволяет просматривать и обрабатывать файлы в дереве управления версиями. В этом окне вы можете выполнять все те же операции, что и в обозревателе решений: например, вы можете проверять и удалять файлы, переименовывать их, удалять и т. Д. Разница заключается в том, что с помощью окна «Исходный элемент управления» файлы, с которыми вы работаете, не обязательно должны быть частью проекта разработки Visual Studio, например проекта C #. Например, вы можете добавить электронную таблицу Excel к управлению версиями; это то, что вы, возможно, не захотите сделать через Solution Explorer. Всякий раз, когда вы работаете с файлами под управлением версиями и редактируете их, добавляйте или удаляйте их, Visual Studio не будет немедленно передавать изменения обратно в элемент управления версиями. Вместо этого это делается только при проверке изменений. Тем временем все ваши изменения по умолчанию хранятся в ожидающем списке изменений, который можно увидеть через окно «Ожидающие изменения».

В окне «Ожидающие изменения» отображается список файлов, которые не были проверены. В окне также указывается запрос (добавление, изменение, удаление или переименование). Как правило, вы выполняете свои проверки через это окно, так как это позволяет вам удобно проверять несколько файлов за одну операцию. Вы также можете написать комментарий, который будет сопровождаться зарегистрированными файлами, и вы можете связать его с рабочим элементом Team Foundation Server с файлами. В целом, один или несколько исходных файлов, необязательные комментарии и ассоциации рабочих элементов вместе образуют набор изменений. Набор изменений в TFS всегда проверяется атомарно, что означает, что полный набор либо преуспевает, либо не выполняется при проверке. Набор изменений связан с уникальным идентификатором и может быть позже просмотрен, например, через окно проводника управления версиями. В управлении версиями TFS набор изменений является существенной концепцией, поскольку это самый маленький набор изменений, которые может обрабатывать система. Набор изменений может содержать один файл или набор файлов. Кроме того, это основа отчетности, особенно при использовании вместе с рабочими элементами.

SharePoint Integration

Windows SharePoint Services is an integral part of Team Foundation Server. As a result, there is v…

Creating Team Project

Team Foundation Server allows creation of the portal project via TFS Portal Creation Wizard. This …

SQL Server Agent Jobs

Team Foundation Server installs several SQL Server Agent Jobs that allow it to perform certain tas…

tf Command

tf Command line utility provide many useful operations that we can perform with Team Foundation Se…

Shelving and Unshelving

Shelving is very powerful feature of the Source Control in VSTS that allows storing pending change…

MS Project Fields Mapping

TFS works with MS Project via mapping file with specific fields mapped from one application to ano…

Managing Documents in TFS

Team Foundation Server provides us with the capability to manage various documents, also called ar…

В данной статье описано использование Team Foundation Server (TFS) и Microsoft Visual Studio Team System (VSTS) в условиях коллективной разработки программного обеспечения. Здесь представлены основные характеристики TFS и VSTS и взаимодействие групп разработки и тестирования при разработке программного обеспечения. TFS интегрирует в себе системы контроля версий, отслеживания процесса работы над проектом, создания и отображения отчетов, управления проектом и автоматизированный процесс сборки, и, следовательно, повышает эффективность работы группы разработки.

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

1. Разработка
2. Тестирование
3. Сборка
4. Развертывание
5. Выпуск продукта

Процесс разработки программного обеспечения с использованием Team Foundation Server

С помощью TFS группа разработки может хранить исходный код в централизованно управляемом хранилище. Тогда есть возможность создавать сборки с использованием сервера сборки и исходных файлов из этого хранилища и затем передавать их группе тестирования. На рис. 1.1 показан процесс коллективной разработки ПО с использованием TFS и взаимосвязь сред разработки и тестирования.

Рис. 1.1 Процесс коллективной разработки ПО с использованием Team Foundation Server.

Группа тестирования берет версии сборок приложений из места публикации результатов сборки и выполняет их в своей среде тестирования, сочетая ручное и автоматизированное тестирование. TFS сохраняет результаты тестирования и использует их для обеспечения обратной связи по качеству сборки. Группа тестирования также может создавать рабочие элементы или дефекты (особый тип рабочих элементов), по которым группа разработки должна предпринять некоторые действия. Эти рабочие элементы позволяют группе тестирования отслеживать работу группы разработки.

Работа в среде разработки, тестирования и выпуска продукта

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

Рис. 1.2 Взаимодействие двух групп разработки и группы тестирования.

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

Процессы разработки

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

1. Осуществляете доступ к дефектам и задачам, находящимся в TFS, и таким образом выясняете, что необходимо сделать. Например, рабочие элементы могут быть назначены руководителем проекта, другим разработчиком или группой тестирования.
2. Используете VSTS Source Control Explorer для доступа к хранилищу исходного кода в TFS и загрузки последней версии исходного кода в локальное рабочее пространство или свой рабочий компьютер.
3. Выполнив задачи, оговоренные рабочим элементом, возвращаете свой код в хранилище исходного кода.
4. Check-in-событие (событие регистрации изменений) может запустить процесс непрерывной интеграции, который использует Team Build.
5. Если сборку создать не удалось, создается новый рабочий элемент для отслеживания неудачного создания сборки.

Процессы тестирования

Член группы тестирования взаимодействует с TFS следующим образом:

1. Загружает плановую сборку из места публикации результатов сборки.
2. С помощью различных инструментов VSTS выполняет ручное и автоматизированное тестирование, включая тестирование безопасности, производительности и Web-тестирование.
3. Загружает результаты тестирования в базу данных TFS Test Result для дальнейшего использования.
4. Регистрирует в TFS дефекты, выявленные при тестировании, как рабочие элементы.
5. Объявляет открытые дефекты исправленными после тестирования последней версии сборки.

Физические среды разработки и тестирования

Размер сред разработки и тестирования и количество компьютеров в них могут быть различными в зависимости от размера группы и проекта. На рис. 1.3 показана типичная физическая среда разработки и тестирования.

Рис. 1.3 Физическая среда разработки и тестирования

Среда разработки

Среда разработки обеспечивает процессы разработки и сборки продукта. Среда разработки включает следующие компьютеры:

1. Team Foundation Server
2. Сервер сборки
3. Сервер для хранения результатов сборки
4. Рабочие станции разработчиков

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

Среда тестирования

Среда тестирования состоит из одной или более тестовых рабочих станций, на которых установлена Visual Studio Team Edition for Software Testers. Они используются для управления процессом тестирования и проведения функционального тестирования, системного тестирования, тестирования безопасности, производительности и Веб-тестирования. Члены группы используют TFS для управления, дефектами и другими рабочими элементами, а также результатами тестирования.
Среда тестирования также может включать Visual Studio Team Test Load для нагрузочного тестирования.

Заключение

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

Время на прочтение
7 мин

Количество просмотров 96K

Данная статья будет полезна тем, кто не устанавливал и не использовал 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.

1. Требования — были устранены наиболее важные ограничения, которые исторически передавались от версии к версии.

• 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 битной операционной системе!

2. Установка. Установка TFS была самым больным местом в течение многих лет. Теперь этот недостаток превратился в достоинство. Установщик TFS 2010 имеет три режима установки: Basic, Standard и Advanced. Особенно большой прорыв сделан в режиме “Basic”. По сути, данный режим превратился в установку по принципу Далее -> Далее -> Далее, что позволяет установить и настроить TFS 2010 за 20 минут или даже меньше (при условии, что на компьютере уже стоит .NET 4.0 и MSSQL Express). Режим “Basic” позволяет автоматически установить и настроить IIS (если он еще не установлен), MSSQL Server (если он еще не установлен) и установить и настроить непосредственно TFS 2010. Сама большая неприятность в этом процессе – это то, что после установки .NET 4.0 необходимо перезагрузить компьютер. Но поверьте мне, результат того стоит!

После установки 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 и желаю вам побольше интересных проектов!
И самое главное – не забывайте получать удовольствие от программирования!

Если Вам понравилась статья, проголосуйте за нее тут

Installation or Setup

Detailed instructions on getting tfs set up or installed.

What is TFS and how Data is stored in it?

Team Foundation Server (commonly abbreviated to TFS) is a Microsoft product that provides source code management (either via Team Foundation Version Control or Git), reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds and lab management, testing and release management capabilities. It covers the entire application lifecycle. TFS can be used as a back end to numerous integrated development environments but is tailored for Microsoft Visual Studio and Eclipse.

ADVANTAGES:

1. Team Foundation Server provides a set of collaboration tools that work with your existing IDE or editor, so your team can work effectively on software projects of all shapes and sizes.
2. Store and collaborate on code with unlimited private repositories. Use Git for distributed version control to maximize collaboration or use Team Foundation version control (TFVC) for centralized version control.
3. Support for AGILE methodology
4. Support for multiple languages and IDE
5. Allows third party plugin integration

TYPES of TFS:

1. Online
2. On-premises

Online is backed by Microsoft’s cloud platform, Windows Azure and it does not require any setup. A user logs in using a Microsoft Account to begin setting up their account, creating projects and adding team members. New features developed in three-week development cycles are added to the online version first. These features migrate to the on-premises version as updates, at approximately three-month intervals.

Team Foundation Server stores all the changeset data in a SQL Server Database. It stores the code from the most recent changeset in its entirety. It then stores a diff to the previous version. One of the benefits of storing it all in SQL Server is that it gains the «all or none» saving capability that is provided by transactions.
The architecture of TFS is centralized. This means all source code is maintained at a single location. In a centralized architecture the TFS server itself can be considered a single point of failure, but with high-availability solutions available in the Windows Server operating system, this does not need to be so. Similarly, the SQL Server database storing the actual source code bits can be mirrored on multiple servers.
TFS control has been designed to integrate seamlessly with the latest versions of Microsoft Visual Studio. However, this does not mean that you could not use TFS version control with other software development products.
The functionality in TFS can be divided into the following areas.
 Basic functionality — checking files in and out
 Locking — limiting concurrent edits
 Branching and merging — work with different versions of the source code
 Security — decide who can access the version control data and how

The basic functionality in any version control system includes checking file in and out. To support concurrency, TFS allows multiple checkouts of the same file, but this can be disabled should the need arise. Items can also be exclusively locked so that nobody else can check in or out a file while it is locked. If concurrent checkouts are disabled in team project settings, then a lock is automatically placed on the file upon checkout.
Branching and merging can be considered advanced functions in TFS, but nonetheless, they are highly useful. The main idea of branching is to take a set of source code files and create a distinct version from those files. The branched code can live a life of its own separate from the original source files. For instance, if you are developing a generic application but need to make a specialized version for a certain customer, you could branch the customer customizations from the main source control tree (the «trunk»). Should the need arise later, you can again combine the customization code with the original source control line. This is called merging.
Everything in TFS (except Active Directory user rights version control) are stored in a central SQL Server database. This includes team project settings, file data, changeset details, and so on. Because almost everything is in a central location, it is imperative to make sure you take regular backups of the SQL database(s) and have a disaster recovery plan.
To understand how version control is integrated into Microsoft Visual Studio, you need to be aware of three separate windows (or panes, depending on your point of view): the Source Control Explorer, Solution Explorer and Pending Changes windows.
When you have connected to a Team Foundation Server instance, Solution Explorer will allow you to check out and check in files directly from the window by right-clicking the items. However, by default a check out occurs simply when you start editing a file in Visual Studio. For instance, if you open a C# source code file in the editor and start typing, the file is checked out. This is often the most convenient way to check out files.
Small icons shown by the Solution Explorer window help you distinguish between locked, checked out and added files, and so forth. A blue lock icon indicates that a file is part of source control but is not currently checked out. A red check mark indicates that the file has been checked out, and a yellow plus sign indicates that a file has been added to the project. In TFS, a check out operation and the operation to get the latest version are separate from each other. In practice, this means that before checking out a file, you should execute a «Get Latest» command on the file(s) you wish to check out. This can be done by simply right-clicking an item in Solution Explorer, and choosing the Get Latest menu item. To change this default behavior, you can choose Microsoft Visual Studio’s Tools/Options menu command, and navigate to the section Source Control/Visual Studio Team Foundation Server. From here, you can find an option named «Get latest version of item on check out».
The source control window allows you to get a more holistic view of your version control tree.
Below is the source control explorer window (currently disconnected).

To open the window, choose the View/Other Windows/Source Control Explorer menu command, or double-click the Source Control node in Visual Studio’s Team Explorer window. The Source Control Explorer window allows you to view and manipulate files in your version control tree. You can do all the same operations through this window than you could do in Solution Explorer: for instance, you can check in and out files, rename them, delete them, and so on. The difference is that using the Source Control Explorer window, the files you work with do not need to be part of a Visual Studio development project, such as a C# project. For example, you could add an Excel spreadsheet to version control; this is something that you might not want to do through Solution Explorer.
Whenever you work with files under version control and edit, add or delete them, Visual Studio will not immediately commit the changes back to version control. Instead, this is done only when you check the changes in. In the meantime, all your changes are by default stored in a pending changes list, which can be seen through the Pending Changes window.

The Pending Changes window shows a list of files that have not been checked in. The window also indicates the operation (add, edit, delete or rename) requested. Usually, you do your check-ins through this window, since it allows you to conveniently check in multiple files in a single operation. You can also write a comment to accompany the checked in files, and you can link to a Team Foundation Server work item with the files.
Overall, one or more source files, optional comments and work item associations collectively form a changeset. A changeset in TFS is always checked in atomically, which means that the complete set either succeeds or fails in the check in. A changeset is associated with a unique ID, and can be later viewed for example through the Source Control Explorer window. In TFS version control, a changeset is an essential concept because it is the smallest set of changes that the system can process. A changeset can contain a single file, or a set of files. Furthermore, it is the basis of reporting, especially when used together with work items.