Учебник. Московский финансовопромышленный университет Синергия Кафедра Системного программирования
 Скачать 3.83 Mb.
|
|
Тема 4. Знакомство с Team Environment Вопросы темы: 1 Логическая организация работы в Team Foundation Server. 2 Физические среды разработки и тестирования. 3 Архитектура Team Foundation Server. 4 Топология развертывания. 5 Стратегии структурирования решения и проекта. Вопрос 1. Логическая организация работы в Team Foundation Server. Продукт TFS позволяет команде разработчиков хранить исходный код в централизованном хранилище. Извлекая код из хранилища, при 45 помощи сервера сборки вы создаете сборки (build), а затем передаете их группе испытателей. На рис. 1 показано, как в TFS организован рабочий процесс и как связаны между собой среда разработчиков и среда испытателей. Рис. 1. Логический документооборот Team Foundation Server Тестовая группа запускает результаты сборки в тестовой среде, проводя сочетание ручных и автоматических тестов. Результаты тестов хранятся в TFS и используются для организации обратной связи по вопросам качества сборки. Кроме того, тестовая группа может создавать рабочие элементы и ошибки (особый тип рабочего элемента), на которые группе разработчиков следует обратить внимание. Эти элементы позволяют группе тестирования отслеживать работу группы разработчиков. Логическая организация работы в средах разработки, тестирования и производства В крупных организациях, где имеется несколько групп разработчиков, у каждой из них есть собственный TFS с отдельными хранилищами и серверами сборки. На рис. 2 показан пример логического потока операций для двух групп разработчиков, передающих сборки в объединенную группу испытаний. 46 Рис. 2. Логическая организация работ в двух группах разработчиков и одной группе комплексного тестирования Каждая группа разработки по расписанию передает сборки в точку сбора, например в общий сетевой ресурс. Группа тестирования извлекает сборки оттуда и проводит их испытания, определяя качество сборок. Когда контроль качества пройден, приложение развертывается на модельном сервере для итогового тестирования и проверки пользователями. После этого приложение развертывается на рабочем сервере. Процесс разработки Работая над проектом ПО, разработчики вовлечены в несколько ключевых взаимодействий с TFS. Например, разработчик взаимодействует с TFS следующими способами: Осуществляет доступ к ошибкам и задачам TFS, чтобы выяснить, какую работу ему нужно сделать. Рабочие элементы могут назначаться разработчику менеджером проекта, другим разработчиком или испытательной группой. Использует обозреватель исходного кода (Source Control Explorer) VSTS для получения доступа к хранилищу исходных 47 кодов TFS и загружает последнюю версию исходного кода в локальную рабочую область или на свой компьютер. Выполнив назначенную задачу, снова помещает код в БД управления исходным кодом. Размещение кода может запустить процесс непрерывной сборки при помощи Team Build. Если сборка завершилась неудачей, создается новый рабочий элемент для отслеживания ошибки. Процесс тестирования Тестировщик взаимодействует с TFS следующими способами: Извлекает результат плановой сборки из точки сбора. При помощи различных инструментов VSTS выполняет ручное и автоматическое тестирование, включая проверку безопасности, производительности и работы в веб. Выгружает результаты испытаний в БД тестирования для последующего использования. Регистрирует ошибки, выявленные в ходе тестирования, как новые рабочие элементы TFS. Разрешает существующие ошибки, если они устранены в последней сборке. Вопрос 2. Физические среды разработки и тестирования. Количество компьютеров в средах разработки и тестирования зависит от размера групп и объема проектов. На рис. 3 изображена типичная физическая среда разработки и тестирования. 48 Рис. 3. Физическая среда разработки и тестирования Среда разработки Среда разработки служит для поддержки процессов разработки и сборки и содержит следующие компьютеры: сервер Team Foundation Server; сервер сборок; сервер для сбора результатов работы сервера сборок; рабочие станции разработчиков. Если группа разработчиков осуществляет удаленный доступ к TFS или размер ее столь велик, что отрицательно сказывается на производительности центрального сервера TFS, для повышения эффективности работы вы можете также настроить TFS-прокси. Среда тестирования Среда тестирования состоит из одной или нескольких рабочих станций, на которых установлен продукт Visual Studio Team Edition for Software Testers. Он используется для управления циклом тестирования, а также для выполнения функционального тестирования, системного тестирования, тестирования производительности и веб-тестирования. 49 Члены группы используют TFS для управления рабочими элементами, ошибками и результатами тестов. В среду тестирования также может включаться продукт Visual Studio Team Test Load для проверки производительности. Вопрос 3. Архитектура Team Foundation Server. В TFS использована логическая трехуровневая архитектура, разделяющаяся на клиентский уровень, а также уровни приложений и данных. Клиенты TFS взаимодействуют с уровнем приложений посредством различных веб-служб. В свою очередь, уровень приложений поддерживается различными базами данных на уровне данных. Компоненты уровня TFS и их взаимодействие проиллюстрированы на рис. 4. Рис. 4. Компоненты и уровни TFS Клиентский уровень Клиентский уровень состоит из следующих компонентов: Объектная модель Team Foundation Server – открытый интерфейс API для взаимодействия с TFS, используется для создания клиентских приложений, обменивающихся данными с TFS. Компоненты Visual Studio Industry Partners (VSIP) – 50 инструменты сторонних поставщиков, надстройки и языки для использования в Visual Studio. Интеграция с Microsoft Office – набор надстроек для Microsoft Office Excel и Microsoft Office Project, позволяющих запрашивать и обновлять рабочие элементы в базе данных TFS Work Item Tracking. Особенно полезен для менеджеров проекта, уже широко использующих эти инструменты. Инструменты командной строки – инструменты, позволяющие взаимодействовать с TFS из командной строки. В основном используются для работы с функциями контроля качества исходного кода, также полезны для автоматизации повторяющихся процессов и при планировании заданий. Политики возврата после правки (check-in policy) – расширяемый механизм проверки кода в процессе возврата после правки. Уровень приложений На уровне приложений клиентскому уровню предоставляется доступ к веб-службам ASP. NET. Использование этих веб-служб в интеграторах от независимых разработчиков не предполагается; здесь они приведены только для полноты картины. Службы сгруппированы в следующие коллекции: Team Foundation Data Services. Team Foundation Integration Services. Службы данных Team Foundation. Эти веб-службы отвечают, в первую очередь, за операции с данными на уровне данных. К ним относятся следующие веб-службы: Version Control. Используется на клиентском уровне для выполнения различных функций TFS по контролю качества исходного кода и для взаимодействия с БД контроля качества исходного кода. Work Item Tracking. Используется на клиентском уровне для создания, обновления и направления запросов к рабочим элементам в БД Work Item Tracking. Team Foundation Build. Используется на клиентском уровне и в оболочке MSBuild для выполнения процесса сборки. Службы интеграции Team Foundation. Эти веб-службы обеспечивают функциональные возможности интеграции и автоматизации и не взаимодействуют с уровнем данных. К ним относятся следующие веб-службы: Registration. Используется для регистрации других служб TFS, сохраняет информацию в регистрационной БД. Информация 51 используется службами для обнаружения друг друга и определения способа взаимодействия. Security. Состоит из службы групповой безопасности (group security service) и службы проверки подлинности (authorization service). Служба групповой безопасности управляет всеми пользователями и группами TFS. Служба проверки подлинности обеспечивает авторизацию доступа к TFS. Linking. Содержит инструменты для создания слабых связей – «ссылок» (link) – между элементами данных. Например, связь между рабочим элементом дефекта и исходным кодом, измененным для устранения дефекта, устанавливается при помощи ссылки TFS. Eventing. Запускает инструмент или службу для регистрации типов событий. Пользователь может подписаться на события и получать уведомление по электронной почте или с помощью вызова веб-службы. Например, можно использовать событие возврата после правки для запуска непрерывной сборки. Classification. Работает вместе с веб-службой Linking и позволяет классифицировать артефакты TFS в соответствии с предопределенными таксономиями. Это облегчает поддержку объединенных отчетов даже для артефактов, которые не пользуются общей таксономией для упорядочивания своих данных. Например, если рабочие элементы упорядочены по группам, а тесты упорядочены по компонентам, вы также можете упорядочить тесты по группам, что позволит им фигурировать в отчете рядом с рабочими элементами. Уровень данных Прямой доступ из клиентских приложений к данным, хранящимся на уровне данных, в TFS не поддерживается. Все запросы к данным должны осуществляться через веб-службы на уровне приложений. Уровень данных TFS состоит из следующих хранилищ, соответствующих службам данных на уровне приложений: Отслеживание рабочих элементов. В этом хранилище хранятся все данные, относящиеся к рабочим элементам. Управление версиями. Здесь хранятся все данные, относящиеся к управлению исходным кодом. Team Foundation Build. Здесь хранится вся информация, относящаяся к TFS Team Build. Хранилище отчетов. Здесь хранится информация, относящаяся ко всем инструментам и функциям TFS. Хранилище отчетов облегчает создание отчетов, объединяющих данные от различных инструментов. Итак, архитектура Team Foundation Server разделена на три уровня: клиентский, приложений и данных. 52 На клиентском уровне находятся компоненты клиента, например, Team Explorer в Visual Studio 2005, интеграция с Microsoft Office и инструменты командной строки. На уровне приложений содержатся, например, службы управления версиями Team Foundation, службы отслеживания рабочих элементов и службы сборки. На уровне данных содержатся БД для хранения данных, необходимых для отслеживания рабочих элементов, управления версиями, групповой сборки и организации хранилища отчетов. Вопрос 4. Топология развертывания. Развертывание TFS выполняется с использованием различных топологий – от односерверных до сложных многосерверных типологий. Основные требования Независимо от используемой топологии, вам следует помнить о нескольких ключевых требованиях: Устанавливайте уровень приложений и уровень данных в одном и том же домене. При этом они могут находиться как на одном, так и на разных серверных узлах. TFS устанавливается на компьютеры под управлением Microsoft Windows Server 2003 SP1 или более поздней версии. Все веб-службы уровня приложений должны устанавливаться на одном сервере. Устанавливайте один экземпляр TFS на одном компьютере. Нельзя установить более одного экземпляра TFS на физический сервер. Не распределяйте БД TFS между несколькими серверами БД. Все проекты должны находиться в одной группе серверов Team Foundation и не могут быть распределены по группам. Для размещения портала проекта нельзя использовать существующую инфраструктуру Microsoft SharePoint Portal Server. Рассмотрите возможность использования специализированного сервера для размещения на нем порталов TFS SharePoint. При развертывании на двух серверах подготовьте учетные записи домена для служб TFS. Например, вам нужно будет создать учетные записи DOMAIN\TFSSERVICE и DOMAIN\TFSREPORTS. Развертывание на одном сервере Развертывание на одном сервере – простейшая топология, подходящая для групп разработчиков или пилотных проектов с числом 53 пользователей не более 400. В этом подходе все компоненты уровня приложений и уровня данных устанавливаются на один сервер, и доступ к ним осуществляется в пределах одного домена. Если вам нужно установить компоненты испытательного стенда для проверки производительности, установите их на серверном узле или на одном или нескольких клиентах. На рис. 5 показана топология с одним сервером. Рис. 5. Односерверная топология Развертывание на раздельных серверах Топология многосерверного развертывания используется в крупных группах разработчиков, насчитывающих до 2000 пользователей. В данной топологии уровень приложений устанавливается отдельно от уровня данных. Вы можете установить службы Team Foundation Build Services на уровень приложений, однако в крупных группах рекомендуется выделять для сборки один или несколько специальных серверов. Если в проекте требуется проверка производительности, разверните испытательный стенд (контроллер и агенты) на дополнительных серверных узлах. На рис. 6 показана многосерверная топология. 54 Рис. 6. Многосерверная топология Таким образом, в продукте TFS поддерживаются односерверная и многосерверная топологии развертывания. В первом случае уровень приложений и уровень данных устанавливаются на одной машине. Односерверное развертывание оправдано для небольших групп или при выполнении пилотных проектов. При раздельном развертывании уровень приложений и уровень данных устанавливаются на отдельных серверах. Многосерверное развертывание полезно в крупных группах с большим числом пользователей. Вопрос 5. Стратегии структурирования решения и проекта. Если вы работаете над небольшим проектом, для размещения всех файлов вам достаточно будет единственного решения. Если вы разрабатываете ПО с большим количеством проектов, воспользуйтесь несколькими решениями для группирования взаимосвязанных проектов, соответствующих различным аспектам функциональности общего проекта. В некоторых сценариях в дополнение к этим решениям может потребоваться и единый глобальный файл решения для объединения всех файлов проекта. Для структурирования файлов решений и проектов чаще всего используются три стратегии: Одиночное решение. Работая над небольшой системой, поместите все проекты в одиночное решение. Решение с разделами. Работая над крупной системой, используйте для группирования связанных проектов несколько решений. Они должны логически объединять подмножества проектов, которые разработчик, скорее всего, будет изменять одновременно. Кроме того, создайте одно глобальное решение, содержащее все проекты. Этот метод позволяет сократить объем данных, извлекаемых из 55 системы управления исходным кодом при работе над отдельным проектом. Несколько решений. Если вы работаете над очень большой системой, требующей десятков и более проектов, используйте для работы над подсистемами несколько самостоятельных решений. Глобальное решение, содержащее все проекты, не создавайте. В целом следует придерживаться следующих рекомендаций: используйте стратегию одиночного решения, даже если в результате получается решение слишком большое для загрузки его в Visual Studio; используйте несколько решений, чтобы получить возможность отдельно рассматривать подсистемы вашего приложения; разделяйте проект на несколько решений, чтобы сократить время, требующееся разработчикам на загрузку решения и его сборку. Разрабатывая структуру проекта и решения, учитывайте следующие моменты: Каждый проект во время сборки генерирует файл сборки (assembly). Для начала определите, какие файлы сборки вы хотите создать, а затем на основании этой информации решите, какие проекты вам нужны. Это поможет вам распределить код по проектам. Начните с простейшего варианта – одиночного решения. Усложняйте структуру, только если это действительно необходимо. Проектируя структуру с несколькими решениями, сделайте следующее: а) Учитывайте зависимости проектов. Старайтесь объединить в одном решении проекты, имеющие зависимости друг от друга. Это позволит использовать ссылки проекта в рамках решения. Использование ссылок проекта вместо файловых ссылок позволяет синхронизировать параметры конфигураций (Debug/Release) Visual Studio, а также отслеживать версии для определения момента очередной сборки проекта. Попытайтесь сократить количество ссылок проекта, указывающих в другие решения. б) Продумайте общее использование ресурсов. Размещайте в одном решении проекты с общим кодом. в) Учитывайте структуру групп. Компонуйте решения так, чтобы облегчить работу группам, занятым разработкой связанных проектов. Сохраняйте «плоскую» структуру проектов, чтобы удобнее было объединять их в решения, не меняя структуру файлов или папок системы управления исходным кодом. 56 Одиночное решение Если вы работаете над небольшой системой, Вам, вероятно, стоит разместить все проекты в одном решении Visual Studio. Эта структура упрощает разработку, поскольку при открытии решения сразу становится доступным весь код. При такой стратегии легко устанавливать ссылки, поскольку все ссылки связывают проекты, находящиеся в одном решении. Возможно, при этом вам все равно потребуются файловые ссылки для указания на файлы сборки сторонних производителей, например приобретенные компоненты, находящиеся за пределами решения. Метод одиночного решения проиллюстрирован на рис. 7. Рис. 7. Метод одиночного решения Вот основные доводы к использованию этой структуры: Сценарии сборки просты. Легко составить карту зависимостей между проектами в пределах решения. Такую структуру следует использовать, если все разработчики пользуются одним решением и имеют один и тот же набор проектов. Это не всегда возможно при разработке больших систем, где требуется упорядочивать проекты по подсистеме или функции. 57 Решение с разделами Если вы работаете над крупной системой, подумайте об использовании нескольких решений, каждое из которых представляло бы подсистему вашего приложения. Такие решения позволяют разработчикам работать над небольшими частями системы, не загружая весь код всех проектов. Составляйте структуру решений таким образом, чтобы проекты, имеющие зависимости, группировались вместе. Это позволит использовать ссылки на проекты, а не ссылки на файлы. Возможно, стоит также создать файл основного решения, в котором содержались бы все ваши проекты. Это глобальное решение может применяться для сборки всего приложения. Примечание. В отличие от предыдущих версий, система Visual Studio основана на MSBuild. Это позволяет создавать структуры решений, не включая в них все проекты, на которые имеются ссылки, и тем не менее производить сборку без ошибок. При условии что сначала выполняется сборка основного решения, при которой происходит генерация двоичных файлов для каждого проекта, система MSBuild способна отследить ссылки проекта, выходящие за рамки решения, и успешно выполнить сборку. Это сработает только в том случае, если вы используете ссылки на проекты, а не на файлы. Созданные таким образом решения можно успешно собирать из командной строки сборки Visual Studio или из интегрированной среды разработки, но по умолчанию не в Team Build. Чтобы провести успешную сборку в Team Build, используйте основное решение, включающее в себя все проекты и зависимости. При работе с несколькими решениями используйте плоскую файловую структуру во всех ваших проектах. Типичный пример – приложение, в котором имеется проект Microsoft Windows Forms, проект ASP. NET, служба Windows и набор проектов для библиотек классов, которые используются некоторыми или всеми вышеперечисленными проектами. Вы можете воспользоваться следующей плоской структурой применительно ко всем проектам: /Source /WinFormsProject /WebProject /WindowsServiceProject /ClassLibrary1 /ClassLibrary2 /ClassLibrary3 Web. sln Service. sln All. sln 58 На рис. 8 проиллюстрирован метод решения с разделами. Рис. 8. Метод решения с разделами Простота структуры обеспечивает гибкость и позволяет использовать решения для рассмотрения проектов с различных сторон. Физическую структуру папок решения очень трудно изменить, особенно если вы осознали, что вам необходимо использовать библиотеку классов из другого решения. Причины, по которым следует использовать эту структуру, таковы: При загрузке и сборке частичных решений для приложения повышается производительность. Частичные решения могут применяться для создания представлений наборов проектов в зависимости от структуры подгрупп разработчиков или границ совместного использования кода. Главное решение можно использовать для сборки всего приложения. Вы легко составите схему зависимостей между проектами любого частичного решения. 59 Логическое разделение решений уменьшает общую сложность работы. Например, новым разработчикам будет проще понять решение, разделенное на технологическую и функциональную части. Есть и довод в пользу того, чтобы не увлекаться использованием данной структуры: увеличение затрат на сопровождение решений. Добавление нового проекта может привести к необходимости изменения многих файлов решения. Несколько решений Работая над очень крупным решением, требующим многих десятков проектов, немудрено натолкнуться на ограничения масштабируемости. В этом случае вам уже просто придется разделить приложение на несколько решений, но уже не создавая главное решение для всего приложения, поскольку ссылки внутри решений могут быть только ссылками на проекты. Ссылки, выходящие за пределы решения (например, на библиотеки независимых разработчиков или проекты в другом решении), являются файловыми ссылками. Это означает, что главного решения быть не может. Вместо этого следует использовать сценарий, в котором указан порядок сборки решений. Одна из центральных задач обслуживания нескольких взаимосвязанных решений состоит в контроле за тем, чтобы разработчики случайно не создали циклические ссылки между решениями. Эта структура требует сложных сценариев сборки и явного отображения отношений зависимости. В Visual Studio полностью собрать подобное приложение уже невозможно. Придется воспользоваться непосредственно TFS Team Build или MSBuild. Структура с несколькими решениями показана на рис. 9. 60 Рис. 9. Структура с несколькими решениями Эту структуру следует использовать для очень крупных приложений, чтобы обойти проблемы с производительностью среды разработки Visual Studio и пределами масштабируемости. Один из недостатков этой структуры – сложные сценарии сборки, способные обработать зависимости частичных решений путем соблюдения нужного порядка сборки решений. Особенности крупных проектов Большие группы разработчиков, как правило, отличаются следующими особенностями: Им требуется более сложная структура ветвления и слияния. Для них более характерно управление зависимостями решений и командных проектов. Для них более характерно наличие нескольких сборок компонентов и групп. В большинстве крупных проектов хорошо работает структура решения с разделами, так как она одновременно обеспечивает гибкость и содержит единое решение, позволяющее собирать приложение целиком. Если ваше приложение настолько велико, что не вписывается в пределы масштабируемости, используйте метод нескольких решений. |