В данной статье описано использование 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 следующим образом:
Почему nft столько стоят #shorts
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 для выполнения тестов, загрузки результатов тестирования и регистрирования дефектов.
Источник: www.cyberguru.ru
Что такое система управления версиями Team Foundation?
Независимо от того, является ли проект вашего программного обеспечения большим или малым, рекомендуется как можно скорее использовать контроль версий. Системы управления версиями состоят из программного обеспечения, которое помогает отслеживать изменения, внесенные в код с течением времени. При редактировании кода вы указываете системе управления версиями создать моментальный снимок файлов. Этот снимок навсегда сохраняется в системе, благодаря чему вы можете повторно вызвать его в любое время.
Azure DevOps Services и TFS предоставляют две модели управления версиями: Git , который является распределенным управлением версиями, и система управления версиями Team Foundation (TFVC), который является централизованным управлением версиями. В этой статье представлен обзор и отправная точка для использования TFVC. Если вы решаете, какой тип управления версиями Azure DevOps Services/TFS использовать, см. раздел Выбор правильного управления версиями для проекта.
Зачем использовать управление версиями?
Без управления версиями вам придется хранить множество копий кода на компьютере. Это опасно, так как легко изменить или удалить файл в неправильной копии кода, что может привести к потере работы. Система управления версиями решает эту проблему, обеспечивая управление всеми версиями кода, но представляя вам одну версию за раз.
Системы управления версиями предоставляют следующие преимущества:
- Создание рабочих процессов . Рабочие процессы управления версиями предотвращают хаос, когда все пользователи используют собственный процесс разработки с различными и несовместимыми инструментами. Системы управления версиями обеспечивают принудительное применение процессов и разрешения, чтобы все пользователи оставались на одной странице.
- Работа с версиями . Каждая версия содержит описание изменений в версии, например исправление ошибки или добавление функции. Такие описания помогают отслеживать изменения в коде по версии, а не по изменениям в отдельных файлах. Код, хранящийся в версиях, можно в любой момент при необходимости просмотреть и восстановить из системы управления версиями. Это упрощает создание новой работы на основе любой версии кода.
- Код вместе . Система управления версиями синхронизирует версии и гарантирует, что изменения не конфликтуют с другими изменениями из вашей команды. Ваша команда использует управление версиями, чтобы устранить и предотвратить конфликты, даже если люди вносят изменения одновременно.
- Ведение журнала . Управление версиями хранит журнал изменений, когда команда сохраняет новые версии кода. Этот журнал позволяет узнать, кто, зачем и когда внес изменения. Журнал дает уверенность в эксперименте, так как вы можете в любое время откатить предыдущую хорошую версию. Журнал позволяет выполнять базовые действия из любой версии кода, например для исправления ошибки в предыдущем выпуске.
- Автоматизация задач . Функции автоматизации управления версиями экономят время команды и создают согласованные результаты. Вы можете автоматизировать тестирование, анализ кода и развертывание при сохранении новых версий в управлении версиями.
Есть много вещей, которые могут занять ваше время в качестве разработчика: воспроизведение ошибок, изучение новых инструментов и добавление новых функций или содержимого. По мере увеличения масштаба пользователей система управления версиями помогает вашей команде работать вместе и отправляться вовремя.
Team Foundation (подсистема контроля версий)
TFVC — это централизованная система управления версиями. Как правило, участники группы имеют только одну версию каждого файла на своих компьютерах разработки. Исторические данные ведутся только на сервере. Ветви основаны на путях и создаются на сервере.
TFVC позволяет применять детализированные разрешения и ограничивать доступ до уровня файла. Так как ваша команда проверяет всю свою работу в Azure DevOps Server, вы можете легко выполнить аудит изменений и определить, какой пользователь вернулся в набор изменений. С помощью функции сравнения и добавления заметок можно определить точные изменения, которые они внесли.
Краткие руководства
Начните с создания проекта, настройки рабочей области, а также просмотра кода и предоставления общего доступа к коду. Вы можете использовать любой из следующих клиентов или URI:
Пошаговые инструкции
Основные сведения о работе в TFVC см. в следующем руководстве, в котором показан день в жизни разработчика DevOps с помощью Visual Studio и TFVC.
- День в жизни разработчика DevOps: приостановка работы, исправление ошибки и проверка кода
- Visual Studio: проверка кода
Выбор действия
- Настройка компьютера для разработки и начало работы Потратьте несколько минут на настройку компьютера разработки, чтобы воспользоваться всеми преимуществами базы кода с управлением версиями.
- Выбор модели рабочего процесса — серверных или локальных рабочих областей
- Серверные рабочие области Перед внесением изменений члены команды открыто извлекают файлы. Большинство операций требуют подключения разработчиков к серверу. Эта система упрощает рабочие процессы блокировки. Другие системы, работающие таким образом, включают Visual Source Safe, Perforce и CVS. С помощью серверных рабочих областей можно масштабировать до очень больших баз кода с миллионами файлов на ветвь и большими двоичными файлами.
- Локальные рабочие области . Каждый участник команды получает с собой копию последней версии базы кода и по мере необходимости работает в автономном режиме. Разработчики возвращают свои изменения и при необходимости разрешают конфликты. Еще одна система, которая работает таким образом, — это Subversion.
Операции доступны только из командной строки tf
В следующей таблице перечислены задачи для TFVC, которые можно выполнять только в командной строке с помощью программы командной tf строки.
| Удалите рабочую область другого пользователя. | workspace с параметром /delete |
| Отмените извлечение другого пользователя. | undo |
| Удалите блокировку другого пользователя. | lock |
| Определение области метки. | label |
| Выполните безбазовое слияние. | merge |
| Окончательное уничтожение содержимого. | destroy |
| Откат эффекта одного или нескольких наборов изменений. | rollback |
Похожие статьи
- Что такое управление версиями?
- Настройка параметров извлечения
- Переход с TFVC на Git
- Сборка и тестирование приложения в системе автоматизированной сборки
- Ограничения именования в Team Foundation
- Использование команд Team Foundation (подсистема контроля версий)
- Разрешения TFVC по умолчанию
Источник: learn.microsoft.com
Непрерывное развертывание проектов в Windows Azure с помощью Team Foundation Service
Microsoft Team Foundation Service –– это облачная версия популярного приложения Microsoft Team Foundation Server (TFS), которое содержит удобные инструменты для создания исходного кода, сборки, гибкой разработки, рабочих процессов в команде, отслеживания задач и ошибок, а также других действий. Командные проекты Team Foundation Service можно автоматически собирать и развертывать на веб-сайтах или облачных службах Windows Azure. Информацию о том, как настроить непрерывную сборку и развертывание системы из локальной версии Team Foundation Server, см. в разделе «Непрерывное развертывание облачных приложений в Windows Azure».
Далее предполагается, что на вашем компьютере установлена среда Visual Studio 2012 и Windows Azure SDK. Если среда Visual Studio 2012 не установлена, загрузите ее отсюда. Можно также использовать Visual Studio 2010, но тогда необходимо установить пакет SP1 и пакет совместимости GDR. Пакет Windows Azure SDK доступен по этой ссылке.
- Этап 1. Подпишитесь на сервис TFS Preview
- Этап 2. Синхронизируйте проект с TFS
- Этап 3. Подключите проект к Windows Azure
- Этап 4. Внесите изменения и запустите повторную сборку и развертывание
- Этап 5. Повторно разверните предыдущую сборку (необязательно)
- Этап 6. Измените рабочее развертывание (только для облачных служб)
Этап 1. Подпишитесь на сервис TFS Preview
Создайте учетную запись TFS на сайте https://tfspreview.com.
Создайте командный проект на странице учетной записи TFS. Учетная запись имеет следующий формат: .tfspreview.com. Выполнять вход нужно с помощью учетной записи Microsoft Live ID.
Выберите Create a Team Project. Введите имя и описание проекта, а затем нажмите кнопку Create Project.
Когда проект будет создан, нажмите кнопку Navigate to Project.
Этап 2. Синхронизируйте проект в TFS
Щелкните ссылку Open new instance in Visual Studio, чтобы автоматически запустить среду Visual Studio, подключенную к командному проекту. Если отобразятся предупреждения безопасности, выберите Allow. Для выполнения этого этапа требуется Visual Studio 2012.
В Visual Studio откройте или создайте решение, которое необходимо развернуть. С помощью инструкций данного руководства можно развернуть веб-сайт или облачную службу (приложение Windows Azure). Чтобы создать решение, создайте проект облачной службы Windows Azure или проект ASP.NET MVC4. Убедитесь, что в проекте используется .NET Framework 4, а затем добавьте веб-роль и рабочую роль ASP.NET MVC 4. По запросу системы выберите Internet Application. Чтобы создать веб-сайт, выберите шаблон проекта ASP.NET MVC4 Application.
Откройте контекстное меню решения и выберите Add Solution to Source Control.
Примите или измените значения по умолчанию, а затем нажмите кнопку OK. После завершения процесса в Solution Explorer появятся значки контроля исходного кода.
Откройте контекстное меню решения и выберите Check In.
В разделе Pending Changes обозревателя команд введите комментарий и нажмите кнопку Check In.
При синхронизации проверьте включенные и исключенные параметры. Если нужные параметры исключены, щелкните ссылку Include All.
Этап 3. Подключите проект к Windows Azure
Теперь командный проект TFS с файлами исходного кода можно подключить к Windows Azure. На портале Windows Azure Preview выберите облачную службу или веб-сайт либо создайте их. Для этого щелкните значок «+» в левой нижней части и выберите Cloud Service или Web Site, а затем Quick Create. Щелкните ссылку Set up TFS publishing.
В открывшемся мастере введите имя учетной записи TFS в текстовом поле и щелкните ссылку Authorize Now. Система может попросить вас выполнить вход.
Во всплывающем диалоговом окне OAuth нажмите Accept, чтобы разрешить Windows Azure настройку командного проекта в TFS.
Затем появится раскрывающийся список, содержащий имена ваших командных проектов TFS. Выберите проект, созданный на предыдущих этапах, и нажмите кнопку с флажком в окне мастера.
После подключения проекта система отобразит несколько инструкций по синхронизации изменений в командном проекте TFS. При следующей синхронизации TFS соберет и развернет проект в Windows Azure. Для проверки этой функции щелкните ссылку Check In from Visual Studio 2012, а затем Launch Visual Studio 2012 (или аналогичную кнопку на панели команд Visual Studio).
Этап 4. Внесите изменения и запустите повторную сборку и развертывание
В обозревателе команд Visual Studio щелкните ссылку Source Control Explorer.
Перейдите к файлу решения и откройте его.
Откройте и измените файл в Solution Explorer. Например, отредактируйте файл _Layout.cshtml в папке ViewsShared веб-роли MVC4.
Измените логотип сайта и нажмите Ctrl + S для сохранения.
В обозревателе команд щелкните ссылку Pending Changes.
Введите комментарий и нажмите кнопку Check In.
Чтобы вернуться на домашнюю страницу обозревателя команд, нажмите кнопку Home.
Щелкните ссылку Builds для просмотра хода выполнения сборки.
Обозреватель команд показывает, что для вашей синхронизации запущен процесс сборки.
Дважды щелкните имя выполняемой сборки для просмотра подробной информации.
В ходе процесса вы можете просмотреть определение сборки, которое было создано при связывании TFS с Windows Azure с помощью мастера. Откройте контекстное меню определения построения и выберите Edit Build Definition.
На вкладке Trigger показано, что определение сборки по умолчанию используется для всех синхронизаций.
На вкладке Process показано, что среда развертывания связана с именем вашей облачной службы или веб-сайта.
К этому моменту сборка должна завершиться.
Если дважды щелкнуть имя сборки, среда Visual Studio отобразит Build Summary, включая все результаты тестирования из соответствующих проектов модульного тестирования.
На портале Windows Azure Preview можно просмотреть связанное развертывание на вкладке Deployments, выбрав тестовую среду.
Выберите URL в разделе Quick Glance на странице Dashboard, где показана тестовая среда облачной службы. Для выбора веб-сайта просто нажмите кнопку Browse на панели команд. По умолчанию развертывания из непрерывной интеграции для облачных служб размещаются в тестовой среде. Эту настройку можно изменить, указав в свойстве Alternate Cloud Service Environment значение Production. Для веб-сайтов не существует тестовой или рабочей среды.
Откроется вкладка браузера, на которой можно проверить работу сайта.
Если вы многократно вносили изменения в проект, количество сборок и развертываний будет довольно большим. Самые последние из них имеют статус Active.