5.1. Организация работы над проектом посредством TFS

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

• разработка;

• тестирование;

• сборка;

• развертывание;

• выпуск.

Рассмотрим логическую организацию командной работы над проектом посредством Team Foundation Server

TFS позволяет команде разработчиков хранить исходный код в централизованном хранилище. Извлекая код из хранилища, при помощи сервера сборки создаются сборки (build) , которые затем передаются группе испытателей.

На рис.5.1 показано, как в TFS организован рабочий процесс и как связаны между собой среда разработчиков и среда испытателей.

Рис. 5.1. Логический документооборот Team Foundation Server

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

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

Рис. 5.2. Логическая организация работ в двух группах разработчиков и одной группе комплексного тестирования

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

Рассмотрим основные процессы командного проекта: разработку и тестирование

Процесс разработки предполагает несколько ключевых взаимодействий с TFS, в который вовлечены разработчики:

• Доступ к ошибкам и задачам TFS для выяснения задела работы. Рабочие элементы могут назначаться разработчику менеджером проекта, другим разработчиком или испытательной группой.

• Использование обозревателя исходного кода (Source Control Explorer) VSTS для получения доступа к хранилищу исходных кодов и загрузки последней версии исходного кода в локальную рабочую область или на свой компьютер.

• Размещение в БД управления исходным кодом модифицированных исходников.

Размещение кода может запустить процесс непрерывной сборки при помощи Team Build. Если сборка завершилась неудачей, создается новый рабочий элемент для отслеживания ошибки.

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

• Извлечение результатов плановой сборки из точки сбора.

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

• Выгрузка результатов испытаний в БД тестирования для последующего использования.

• Регистрация ошибок, выявленных в ходе тестирования, как новых рабочих элементов TFS.

• Разрешение существующих ошибок, если они устранены в последней сборке.

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

Количество компьютеров в средах разработки и тестирования зависит от размера групп и объема проекта. На рис.5.3 изображена типичная физическая среда разработки и тестирования.

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

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

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

• сервер Team Foundation Server ;

• сервер сборок;

• сервер для сбора результатов работы сборок;

• рабочие станции разработчиков.

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

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

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

В среду тестирования также может включаться продукт Visual Studio Team Test Load для проверки производительности и соответствия стандартам.

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

5.2. Архитектура TFS

Microsoft Visual Studio TFS предназначен для обеспечения совместной работы команд разработчиков программного обеспечения. TFS предоставляет следующие функциональные возможности:

• управление проектами;

• отслеживание рабочих элементов;

• контроль версий;

• управление тестовыми случаями;

• автоматизация построения;

• отчетность.

Архитектура TFS 2012 и выше является трехуровневой сервис-ориентированной (рис. 5.4).

Рис. 5.4. Архитектура Team Foundation Server

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

• служба управления доступом;
• служба управления версиями;
• служба построения;
• служба отслеживания рабочих элементов;
• служба тестирования (Lab Management);
• Службы формирования отчетов;
• службы платформы TFS.

Серверная объектная модель является интерфейсом прикладного программирования для TFS. При необходимости расширение функциональности TFS целесообразно строить на базе серверной объектной модели.

Уровень данных поддерживается сервером баз данных MS SQL Server 2012 и выше.

Состоит из нескольких реляционных баз данных и хранилища данных:

• базы данных конфигурации сервера;
• базы данных аналитики;
• базы данных коллекции командных проектов;
• хранилища данных.

Информация командных проектов сохраняется в реляционных базах данных, и через запланированные интервалы времени помещается в хранилище данных.

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

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

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

В простейшей серверной топологии для размещения компонентов, составляющих логические уровни Team Foundation, используется один физический сервер (рис. 5.5). При установке TFS с одним сервером все компоненты (приложение TFS, SQL Server, Reporting Services и Widows Share Point Services) устанавливаются на одном компьютере. Такая конфигурация предполагает выполнение построения (Team Foundation Build) и тестирование либо на сервере, либо на клиентских компьютерах. Общее число пользователей для такой конфигурации, как правило, не более 50.

Рис. 5.5. Простейшая серверная топология TFS

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

Рис. 5.6. Простая серверная топология TFS

На рис. 5.6 веб-службы и базы данных Team Foundation размещаются на одном физическом сервере, но службы построения устанавливаются на отдельный компьютер. К Team Foundation Server можно получить доступ с клиентских компьютеров, принадлежащих к той же рабочей группе или тому же домену. В данной конфигурации контроллер построения для выполненияTeam Foundation Build и контроллер тестирования устанавливаются на отдельных компьютерах. Общее число пользователей для такой конфигурации, как правило, не более 100.

В серверной топологии средней сложности используются два или больше серверов для размещения логических компонентов на уровне данных и приложений Team Foundation (рис. 5.7). На рис. 5.7 службы уровня приложений для Team Foundation Server развертываются на одном сервере, а базы данных для TFS устанавливаются на отдельном сервере. На отдельных серверах размещаются веб-приложение SharePoint и экземпляр служб отчетов SQL Server. При этом портал для каждого командного проекта размещается в веб-приложении SharePoint. Сервер Team Foundation Build и тестовые контроллеры команды развертываются на дополнительных серверах. Общее число пользователей для такой конфигурации, как правило, не более 1000.

Рис. 5.7. Серверная топология TFS средней сложности

5.4. Шаблоны командных проектов применяются для упорядочения работы над проектом и регламентирования членов команды

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

• MSF for CMMI Process Improvement 6.0, который предназначен для больших команд со строго формальным подходом к управлению проектами на основе модели CMM/CMMI;

• MSF for Agile Software Development 6.0, который определяет гибкий подход к управлению проектами разработки программного обеспечения;

• Microsoft Visual Studio Scrum 2.2., который предназначен для небольших команд (до 7 – 10 участников), которые используют гибкую методологию и терминологию Scrum.

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

• отслеживание рабочих элементов позволяет определить начальные типы рабочих элементов, общие и пользовательские запросы, создать начальные рабочие элементы;

• классификации позволяют определить начальные области и итерации проекта;

• веб-сайт на базе SharePoint позволяет управлять библиотекой документов проекта;

• система контроля версий позволяет определять начальные группы безопасности, разрешения, правила возврата версий;

• отчеты формируются в папки, создаваемые на сайте командного проекта;

• группы и разрешения включают группы безопасности TFS и набор разрешений для каждой группы;

• построения включают стандартные процессы построения для создания новых построений;

• управление тестированием включает стандартные конфигурации тестирования, переменные, параметры и состояния разрешений.

В зависимости от шаблона различают набор и наименование рабочих элементов. Так для гибкой методологии Agile определены такие рабочие элементы:

• Рабочий элемент "Пользовательское описание функциональности" представляет собой пользовательское требование, которое необходимо выполнить при реализации проекта.
• Рабочий элемент "Задача" создается в проекте для назначения и выполнения работы. Задачи предоставляют детали реализации для пользовательских требований.
• Рабочий элемент "Ошибка" используется для отслеживания и мониторинга проблем в программном продукте.
• Рабочий элемент "Препятствие" используется для фиксации в проекте событий или объектов, которые создают проблемы в выполнении проекта и должны быть устранены в ходе текущей или следующей итерации.
• Рабочий элемент "Тестовый случай" описывает условия проверки правильности выполнения программным продуктом требований пользователя.

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

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

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

• Командного обозревателя в Visual Studio;

• Microsoft Project;

• Microsoft Excel.

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

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

• атомарные возвраты. Изменения, вносимые в файлы, упаковываются с "набор изменений". Возврат файла в наборе изменений представляет собой неделимую транзакцию. Этим гарантируется согласованность базы кода;

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

• ветвление и объединение при разработке кода;

• наборы отложенных изменений позволяют создавать копии кода не записывая их в главное хранилище системы контроля версий;

• использование подписей позволяет пометить набор файлов в определенной версии с помощью текстовой подписи;

• одновременное извлечение позволяет нескольким членам команды одновременно редактировать файл с последующим объединением изменений;

• отслеживание истории файлов;

• политики возврата, которые предоставляют возможность выполнить код для проверки допустимости возврата;

• примечания при возврате позволяют формировать метаданные о возврате;

• прокси-сервер позволяет оптимизировать работу с региональными центрами разработки.

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

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

MicrosoftVisual StudioTFS предназначен для обеспечения совместной работы команд разработчиков программного обеспечения и имеет трехуровневую сервис-ориентированную архитектуру. Клиентский уровень реализован в оболочке Visual Studioи веб-браузере. Уровень приложения TFS состоит из нескольких веб-служб. Уровень данных включает несколько реляционных баз данных и хранилище данных. РазвертываниеTFS можно выполнить на одном сервере, на нескольких серверах, в одном домене, рабочей группе или в нескольких доменах. Командный проект представляет коллекцию рабочих элементов, кода, тестов и построений. Проект строится на основе шаблонов. Рабочими элементамивTFS являются: пользовательское описание функциональности, задачи, тестовые случаи, ошибки и препятствия. TFS включает централизованную систему контроля версий. Построение проекта программного продукта в TFS реализует сервер Team Foundation Build. Разработчик имеет возможность взаимодействовать с ключевыми службами TFS посредством командного обозревателя, доступа через веб, MicrosoftExcel, MicrosoftProject, консоли администрирования TFS и инструментов командной строки.