Коллективная разработка с использованием Visual Studio Team Foundation Server

Microsoft®

Коллективная разработка с использованием Visual Studio Team Foundation Server

Коллективная разработка с использованием Visual Studio Team Foundation Server

patterns & practices

Дж.Д. Мейер Джейсон Тейлор Алекс Макман Прашант Бансод Кевин Джонс

Информация, представленная в данном документе, включая URL и другие ссылки на Вебсайты, может быть изменена без дополнительного уведомления. Если не указано обратное, приведенные названия компаний, организаций, продуктов, доменные имена, адреса электронной почты, товарные знаки, люди, географические наименования и события являются вымышленными и не имеют никакой связи с реальными компаниями, организациями, продуктами, доменными именами, адресами электронной почты, товарными знаками, людьми, географическими наименованиями или событиями. Ответственность за соблюдение всех применимых в данном случае законов об авторском праве несет пользователь. Ни одна часть этого документа не может быть воспроизведена, представлена или храниться в системе поиска, передаваться в любой форме или любыми средствами (электронными, механическими, фотокопированием, средствами звукозаписи и пр.) в любых целях без письменного разрешения от корпорации Майкрософт. Майкрософт может обладать патентами, заявками на патент, торговыми марками, авторскими правами или другими правами на интеллектуальную собственность по отношению к материалам, представленным в данном документе. Предоставление данного документа без письменного лицензионного соглашения от Майкрософт не дает никакого права на использование этих патентов, торговых марок, авторских прав или любой другой интеллектуальной собственности. © 2007 Microsoft Corporation. Все права защищены. Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, MSDN, Visual Basic, Visual C++, Visual C#, Visual Studio и Win32 являются зарегистрированными торговыми марками или торговыми марками корпорации Майкрософт в США и/или других странах. Имена реальных компаний и продуктов, упомянутые здесь, могут быть торговыми марками их владельцев.

Предисловие Джеффа Билера Прежде чем выпустить Microsoft® Visual Studio® 2005 Team Foundation Server (TFS), мы использовали его для разработки TFS. Последние 18 месяцев работы над проектом он широко применялся для управления жизненным циклом его собственной разработки. С помощью этой практики, известной под названием «dogfooding» или «проверка на себе», мы многое узнали о создаваемой нами мощной системе. Конечно же, было выявлено и исправлено множество ошибок, так что конечный продукт получился намного более стабильным и производительным. Но, вероятно, важнее всего то, что были найдены наилучшие варианты использования (и не использования) создаваемых инструментов. Этот опыт в сочетании с обратной связью, получаемой от наших заказчиков, формируют основу данного руководства.

На первый взгляд можно ожидать, что эта информация должна быть включена в или заменить документацию по продукту. Кстати, одно время я тоже придерживался такого мнения. Однако поработав в тесном соавторстве с Дж.Д. Мейером (J.D. Meier) и другими авторами данного руководства, я осознал, что разделение этих документов настолько же естественно, насколько важно. Мне кажется, лучше всего это можно объяснить, сравнив два руководства – инструкцию для владельца автомобиля и руководство для водителя – нужны оба, но цели их использования разные. Традиционно, группа разработки продукта занимается исключительно документацией по продукту. Руководства обычно создаются третьими лицами, хотя, сейчас ситуация немного изменилась, и мы стали уделять больше своего времени и энергии этому вопросу, потому что осознаем его важность в успешном внедрении нашего продукта и его роль в повышении общей удовлетворенности потребителей.

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

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

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

Мы разработали TFS с целью обеспечения лучшего взаимодействия групп и, тем самым, создания лучшего ПО. Испытывая TFS «на себе», мы добились слаженной работы своих групп, и, надеюсь, вы согласитесь, получили в результате замечательный продукт. Это руководство поможет вам и вашей группе реализовать данную концепцию уже в следующем вашем проекте.

Всего хорошего!

Джефф Билер (Jeff Beehler) Руководитель отдела разработки Visual Studio Team System Июль, 2007

Джефф Бихлер – Руководитель всего отдела разработки Team System. По окончании Университета Колорадо в 1990 начал свою карьеру в Майкрософт, работал над ранними версиями Visual C++. В 1996 ушел из Майкрософт и посвятил себя другим занятиям, включая консалтинг и преподавание в начальной школе, обзавелся семьей. Вернулся в Майкрософт в 2003 для работы над Visual Studio Team System, участвовал во многих работах над проектом, от планирования до исполнения и выпуска. Яростный приверженец «испытания на себе» всех частей Team System, что по его убеждению помогает ему делать его работу лучше. Свободное время Джефф любит проводить с семьей на свежем воздухе, фотографируя и наслаждаясь замечательной природой серверо-запада.

Предисловие Роба Карона С самых первых дней работы над Visual Studio Team System мы знали, что группам разработки ПО понадобится больше информации, чем мы могли предоставить до поставки продукта. В частности, была очевидна необходимость в испытанном руководстве и лучших практиках, однако, они могли появиться лишь в результате испытаний продукта многими группами в разных средах, проектах и сценариях.

К сожалению, наработка лучших практик и создание проверенного руководства требует времени. За последние несколько лет мы многое узнали об использовании Team System в общем и Team Foundation Server в частности. Но эту информацию было не всегда легко отыскать и систематизировать. Для этого потребовались месяцы самоотверженной и методичной работы ветерана отдела patterns & practices Дж.Д.Мейера и его команды.

И вот, наконец, «Коллективная разработка с использованием Visual Studio Team Foundation Server» представляет коллективный труд огромного количества людей, прямо или косвенно участвующих в этом проекте. Группа, которая свела воедино всю эту информацию, не проигнорировала опыт тех, кто шел перед ними. Они обработали огромнейшую разнородную массу сообщений блогов, форумов, статей и пр., чтобы лучше понять, как группы используют Team System «в естественных условиях».

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

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

Роб Карон (Rob Caron) ведущий руководитель, ответственный за выпуск продукта

Корпорация Майкрософт Июль, 2007

Роб Карон – ведущий руководитель, ответственный за выпуск продукта в отделе Стратегии создания документации для разработчиков компании Майкрософт. Роб начал работать в Майкрософт с 1999 как создатель документации по продукту Visual Studio. Он участвовал в написании документации для Visual Studio .NET 2002, Visual Studio .NET 2003 и Visual Studio Team System. В середине 2004 он создал блог, ставший основным источником информации по Team System. Посвятив семь лет разработке документации, осенью 2006 Роб перешел в отдел маркетинга для разработчиков. Сейчас он руководит группой, основной целью которой является упрощение стремительно усложняющейся «истории разработчика» в Майкрософт.

Предисловие Брайана Гарри Процесс разработки программного обеспечения может быть очень сложным. Созданием ПО занимаются как очень маленькие группы, так и группы, насчитывающие тысячи человек с массой специальных ролей. Приступая к работе над Microsoft® Visual Studio® Team System, мы хотели создать инструменты, которые помогут разработчикам представлять, организовывать, проектировать, планировать, собирать, тестировать, разворачивать и управлять приложениями. Team Foundation Server (TFS) – это центральный элемент Team System, связывающий воедино всех людей и работы, вовлеченные в жизненный цикл приложения.

В результате, Team System обладает широкими возможностями, спроектирована согласно потребностям разных людей, выполняющих разные роли. Мы постарались сделать продукт максимально простым, но при этом достаточно гибким с возможностью адаптации соответственно нуждам разнообразнейших групп разработки. За последний год стало очевидным, что пользователям Team System не хватает ключевого компонента. Имеется масса документации и различных руководств, «как это сделать», но не хватает хорошей книги о том, как это «должно быть». Руководство по процессу в Team System частично заполняет возникшую пропасть, но преимущественно сосредоточено на людях, ролях и последовательности операций. Требовалась по-настоящему цельная документация о стратегиях реализации процесса разработки ПО.

Новое «Руководство по TFS, шаблоны и практики» именно то, что нужно. Оно охватывает широкий диапазон тем, от «Как следует организовывать групповые проекты?» и «Какая структура ветвления и слияния должна использоваться?» до «Сколько сборок должно быть и как часто их надо выполнять?» и «Как управлять проектом с помощью Team System?». Все вопросы в данном руководстве рассматриваются на примере лучших практик и в контексте того, как они могут применяться в конкретных условиях и как их можно реализовать в TFS.

Это руководство преимущественно основывается на практиках разработки ПО, созданных и принятых в Майкрософт в течение последних 30 лет. Более того, здесь учтен реальный опыт использования TFS, поскольку Developer Division (Отдел разработки) применяет TFS в процессе разработки уже более двух лет. Я искренне надеюсь, что наш опыт и лучшие практики будут вам полезны.

Брайан Гарри (Brian Harry) член технического совета (Technical Fellow1), Visual Studio Team System Июль, 2007

Брайан Гарри – руководитель отдела по разработке продуктов для Team Foundation Server. Брайан всегда питал особую страсть к инструментальным средствам разработки ПО, еще со студенческих времен в середине 80-х в Государственном университете Серверной Каролины, когда он экспериментировал с компиляторами, компоновщиками, ассемблерами, системами моделирования процессоров и т.д. Придя в Майкрософт, Брайан работал в отделе, в то время называвшемся Tools and Databases (Инструментальные средства и базы данных). Пару лет он проработал в SourceSafe и затем в Microsoft Repository. Затем он участвовал в разработке .NET Framework в качестве руководителя группы исследований и разработки для Общеязыковой среды выполнения (Common Language Runtime) и затем как Руководитель отдела по разработке продукта (Product Unit Manager). В конце 2002 он вернулся в Северную Каролину, чтобы помочь в открытии центра разработки инструментальных средств для разработчиков. Брайан собрал там команду примерно в 50-60 человек, которая работает над продуктами Team Foundation Server и Visual Studio Team System for Testers (Visual Studio Team System для тестировщиков).

1

Звание Technical Fellow – это признание той ключевой роли, которую играет лидер в области какой-либо технологии в намеренном продвижении инноваций, в согласовании их с бизнесстратегиями Майкрософт, таким образом влияя на высокотехнологический сектор в целом. Технологическое видение, квалификация и лидерские качества мирового класса Technical Fellow соизмеримы с таковыми у вице-президента корпорации, чье внимание сосредоточено на лидерстве в области бизнеса. Такие люди способствуют разработке и продвижению технический стратегий для Майкрософт и всей индустрии (источник: http://www.microsoft.com/presspass/exec/techfellow/default.mspx).

Введение Данное руководство показывает, как с помощью Visual Studio 2005 Team Foundation Server максимально увеличить эффективность коллективной разработки ПО. Представленные здесь рекомендации и анализ будут полезны и тем, кто уже использует Team Foundation Server, и тем, кто только планирует перейти на него.

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







 







Часть I, «Основы», предлагает краткий обзор коллективной разработки с использованием Team Foundation Server. Дается общее представление о коллективной разработке с точки зрения среды разработки ПО, включая среды разработки и тестирования. Также представлена базовая архитектура Team Foundation Server. Часть II, «Система контроля версий исходного кода», показывает, как структурировать исходный код и управлять зависимостями. Также рассказывает, как правильно выбрать стратегию ветвления и слияния для обеспечения изолированной разработки. Часть III, «Сборки», показывает, как настраивать сборки проектов, как создавать сборки в результате процесса непрерывной интеграции для группы разработки и как передавать плановые сборки группе тестирования. Также обсуждаются общие проблемы и их решение. Часть IV, «Рекомендации по работе над большим проектом», обращает внимание на дополнительные вопросы, которые придется решать при работе над большими проектами. Часть V, «Управление проектом», показывает, как использовать рабочие элементы, области и итерации Team Foundation Serve для организации процесса разработки независимо от применяемого подхода к управлению проектом. Часть VI, «Шаблоны процессов», показывает, как максимально эффективно использовать шаблоны процессов и руководство по процессу, поставляемые с Team Foundation Server. Также рассказывает, как можно настраивать шаблоны процессов и изменять рабочие элементы и последовательность операций соответственно процессу разработки ПО, который уже используется вашей группой. Часть VII, «Создание и отображение отчетов», показывает, как все компоненты Team Foundation Server интегрируют свои данные в общий механизм создания отчетов. Рассказывает, как использовать стандартные отчеты и создавать собственные специальные отчеты. Часть VIII, «Настройка и обслуживание среды коллективной разработки», раскрывает загадку развертывания Team Foundation Server. Научит выбирать тип развертывания, на одном или на двух серверах. Также расскажет, как







  

поддерживать удаленные группы разработки и как максимально увеличить производительность Team Foundation Server. Часть IX, «Visual Studio Team System 2008 Team Foundation Server», представляет изменения, внесенные в следующую версию Team Foundation Server. Расскажет о том, какие новые функции планируется ввести, а также какие функции будут существенно улучшены. Как следствие некоторых из изменений, меняются и рекомендации, предлагаемые в данном руководстве, поэтому используйте данный раздел при планировании обновления Team Foundation Server. Рекомендации, предлагает краткие рекомендации для Team Server Build, управления проектом, систем создания и отображения отчетов и контроля версий. Каждая рекомендация указывает, что делать, почему и как следовать рекомендации. Практические рекомендации, предоставляет ряд лучших практик, основанных на опыте, полученном группами разработки при использовании Team Foundation Server в реальных условиях и в рамках Майкрософт. В практических рекомендациях рассматриваются задачи, имеющие особое значение для эффективности работы группы при использовании Team Foundation Server. Вопросы и ответы, дает ответы на самые распространенные вопросы по системе контроля версий Team Foundation. Статьи «Как…», пошаговое подробное руководство по выполнению конкретных задач с использованием Team Foundation Server. Ресурсы, сборник веб-сайтов, провайдеров сервисов, форумов и блогов, которые можно использовать как источники дополнительной информации по Team Foundation Server, чтобы оставаться в курсе последних разработок инструментария.

Коллективная разработка Успех групповых проектов разработки ПО обеспечивает сочетание многих элементов, процессов и ролей. Данное руководство основное внимание обращает на:   

Процесс разработки Процесс сборки Процесс управления проектом

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

Сфера рассмотрения данного руководства Основное внимание в данном руководстве направлено на развертывание Team Foundation Server и эффективное его использование для контроля версий, автоматизации сборок, управления рабочими элементами и процессом.

На следующей диаграмме представлен пример логической реализации Team Foundation Server с точки зрения наиболее типичных ролей в разработке ПО и жизненном цикле разработки.

Почему было создано данное руководство Из собственного опыта работы с Team Foundation Server и из бесед с пользователями и сотрудниками Майкрософт, работающими в этой области, стала ясна необходимость в руководстве, объясняющем, как использовать Team Foundation в реальных условиях. Имелась документация по продукту, специализированные блоги и форумы, но не было единого источника, в котором можно было бы найти проверенные практики эффективного использования Team Foundation Server в контексте проекта разработки в реальных условиях.

Для кого написано данное руководство Цель данного руководства – обеспечить участников процесса разработки ПО ресурсами, шаблонами и практиками создания эффективной среды для коллективной разработки. Это руководство будет полезно:



Группе разработки, которая желает перейти к использованию Team Foundation.



 

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

Как использовать данное руководство Руководство разделено на части, исходя из порядка, в котором группы обычно рассматривают и используют Team Foundation. Тот, кто находится на этапе внедрения Team Foundation, вероятно, захочет прочитать все руководство от начала до конца. Если речь идет о конкретном применении Team Foundation, например, о системе контроля версий или Team Build, можно ограничиться только разделами, посвященными этим вопросам. В основных главах изложены концепции и основные принципы. Приложения «Рекомендации», «Практические рекомендации», статьи «Как…» и «Вопросы и ответы» углубляются в детали реализации. Такое разделение обеспечивает читателю возможность сначала понять тему, а потом уже заниматься детальной ее проработкой, если в этом есть необходимость.

Как организовано данное руководство Это руководство можно читать полностью, от начала до конца, или только интересующие вас главы.

Части Руководство разделено на девять частей:         

Часть I, Основы Часть II, Система контроля версий исходного кода Часть III, Сборки Часть IV, Рекомендации по работе над большим проектом Часть V, Управление проектом Часть VI, Шаблоны процессов Часть VII, Создание и отображение отчетов Часть VIII, Настройка и обслуживание среды коллективной разработки Часть IX, Visual Studio Team System 2008 Team Foundation Server

Часть I, Основы  

Глава 1 – Введение в среду для коллективной разработки Глава 2 – Архитектура Team Foundation Server

Часть II, Система контроля версий исходного кода

   

Глава 3 – Структурирование проектов и решений в системе контроля версий Глава 4 – Структурирование проектов и решений в системе контроля версий Team Foundation Server Глава 5 – Выбор стратегии ветвления и слияния Глава 6 – Управление зависимостями системы контроля версий в Visual Studio Team System

Часть III, Сборки   

Глава 7 – Team Build Глава 8 – Как настроить процесс непрерывной интеграции с помощью Team Build Глава 9 – Настройка плановых сборок в Team Build

Часть IV, Рекомендации по работе над большим проектом 

Глава 10 – Рекомендации по работе над большим проектом

Часть V, Управление проектом  

Глава 11 – Управление проектом Глава 12 – Рабочие элементы

Часть VI, Шаблоны процессов  

Глава 13 – Шаблоны процессов Глава 14 – Проекты MSF Agile

Часть VII, Создание и отображение отчетов 

Глава 15 – Создание и отображение отчетов

Часть VIII, Настройка и обслуживание среды коллективной разработки  

Глава 16 – Развертывание Team Foundation Server Глава 17 – Обеспечение доступа к Team Foundation Server через Интернет

Часть IX, Visual Studio Team System 2008 Team Foundation Server 

Глава 18 – Что нового в Visual Studio 2008 Team Foundation Server

Рекомендации  

Рекомендации: Team Build Рекомендации: Система контроля версий

 

Рекомендации: Создание и отображение отчетов Рекомендации: Управление проектом

Практические рекомендации    

Краткие практические рекомендации: Team Build Краткие практические рекомендации: система контроля версий Краткие практические рекомендации: создание и отображение отчетов Краткие практические рекомендации: управление проектом

Вопросы и ответы 

Вопросы и ответы: система контроля версий

Статьи «Как…»                

Как: добавить нового разработчика в проект Visual Studio Team Foundation Server Как: с помощью Team Build автоматически выполнять анализ кода в Visual Studio Team Foundation Server Как: создать специальный отчет для Visual Studio Team Foundation Server Как: создать отчет о динамике рисков для Visual Studio Team Foundation Server Как: создавать специальные политики регистрации изменений в коде в Visual Studio Team Foundation Server Как: создать собственное дерево каталогов исходного кода в Visual Studio Team Foundation Server Как: настроить шаблон процесса в Visual Studio Team Foundation Server Как: настроить отчет в Visual Studio Team Foundation Server Как: управлять проектами в Visual Studio Team Foundation Server Как: перенести исходный код из Visual Source Safe в Team Foundation Server Как: выполнить слияние без общей родительской версии в Visual Studio Team Foundation Server Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server Как: настроить плановую сборку в Visual Studio Team Foundation Server Как: структурировать приложения ASP.NET в Visual Studio Team Foundation Server Как: структурировать приложения Windows в Visual Studio Team Foundation Server Как: структурировать каталоги системы контроля версий в Visual Studio Team Foundation Server

Ресурсы 

Ресурсы Team Foundation Server

Обратная связь и поддержка Мы приложили максимум усилий, чтобы избежать ошибок и неточностей в данном руководстве и сопровождающих материалах.

Обратная связь Свои комментарии по данному руководству присылайте по адресу

[email protected].

Нам особенно интересно ваше мнение по таким вопросам:  

Технические вопросы относительно рекомендаций Полезность и применимость

Техническая поддержка Техническую поддержку продуктов и технологий Майкрософт, упоминаемых в данном руководстве, обеспечивает Microsoft Product Support Services (PSS). Информацию о поддержке продукта можно получить на Веб-сайте Microsoft Product Support по адресу http://support.microsoft.com.

Поддержка сообщества Группы новостей (форумы) MSDN: http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=5&SiteID=1.

Форум

Адрес

Team Foundation Server общие вопросы

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =22&SiteID=1

Team Foundation Server – установка

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =68&SiteID=1

Team Foundation Server администрирование

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =477&SiteID=1

Team Foundation Server – автоматизация сборки

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =481&SiteID=1

Team Foundation Server – мощные миниинструменты

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =930&SiteID=1

Team Foundation Server – шаблоны процессов

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =482&SiteID=1

Team Foundation Server – создание и отображение отчетов и хранилище данных

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =480&SiteID=1

Team Foundation Server – доступ через Веб к Team

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =1466&SiteID=1

System Team Foundation Server – система контроля версий

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =478&SiteID=1

Team Foundation Server – отслеживание рабочих элементов

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID =479&SiteID=1

Создатели руководства В создании данного руководства принимали участие:     

Дж.Д. Мейер (J.D. Meier) Джейсон Тейлор (Jason Taylor) Алекс Макман (Alex Mackman) Прашант Бансод (Prashant Bansode) Кевин Джонс (Kevin Jones)

Участники и рецензенты  



Внешние участники/рецензенты. David P. Romig, Sr; Dennis Rea; Eugene Zakhareyev; Leon Langleyben; Martin Woodward; Michael Rummier; Miguel Mendoza ; Mike Fourie; Quang Tran; Sarit Tamir; Tushar More; Vaughn Hughes Участники/рецензенты, являющиеся сотрудниками Microsoft. Aaron Hallberg; Ahmed Salijee; Ajay Sudan; Ajoy Krishnamoorthy; Alan Ridlehoover; Alik Levin; Ameya Bhatawdekar; Bijan Javidi; Bill Essary; Brett Keown; Brian Harry; Brian Moore; Brian Keller; Buck Hodges; Burt Harris; Conor Morrison; David Caufield; David Lemphers; Doug Neumann; Edward Jezierski; Eric Blanchet; Eric Charran; Graham Barry; Gregg Boer; Grigori Melnik; Janet Williams Hepler; Jeff Beehler; Jose Parra; Julie MacAller; Ken Perilman; Lenny Fenster; Marc Kuperstein; Mario Rodriguez; Matthew Mitrik; Michael Puleio; Nobuyuki Akama; Paul Goring; Pete Coupland; Peter Provost; Granville (Randy) Miller; Richard Berg; Rob Caron; Robert Horvick; Rohit Sharma; Ryley Taketa; Sajee Mathew; Siddharth Bhatia; Tom Hollander; Tom Marsh; Venky Veeraraghavan, Viktor Shatokhin Русский вариант Шатохина Надежда, Дмитрий Лапшин, Александр Макаренко, Владимир Лещинский

Поделитесь с нами своим успехом Если данное руководство было вам полезным, мы были бы рады узнать об этом. Напишите короткую сводку проблем, с которыми вы столкнулись, и то, как руководство помогло в их решении. Свои письма присылайте по адресу: [email protected]

Шатохина Надежда Независимый технический переводчик. В 2000 г. закончила Национальный аэрокосмический университет (ХАИ) по специальности Энергетические установки космических летальных аппаратов. 2000-2001 работала на кафедре Двигателей и энергоустановок летательных аппаратов, участвовала в разработке ПО для микроспутника. С 2002 года занимается техническими переводами литературы по ИТ и языкам программирования. Сотрудничает с Русской редакцией и издательством Символ-плюс. Статьи на сайтах www.uneta.org, www.gotdotnet.ru, www.dotsite.spb.ru, www.vbnet.ru. Книги: «Каскадные таблицы стилей для профессионалов (Cascading Style Sheets: The Definitive Guide)» «Основы ActionScript 2.0 (Essential ActionScript 2.0)» (O'Reilly) «Введение в EJB (HeadFirst EJB)» « UML 2 и унифицированный процесс, второе издание (UML 2 and the Unified Process, Second Edition)» «С++, общие знания (C++ Common Knowledge)» (Addison-Wesley) «Изучение SQL (Learning SQL)» (O'Reilly) «Сборник рецептов ActionScript 3.0 (ActionScript 3.0 Cookbook)» (O'Reilly) «Сборник рецептов SQL (SQL Cookbook)» (O'Reilly). Контактная информация: E-mail: [email protected] Дмитрий Лапшин Отвечает за процесс и технологии разработки ПО, а также за экспертизу архитектурных и технических решений в отделении, специализирующемся на разработке приложений для бизнеса на основе платформ и инструментария Microsoft в компании GlobaLogic Украина. В прошлом - разработчик, технический руководитель и менеджер проектов. Практически с самого начала работы в области создания коммерческого ПО интересовался вопросами объектно-ориентированного дизайна, наилучшими практиками написания кода и прогрессивными технологиями разработки, что и позволило проделать к сегодняшнему моменту довольно интересный профессиональный путь. По образованию - специалист в области информационной безопасности, но на практике эти навыки оказались невостребованными. Контактная информация: E-mail: [email protected]

Макаренко Александр Тесно работает с платформой .Net уже более пяти лет. Является «MCPD: Enterprise Applications Developer». В профессиональной деятельности совмещает позиции проектного менеджера и руководителя команды .Net разработчиков. Один из основателей и официальный представитель Belarusian .Net User Group. Всегда интересуется последними решениями и технологиями от Майкрософт. Контактная информация: E-mail: [email protected] Лещинский Владимир Кандидат технических наук, старший преподаватель кафедры программного обеспечения ЭВМ Харьковского национального университета радиоэлектроники, один из лидеров Харьковской группы профессиональных разработчиков на платформе .Net "UNETA" и Харьковской группы IT специалистов "TECHNET", руководитель проектной группы одной из крупнейших компаний Украины, разрабатывающей ПО на платформе .Net. Читает лекции по дисциплинам: "Основы разработки ПО на платформе .Net", "Разработка Web-сервисов (WCF)", "Основы разработки WEB-приложений (ASP.NET)", "Проектирование программного обеспечения для автоматизированных систем". Контактная информация: E-mail: [email protected]

Часть I Основы В данной части:  

Введение в среду для коллективной разработки Архитектура Team Foundation Server

Глава 1 – Введение в среду для коллективной разработки Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи    

Показать, как Microsoft® Visual Studio® Team Foundation Server обеспечивает жизненный цикл разработки программного обеспечения. Показать, как типовая группа разработчиков может использовать Team Foundation Server. Описать использование Team Foundation Server типовой группой тестирования. Описать физическую среду групп разработки и тестирования.

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

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

    

Разработка Тестирование Сборка Развертывание Выпуск продукта

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

Как использовать данную главу Данная глава рассказывает о Team Foundation Server – единой платформе для построения цикла разработки ПО. В этой главе также можно найти информацию о

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

Более подробно архитектура TFS и его основные компоненты рассмотрены в Главе 2 «Архитектура Team Foundation Server»

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

На рис. 1.1 показан процесс коллективной разработки ПО с использованием TFS и взаимосвязь сред разработки и тестирования.

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

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

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

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

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

пользователями. После этого они поступают на сервер производственной эксплуатации.

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



   

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

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

    

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

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

2

Check-in – регистрация изменений в системе хранения исходного кода. Локальные изменения отправляются в хранилище и становятся доступными остальным пользователям системы.

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

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

   

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

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

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

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

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

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

Дополнительные источники 



Более подробно об основах TFS смотрите в статье «Team Foundation Server Fundamentals: A Look at the Capabilities and Architecture» (Основы Team Foundation Server: взгляд на возможности и архитектуру) по адресу http://msdn2.microsoft.com/en-us/library/ms364062(vs.80).aspx. Обзор Team Foundation представлен в технической документации на Веб-сайте Microsoft MSDN® по адресу http://msdn2.microsoft.com/enus/library/ms181232(vs.80).aspx.

Глава 2 – Архитектура Team Foundation Server Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Описать архитектуру Microsoft® Visual Studio® Team System (VSTS) и Team Foundation Server (TFS). Определить компоненты, образующие клиентский уровень, уровень приложений и уровень данных. Обозначить различия между развертыванием на одном сервере и развертыванием на нескольких серверах.

Обзор В данной главе представлена архитектура TFS и основные схемы развертывания. TFS логически представлен трехуровневой архитектурой, которая включает клиентский уровень, уровень приложений и уровень данных. Клиенты TFS взаимодействуют с уровнем приложений посредством различных Веб-сервисов, а уровень приложений использует различные базы данных Microsoft SQL Server™ уровня данных.

Уровни приложений и данных физически могут располагаться как на одном сервере, так и на разных серверах. Выбор, главным образом, зависит от размера группы, работающей над проектом. Для групп менее 50 человек лучше использовать один сервер. Достаточно мощный сервер может обслуживать до 400 пользователей. Развертывание на двух серверах позволяет обслуживать около 2000 пользователей.

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

Те, кто еще не знаком с TFS, должны сначала прочитать Главу 1 «Введение в среду для коллективной разработки», в которой описывается взаимодействие групп разработки и тестирования с TFS и использование TFS для повышения качества этого взаимодействия и общей эффективности производства ПО.

Архитектура Team Foundation Server TFS использует трехуровневую архитектуру, которая включает клиентский уровень, уровень приложений и уровень данных. Клиенты TFS взаимодействуют с уровнем приложений посредством различных Веб-сервисов; уровень приложений, в свою

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

Рис. 2.1 Компоненты и уровни TFS

Клиентский уровень Клиентский уровень включает следующие компоненты:

  



Объектная модель Team Foundation Server. Это открытый API, используемый для взаимодействия с TFS. Объектная модель может использоваться для создания клиентских приложений, взаимодействующих с TFS. Компоненты Visual Studio Industry Partners (VSIP). Это инструментальные средства, надстройки и языки программирования сторонних производителей для Visual Studio. Интеграция с Microsoft Office. Включает ряд надстроек Microsoft Office Excel® и Microsoft Office Project, которые обеспечивают возможность запрашивать и обновлять рабочие элементы в базе данных TFS Work Item Tracking. Особенно полезна для руководителей проектов, которые уже активно используют эти приложения. Инструментальные средства командной строки. Это инструментальные средства, обеспечивающие возможность взаимодействия с TFS из командной строки. Преимущественное большинство этих инструментов предоставляют



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

Уровень приложений Уровень приложений предоставляет Веб-сервисы ASP.NET, с которыми взаимодействует клиентский уровень. Эти Веб-сервисы не предназначены для использования в сторонних приложениях, но приведены здесь для полноты картины. Веб-сервисы сгруппированы в следующие наборы:

 

Сервисы обработки данных TFS (Team Foundation Data Services) Сервисы интегрирования TFS (Team Foundation Integration Services)

Сервисы обработки данных TFS Эти Веб-сервисы преимущественно обеспечивают взаимодействие с уровнем данных. К этим сервисам относятся:   

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

Сервисы интегрирования TFS Данный набор Веб-сервисов обеспечивает функциональность интегрирования и автоматизации. Эти сервисы не взаимодействуют с уровнем данных. К сервисам интегрирования TFS относятся:







Веб-сервис регистрации. Этот сервис используется для регистрации других сервисов TFS. Он обслуживает информацию регистрационной базы данных. Эта информация используется сервисами для определения способа взаимодействия друг с другом. Веб-сервис безопасности. Этот сервис состоит из Сервиса групповой безопасности (Group Security Service) и Сервиса авторизации (Authorization Service). Сервис групповой безопасности используется для управления всеми пользователями и группами TFS. Сервис авторизации предоставляет TFS систему управления доступом. Веб-сервис связывания. Этот сервис обеспечивает возможность устанавливать отношения слабой связи (или просто «связи») между элементами данных





инструментальных средств1. Например, соответствие между рабочим элементом (например, дефектом), и исходным кодом, который был изменен с целью исправления этого дефекта, устанавливается в TFS при помощи связи. Веб-сервис обработки событий. Этот сервис обеспечивает возможность инструментальному средству или сервису регистрировать типы событий. Пользователи могут подписываться на эти события и получать уведомления по электронной почте или посредством вызова Веб-сервиса. Например, событие регистрации изменений может использоваться для запуска процесса непрерывной интеграции. Веб-сервис классификации. Этот сервис совместно с Веб-сервисом связывания обеспечивает классификацию артефактов TFS соответственно установленным систематикам. Это обеспечивает возможность поддерживать создание перекрестных2 отчетов даже для артефактов, не использующих общую систематику для организации своих данных. Например, если обычно рабочие элементы группируются по проектным группам, а тесты – по компонентам, то с помощью классификации можно организовать тесты по проектным группам, так они смогут быть включены в тот же отчет, что и рабочие элементы.

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

   

Отслеживание рабочих элементов. Здесь хранятся все данные, касающиеся рабочих элементов. Контроль версий. Здесь хранятся все данные, касающиеся контроля версий. Сборка. Содержит всю информацию, касающуюся инструмента TFS Team Build. Хранилище отчетов. Хранит информацию, касающуюся всех инструментов и функций TFS. Хранилище отчетов упрощает создание отчетов, сочетающих в себе данные нескольких инструментальных средств.

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

Основные требования Независимо от выбранной схемы развертывания: 

1

Уровни приложений и данных должны быть установлены в одном домене, хотя могут располагаться как на одном, так и на разных серверах.

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

    

  

На серверах, на которых развертывается TFS, должен быть установлен Microsoft Windows Server™ 2003 с Service Pack 1 (SP1) или его более поздняя версия. Все Веб-сервисы уровня приложений TFS должны быть установлены на одном сервере. Один экземпляр TFS физически должен быть установлен на одном компьютере. На один физический сервер нельзя устанавливать более одного экземпляра TFS. Нельзя распределять базы данных TFS по нескольким серверам баз данных. Все проекты должны находиться в одной группе серверов Team Foundation Server и не могут развертываться в нескольких группах (т.е. проект не может использовать уровень приложений одного экземпляра TFS и уровень данных другого экземпляра TFS). Для размещения сайта портала проекта нельзя использовать существующую инфраструктуру Microsoft SharePoint® Portal Server. Порталы TFS должны размещаться на выделенном сервере1. Не следует устанавливать TFS на сервер, сконфигурированный как контроллер домена – такой сценарий установки не поддерживается. При развертывании на двух серверах необходимо подготовить доменные учетные записи, которые будут использоваться при запуске сервисов TFS. Например, учетные записи могут быть такими: DOMAIN\TFSSERVICE и DOMAIN\TFSREPORTS.

Развертывание на одном сервере Развертывание на одном сервере – самая простая схема. Она подходит для групп разработки, в которых участвуют до 400 пользователей, или пилотных проектов. В этом случае все компоненты уровня приложений и уровня данных устанавливаются на один сервер и доступ к ним осуществляется из одного домена.

Средства тестирования производительности можно установить на сервере или на одном и более клиентах. На рис. 2.2 показана схема развертывания на одном сервере.

1

В TFS 2008 это ограничение снято (прим. научного редактора)

Рис. 2.2 Схема развертывания на одном сервере

Развертывание на двух серверах Схема развертывания на двух серверах используется для больших групп разработки с количеством пользователей до 2000. В этом случае уровень приложений и уровень данных размещаются на разных серверах.

Сервисы сборки TFS можно установить на сервере уровня приложений, но для больших групп рекомендуется настроить один или более специальных серверов сборки. Если в проекте предусмотрено тестирование производительности, средства тестирования (контроллер и агенты) можно развернуть на дополнительных серверах. На рис. 2.3 показана схема развертывания на двух серверах.

Рис. 2.3 Схема развертывания на двух серверах

Заключение Архитектура Team Foundation Server включает три уровня: клиентский уровень, уровень приложений и уровень данных.

  

Клиентский уровень содержит клиентские компоненты, такие как Team Explorer, компоненты для интеграции с Microsoft Office и инструменты командной строки. Уровень приложений содержит такие компоненты, как сервисы контроля версий Team Foundation, сервисы для отслеживания рабочих элементов и сервисы сборки. Уровень данных содержит базы данных для хранения данных, необходимых для отслеживания рабочих элементов, контроля версий, сборок проектов и создания отчетов.

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

Дополнительные источники 

 

Более подробную информацию об основах Team Foundation можно найти в статье «Team Foundation Server Fundamentals: A Look at the Capabilities and Architecture» по адресу http://msdn2.microsoft.com/enus/library/ms364062(vs.80).aspx. Обзор Team Foundation можно найти в технической документации Team Foundation на сайте Microsoft MSDN® по адресу http://msdn2.microsoft.com/enus/library/ms181232(vs.80).aspx. Более подробно о масштабировании Team Foundation Server рассказывается в статье «Team Foundation Server Capacity Planning» (Планирование серверных мощностей для Team Foundation Server) по адресу http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx, а также http://blogs.msdn.com/bharry/archive/2007/10/18/tfs-2008-systemrecommendations.aspx и http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx.

Часть II Система контроля версий исходного кода В данной части:    

Структурирование проектов и решений в системе контроля версий Структурирование проектов и решений в системе контроля версий Team Foundation Server Выбор стратегии ветвления и слияния Управление зависимостями системы контроля версий в Visual Studio Team System

Глава 3 – Структурирование проектов и решений в системе контроля версий Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Структурировать решения и проекты Microsoft® Visual Studio® Team System. Выяснить, когда необходимо использовать несколько решений и когда – одно решение. Определить структуры, подходящие для небольших, средних и больших групп.

Обзор В данной главе описываются различные варианты структурирования файлов решений и проектов Visual Studio, подходящие для коллективной разработки. Для группировки взаимосвязанных файлов проектов (.csproj и .vbproj) Visual Studio использует файлы решений (.sln). Выбор структуры проектов и решений очень важен, поскольку имеет ряд последствий. Например, он влияет на то, насколько легко члены групп разработки смогут извлекать и размещать решения и проекты в системе контроля версий, на механизм, используемый для описания зависимостей, а также на процессы сборки.

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

Как использовать данную главу Данная глава поможет выбрать подход к структурированию решений и проектов Visual Studio. Чтобы извлечь максимальную пользу из этой главы, необходимо:   

Использовать список стратегий. Чтобы быстро выбрать наилучший подход для своего сценария, используйте одну из следующих стратегий: одно решение, сегментированное решение и несколько решений. Прочитать раздел сценария, наиболее отвечающий вашим нуждам. Прочитайте раздел, описывающий, как следует реализовывать выбранный вариант. Прочитать Главу 4, «Структурирование проектов и решений в системе контроля версий Team Foundation Server». Глава 4 представляет важные моменты, о которых следует помнить при размещении кода в системе контроля версий Team Foundation Server (TFS).

 

Прочитать Главу 6, «Управление зависимостями системы контроля версий в Visual Studio Team System». Структура проекта оказывает влияние на стратегии, доступные при управлении зависимостями между проектами и решениями. Прочитать сопроводительные статьи раздела «Как: ...». Прочитайте следующие сопроводительные статьи «Как: ...», в которых представлен пошаговый разбор различных обсуждаемых в данной главе методик. o Как: структурировать приложения ASP.NET в Visual Studio Team Foundation Server. o Как: структурировать приложения Windows в Visual Studio Team Foundation Server. o Как: структурировать каталоги системы контроля версий Visual Studio Team Foundation Server.

Стратегии структурирования решений и проектов Чаще всего используются три стратегии структурирования файлов решений и проектов:

 



Одиночное решение. При разработке небольшой системы, создается одиночное решение, в котором размещаются все проекты. Сегментированное решение. При разработке большой системы взаимосвязанные проекты группируются в разные решения. Для каждой логической группы проектов, с которой разработчик, вероятнее всего, будет работать как с совокупностью, создается отдельное решение. Затем все эти решения объединяются в одно главное решение, которое будет содержать все проекты. При таком подходе сокращается количество данных, извлекаемых из системы контроля версий, поскольку работа ведется только над определенными проектами. Несколько решений. При создании очень большой системы, требующей десятков и более проектов, следует работать с подсистемами. Для отображения зависимостей и из соображений производительности не нужно создавать главное решение, содержащее все проекты.

В общем, следует:   

Использовать стратегию одиночного решения, если размер получаемого в результате решения не слишком велик и не приводит к проблемам загрузки в Visual Studio. Использовать несколько решений для создания отдельных представлений подсистем приложения. Использовать несколько решений для сокращения времени загрузки решения и сокращения времени сборки для разработчиков.

При разработке структуры проектов и решений следует иметь в виду следующее:



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

 



из этого, принимайте решение о необходимых проектах. На основании этого распределите код по проектам. Начинайте с самой простой структуры одиночного решения. Усложняйте структуру только в том случае, когда это действительно необходимо. При проектировании структуры с множеством решений: o Рассмотрите зависимости проекта. Попытайтесь сгруппировать взаимосвязанные проекты в одно решение. Это позволит использовать в решении ссылки на проекты, а не на файлы, что обеспечивает возможность Visual Studio синхронизировать конфигурации сборки (отладка/ версия для выпуска) и, отслеживая версии, определять, когда необходимо повторно собрать проект. Пытайтесь свести к минимуму количество перекрестных ссылок на проекты между решениями. o Рассмотрите возможность совместного использования исходного кода. Поместите проекты, использующие один и тот же исходный код, в одно решение. o Учтите структуру группы. Решения должны быть структурированы таким образом, чтобы упростить группам работу с набором взаимосвязанных проектов. Придерживайтесь плоской структуры проекта. Это облегчит задачу по группировке проектов в решения без необходимости внесения изменений в структуру каталогов или папку системы контроля версий.

Одиночное решение При работе над небольшой системой рекомендуется размещать все проекты в одном решении Visual Studio. Такая структура упрощает разработку, потому что при открытии решения доступен весь исходный код. При такой стратегии также очень легко работать со ссылками, потому что все они являются ссылками на проекты одного решения. Но все-таки, возможно, придется использовать ссылки на файлы сборок сторонних производителей, например на купленные компоненты, находящиеся вне решения. На рис. 3.1. показан подход с использованием одиночного решения.

Рис. 3.1 Подход с использованием одиночного решения

Главными причинами выбора данной структуры являются:  

Простые сценарии сборки. В рамках решения можно без труда отображать зависимости между проектами.

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

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

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

Примечание: В отличие от предыдущих версий, Visual Studio 2005 полагается в сборке проектов на MSBuild. Начиная с Visual Studio 2005, появилась возможность создавать структуры решений, не включающие в себя все проекты, на которые имеются ссылки, и такие решения все равно будут собираться без ошибок. Поскольку главное решение собирается первым, формируя результирующие двоичные файлы каждого проекта, MSBuild может прослеживать ссылки на проекты вне границ решения и успешно выполнять сборку. Но это возможно только в случае использования ссылок на проекты, а не ссылок на файлы. Созданные таким образом решения можно успешно собирать из командной строки Visual Studio и из IDE, но не с помощью Team Build. Чтобы успешно создать сборку с помощью Team Build, необходимо использовать главное решение, включающее все проекты и зависимости.

На рис. 3.2 показан подход с использованием сегментированного решения.

Рис. 3.2 Подход с использованием сегментированного решения

При работе с несколькими решениями все проекты должны иметь плоскую структуру. Типичный пример – приложение, включающее проект Microsoft Windows® Forms, проект ASP.NET, службу Windows и ряд библиотек классов, которые совместно используются некоторыми или всеми перечисленными проектами.

Для всех проектов может использоваться следующая плоская структура: /Source /WinFormsProject /WebProject /WindowsServiceProject

/ClassLibrary1 /ClassLibrary2 /ClassLibrary3 Web.sln Service.sln All.sln

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

Основания использования этой структуры:     

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

Основная причина не использовать эту структуру: 

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

Несколько решений При работе над очень большим решением, включающим десятки проектов, может возникнуть проблема с масштабируемостью решения. При таком сценарии следует разбить приложение на несколько решений, но при этом не создавать главного решения для всего приложения, потому что все ссылки внутри решений являются ссылками на проекты. Ссылки на проекты вне решений (например, на библиотеки сторонних производителей или проекты из другого составляющего решения) – это ссылки на файлы, т.е. без «главного» решения можно обойтись.

Вместо главного решения необходимо использовать сценарий, который понимает порядок сборки решений. Одна из главных задач при обслуживании структуры с несколькими решениями – гарантировать невозможность создания циклических ссылок между решениями. Эта структура требует сложных сценариев сборки и явного отображения зависимостей. При такой структуре невозможно создать сборку всего приложения в Visual Studio. Это делается непосредственно из TFS Team Build или MSBuild.

На рис. 3.3 показан подход с использованием нескольких решений.

Рис. 3.3 Подход с использованием нескольких решений

Такая структура должна использоваться для очень больших приложений. Она поможет решить проблемы с производительностью и масштабируемостью Visual Studio IDE.

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

Рекомендации по работе над большим проектом Большим группам разработки, в отличие от малых, присущи следующие черты:

  

Им нужна более сложная структура ветвления и слияния. Для них более высока вероятность работы с зависимостями между решениями и групповыми проектами. Для них более высока вероятность работы с несколькими сценариями сборки для компонентов и групп.

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

Заключение Для небольших проектов, в которых не требуется разделять исходный код на отдельные составляющие решения, используется одиночное решение.

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

Для создания определенных представлений подсистем и сокращения времени загрузки и сборки приложения используется несколько решений.

Сегментированное решение отлично подходит для большинства больших проектов, потому что обеспечивает гибкость решения и при этом предоставляет одно решение, которое может использоваться для сборки приложения.

Дополнительные источники 

Больше информации о структуре проектов и решений (хотя это не применимо напрямую к Team Foundation Server) можно найти в статье «Team Development with Visual Studio .NET and Visual SourceSafe» (Коллективная разработка с

использованием Visual Studio .NET и Visual SourceSafe) по адресу http://msdn2.microsoft.com/en-us/library/ms998208.aspx.

Глава 4 – Структурирование проектов и решений в системе контроля версий Team Foundation Server Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи      

Структурировать проекты для эффективной коллективной разработки в системе контроля версий Microsoft® Visual Studio® Team Foundation Server (TFS). Обеспечить синхронизацию файловой структуры на стороне сервера и на стороне клиента. Выбрать стратегию структурирования тестов. Создать структуру каталогов, поддерживающую различные сценарии ветвления. Изучить понятие рабочего пространства и отображение им локальных файлов в системе контроля версий. Понять, какие файлы добавляются в систему контроля версий.

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

Эта глава начинается с объяснения того, как должны быть структурированы решения и проекты на компьютере разработчика (на стороне клиента) и как необходимо структурировать каталоги в системе контроля версий TFS (на стороне сервера). Представлены примеры структур каталогов для различных типов приложений, включая Microsoft Windows® Forms, смарт-клиенты и Веб-приложения. Кроме того, в главе рассматривается использование рабочих пространств для отображения структур каталогов клиента и сервера.

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

Использовать предложения по созданию структуры каталогов на стороне сервера. Для организации исходного кода проекта в системе контроля версий TFS используйте предложенные структуры каталогов на стороне сервера.





Использовать предложения по созданию структуры каталогов на стороне клиента. Для организации исходного кода проекта в локальном рабочем пространстве используйте предложенные структуры каталогов на стороне клиента. Прочитать сопроводительные статьи «Как: …». В этих статьях представлен пошаговый разбор некоторых обсуждаемых в данной главе процессов: o Как: Создать собственное дерево каталогов исходного кода в Team Foundation Server. o Как: Структурировать приложения ASP.NET в Team Foundation Server. o Как: Структурировать приложения Windows в Team Foundation Server. o Как: Структурировать каталоги системы контроля версий в Team Foundation Server.

Структура на стороне сервера Большинство разрабатываемых группой проектов включают одно или более решений Visual Studio, каждое из которых, в свою очередь, включает один или более проектов Visual Studio. При организации изолированных ветвей разработки проекты Visual Studio группируются в корневую папку Main (как на стороне клиента, так и на стороне сервера). Ниже представлен пример структуры каталогов в системе контроля версий TFS:

$MyTeamProject1  Может содержать файлы решений (.sln)

/Main /Source

 Содержит файл MyApp1.sln

/MyApp1

 Папка-контейнер всего исходного кода

/Source /ClassLibrary1

 Содержит ClassLibrary1.csproj

/MyApp1Web

 Содержит Default.aspx  Папка-контейнер всех модульных тестов

/UnitTests /ClassLibrary1Tests

 Содержит проект тестирования и исходный код тестов

/MyApp1WebTests

 Содержит проект тестрования и исходный код тестов

/SharedBinaries

 Совместно используемые двоичные файлы, например,

/SharedSource

 Совместно используемый исходный код

библиотеки

/Docs

 Содержит документацию продукта

/Tests

 Контейнер тестов /FunctionalTests /PerformanceTests /SecurityTests

 Создается автоматически Team Build

/TeamBuildTypes /BuildType1 /BuildType2

Main – это папка-контейнер исходных файлов и других артефактов, таких как результат сборки, проектная документация и сценарии тестирования. Папка приложения (как MyApp1 в предыдущем примере) содержит файл решения Visual Studio (.sln), используемый для группировки множества взаимосвязанных проектов Visual Studio. Каждый файл проекта (.vcproj или .vbproj) размещается в специальной папке проекта, находящейся внутри папки /Main/Source/MyApp1/Source. Модульные тесты, сопровождающие каждый проект, располагаются в папке UnitTests (Модульные тесты). В папку Main можно поместить и другие файлы решений Visual Studio (.sln), что позволит работать с разными вариантами группировки проектов.

Папки Docs и Test используются для размещения дополнительных артефактов, включая документацию по продукту и автоматизированные тесты.

Папка TeamBuildTypes (Типы сценариев сборки) создается автоматически при настройке первого типа сценария сборки. Чтобы вручную зарегистрировать тип сценария сборки, можно создать эту папку самостоятельно, добавить в нее свои файлы Team Build, и TFS распознает эту папку автоматически.

Более подробно о группировке проектов и структуре решения рассказывается в Главе 3 «Структурирование проектов и решений в системе контроля версий».

Хранение модульных тестов Модульные тесты можно сохранять в папке UnitTests и располагать ее на одном уровне с папкой Source, как показано ниже. …  Содержит файл MyApp1.sln

/MyApp1

 Папка-контейнер всего исходного кода

/Source /ClassLibrary1

 Содержит ClassLibrary1.csproj

/MyApp1Web

 Содержит Default.aspx  Папка-контейнер модульных тестов

/UnitTests /ClassLibrary1Tests

 Содержит проект тестирования и исходный код тестов

/MyApp1WebTests

 Содержит проект тестирования и исходный код тестов

При таком сценарии модульные тесты выносятся отдельно от всего исходного кода. Однако происходит это за счет совместимости на уровне проектов. Вот альтернативная структура:

/MyApp1 /Source /ClassLibrary1 /ClassLibrary1Tests /MyApp1Web /MyApp1WebTests

За и против каждого из подходов:

UnitTests на одном уровне с папкой Source     

За: Все модульные тесты находятся в одном месте. За: Поставляемый код располагается отдельно от кода, который поставляться не будет. За: Процесс сборки может без труда выполнить все модульные тесты во всех проектах. Против: Разработчикам сложнее выполнять модульное тестирование только для своего проекта. Против: Модульные тесты не включаются в ответвления папки Source.

UnitTests в каждом проекте    

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

Хранение документации Папка Documentation (Документация) предназначена для хранения документации проекта. Чтобы определиться с тем, где хранить те или иные документы (в системе контроля версий TFS или на сайте портала проекта Microsoft Windows SharePoint®), учитываем следующее:

 

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

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

Следует быть осторожными при использовании SharePoint, поскольку в этом случае требуется жесткий контроль версий документа. В SharePoint проще перезаписать изменения по сравнению с системой контроля версий TFS. По умолчанию SharePoint при закачивании файлов включает опцию «overwrite existing file» (перезаписать существующий файл).

Структура на стороне клиента Локальная структура каталогов на рабочих станциях разработчиков должна быть идентична структуре каталогов на стороне сервера. Артефакты исходного кода на рабочих станциях должны быть хорошо организованы: исходные файлы всех проектов группы должны размещаться в одной корневой папке, например, C:\DevProjects. Для каждого проекта группы создается отдельная подпапка, как показано в данном примере:

C:\DevProjects

 Корневая папка-контейнер для всех проектов группы

\MyTeamProject1

 Папка-контейнер для TeamProject1

\MyTeamProject2

 Папка-контейнер для TeamProject2

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

\MyTeamProject1

 Папка-контейнер для TeamProject1  Содержит файлы .sln, объединяющие проекты

\Main \Source

 Содержит MyApp1.sln

\MyApp 1 \Source \ClassLibrary1

 Содержит ClassLibrary1.csproj

\MyApp1Web

 Содержит Default.aspx  Содержит проекты и исходный код модульных тестов

\UnitTests \ClassLibrary1Tests \MyWinApp1Tests \SharedBinaries \SharedSource

 Совместно используемые двоичные файлы, например, библиотеки  Совместно используемый исходный код

\Docs

 Содержит документацию продукта

\Tests

 Контейнер тестов \FunctionalTests \PerformanceTests \SecurityTests

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

Ветвление папок Изолированность разработки обеспечивается ветвлением. Для этого на одном уровне с папкой Main создаются дополнительные папки. Также, чтобы обеспечить разработчикам возможность работать с различными вариантами группировки проектов, в папке Main можно разместить дополнительные файлы решений Visual Studio (.sln). Ветви, созданные от папок исходного кода Main, могут использоваться для продолжения обслуживания выпущенных версий продукта или поддержки параллельных потоков разработки.

В следующем примере структуры каталогов для обеспечения изолированности по функциональности или по группам, кроме корневой папки Main, используется папка Development (Разработка) (ответвление Main). Папка Releases (Выпускаемые версии), являющаяся контейнером веток версий, готовых к выпуску (опять же, ответвление Main), обеспечивает изолированность выпускаемых сборок, текущую версию которых необходимо фиксировать, но которые необходимо продолжать обслуживать.

$MyTeamProject1 /Development /FeatureBranch1 /Source /MyApp /FeatureBranch2 /Source /MyApp /Main /Source /Releases /Release1 – Обслуживание /Source /MyApp /Release2 – Обслуживание /Source /MyApp /Release3 – Фиксированная текущая версия, готовая к выпуску /Source /MyApp

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

Более подробно о группировке проектов и структуре решений рассказывается в Главе 3 «Структурирование проектов и решений в системе контроля версий».

Более подробно сценарии ветвления и соответствующие им структуры каталогов рассматриваются в Главе 5 «Выбор стратегии ветвления и слияния».

Что такое рабочее пространство Рабочее пространство TFS – это копия файлов и папок системы контроля версий TFS на стороне клиента. Рабочее пространство проецирует папки системы контроля версий в каталоги локальной файловой системы. Изменения, вносимые в файлы в рабочем пространстве на локальном компьютере, называют локальными или ожидающими регистрации изменениями (pending changes). Они остаются изолированными в рамках рабочего пространства до тех пор, пока не будут зарегистрированы на сервере как единое целое. Совокупный набор изменений, регистрируемый пакетом, называют пакетом изменений (changeset).

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

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

Создание нового отображения рабочего пространства Отображения рекурсивны, поэтому при создании нового отображения рабочего пространства и выполнении операции Get Latest Version (Получить последнюю версию) в корне этого рабочего пространства, вся локальная структура каталогов создается автоматически. Вновь созданная локальная структура каталогов полностью соответствует структуре каталогов сервера.

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

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

спроецировать корневую папку проекта группы в соответствующую локальную папку, например, C:\DevProjects\TeamProject1.

Где хранятся отображения рабочего пространства? Информация рабочего пространства сохраняется как на клиенте, так и на сервере. На стороне клиента информация рабочего пространства находится в файле VersionControl.config, располагающемся в следующей папке: \Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache.

Файл VersionControl.config проецирует имя рабочего пространства в локальный каталог на компьютере разработчика. Он не содержит информации о соответствии между отдельными папками системы контроля версий и локальными каталогами. Эта информация хранится на сервере в нескольких таблицах (включая tbl_Workspace и tbl_workingfolder) базы данных TfsVersionControl.

Сокрытие Если требуется предотвратить возможность извлечения какой-либо части дерева каталогов системы контроля версий для оптимизации производительности, можно использовать сокрытие. Вот типичные сценарии сокрытия:  

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

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

При сокрытии необходимо учитывать следующие рекомендации:  

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

Для каких файлов необходимо выполнять контроль версий? В следующем списке перечислены основные типы файлов, которые должны быть включены в систему контроля версий. Эти типы файлов добавляются по выбору пункта меню Add Solution to Source Control (Добавить решение в систему контроля версий).

  



Файлы решений (*.sln). В файлах решений хранится список входящих в них проектов, информация о зависимостях, детали конфигурации сборки и информация о провайдере системы контроля версий. Файлы проектов (*.csproj или *.vbproj). Файлы проектов включают настройки процесса сборки, используемые сборки (имя и путь) и перечисление входящих в проект файлов. Метаданные проекта системы контроля версий Visual Studio (*.vspscc). В этих файлах хранятся связи проекта, списки файлов, не находящихся под версионным контролем, имена провайдеров системы контроля версий и другие метаданные системы контроля версий. Конфигурационные файлы приложения (*.config). Конфигурационные файлы XML содержат характерные детали проекта и приложения, которые используются для управления поведением приложения во время выполнения. Веб-приложения используют файлы Web.config. Не Веб-приложения используют файлы App.config.

Примечание: Во время выполнения система сборки Visual Studio копирует App.config в папку Bin проекта и переименовывает его в .exe.config. Для не веб-приложений не происходит автоматического добавления конфигурационных файлов в новый проект. Если такой файл необходим, следует добавить его вручную. Он должен называться App.config и располагаться в папке проекта.

 

Исходные файлы (*.aspx, *.asmx, *.cs, *.vb, …). Это файлы исходного кода. Какие именно это файлы, зависит от типа приложения и используемого языка программирования. Используемые двоичные файлы (*.dll). Если проект использует двоичные файлы, такие как динамически подключаемые библиотеки (dynamic-link libraries, DLLs) сторонних производителей, они также должны быть добавлены в проект в системе контроля версий. Более подробно об управлении зависимостями рассказывается в Главе 6 «Управление зависимостями системы контроля версий в Visual Studio Team System».

Для каких файлов не требуется контроль версий? Следующие файлы для каждого разработчика свои и поэтому не должны добавляться в систему контроля версий:  



Файлы решения с пользовательскими опциями (*.suo). В данных файлах хранятся персональные настройки IDE Visual Studio отдельного разработчика. Файлы проекта с пользовательскими опциями (*.csproj.user или *.vbproj.user). В данных файлах хранятся опции проекта отдельного разработчика и локальный путь (необязательно), используемый Visual Studio для установления местоположения указанных в ссылках сборок. Файлы WebInfo (*.csproj.webinfo или *.vbproj.webinfo). Этот файл хранит информацию о местоположении корневой виртуальной папки проекта. Он не вводится в систему контроля версий для того, чтобы каждый разработчик мог задавать свою виртуальную корневую папку для собственной рабочей копии



проекта. Несмотря на существование такой возможности, при разработке Вебприложений всем членам группы рекомендуется использовать один (локальный) виртуальный корневой каталог. Результаты сборки. Сюда входят DLL сборки, вспомогательные сборки для взаимодействия с COM-компонентами и исполняемые файлы (EXE). (Однако, обратите внимание, что такие сборки, как двоичные файлы сторонних производителей, которые собираются отдельно, не как часть процесса сборки, подлежат контролю версий, как описывалось выше).

Заключение Для эффективной коллективной разработки проекты в системе контроля версий TFS должны быть структурированы. Проекты Visual Studio группируются в корневой папке Main. Папка Main должна иметь дочерние папки для хранения различных ресурсов проекта, таких как исходный код, тесты, документы и типы сценариев сборки.

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

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

Дополнительные источники 



Более подробно о системе контроля версий Team Foundation смотрите в статье «Using Source Code Control in Team Foundation» (Использование системы контроля версий в Team Foundation) по адресу http://msdn2.microsoft.com/enus/library/ms364074(VS.80).aspx. Более подробно и создании рабочего пространства смотрите в статье «How to: Create a Workspace» (Как: создать рабочее пространство) по адресу http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx.

Глава 5 – Выбор стратегии ветвления и слияния Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи    

Разобраться, когда следует и когда не следует прибегать к ветвлению. Выбрать стратегию ветвления и слияния для своего проекта. Описать, как адаптировать обычную стратегию ветвления для использования в очень больших группах. Определить структуры каталогов, подходящие для различных сценариев ветвления.

Обзор Данная глава описывает стратегии ветвления и слияния для ряда типовых сценариев. Обычно ветви используются для поддержания версий, готовых к выпуску, или параллельной разработки.

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

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

В данной главе предлагается обзор ветвления и слияния: в ней приведены различные стратегии ветвления и показаны сценарии, когда применение ветвления уместно. Если вас интересует конкретный сценарий, переходите прямо к соответствующему разделу. Чтобы извлечь максимальную пользу из этой главы, следует: 

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



Использовать сопроводительное руководство. Руководствуйтесь рекомендациями по ветвлению и слиянию, приведенными в разделе «Рекомендации по работе с системой контроля версий» данного руководства.

Сценарии ветвления и слияния Далее приведены сценарии, в которых может понадобиться создавать ветви и выполнять слияния:

 

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

Не следует использовать ветвление, если в нем нет крайней необходимости. Ветвление требует дополнительного обслуживания каталога исходного кода и выполнения задач по слиянию. Для большинства групп разработки, которые занимаются созданием бизнес-приложений и имеют короткие циклы выпуска новых версий, ветвления не требуется. Группам разработки, реализующим более длинные циклы выпуска, таким как Независимые производители ПО (Independent Software Vendors, ISV), которые создают «коробочные» приложения, скорее всего, придется прибегнуть к ветвлению в своем процессе разработки.

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

Типовые сценарии на практике Рассмотрим типовые сценарии ветвления:





Сценарий 1 – Нет ветвления. Группа работает только с основным деревом исходного кода. В данном случае ветви не создаются, и в изоляции нет необходимости. Такой сценарий обычно подходит для небольших или средних групп, где не требуется изоляция по группам или по функциональным возможностям и не нужно изолировать версии, готовые к выпуску. Сценарий 2 – Ветвление для выпуска версии. Группа создает ветви для поддержки выпускаемой версии. Это второй наиболее распространенный случай, когда ветвление используется для стабилизации выпускаемой версии. В данном случае группа создает ветвь перед выпуском версии, чтобы







стабилизировать ее, и затем, после выпуска версии ПО, вносит изменения из ветви выпущенной версии в основную ветвь исходного кода. Сценарий 3 – Ветвление для обслуживания. Группа создает ветвь для сохранения старой сборки. В данном случае ветвь создается с целью обслуживания, чтобы не дестабилизировать сборки, находящиеся в производственной эксплуатации в настоящее время. Изменения этой ветви могут, как переноситься, так и не переноситься в основное дерево. Например, для некоторой группы пользователей может создаваться решение для быстрого исправления дефекта, которое не требуется включать в основную сборку. Сценарий 4 – Ветвление для разработки функциональной возможности. Группа создает ветви на основании имеющихся функциональных возможностей. В данном случае создается ветвь разработки, все работы ведутся в ней и затем все выполненные изменения переносятся в основную ветвь исходного кода. Создание отдельных ветвей для функциональных возможностей позволяет работать над ними параллельно. Сценарий 5 – Ветвление для изоляции группы. Ветви создаются с целью изоляции подгрупп, чтобы обеспечить им возможность работы без конфликтов, порождаемых несовместимыми между собой изменениями в исходном коде, или чтобы они могли работать параллельно и выполнять синхронизацию по завершении собственных этапов, характерных для этой группы.

В своей работе разработчик может столкнуться с одним и более сценариев. Их следует использовать как эталон для определения возможности применения той или иной рекомендации в конкретном случае.

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



 

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

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

Сценарий 1 – Нет ветвления Данный сценарий обычно применяется в небольших группах, для которых не стоит вопрос о необходимости изолированной разработки. Используя маркировку сборок метками, можно извлекать соответствующий исходный код. Во введении сложного ветвления нет необходимости, потому что работать можно непосредственно из папки Main. Вот представление сценария без ветвления:

My Team Project Main Source

Сценарий 2 – Ветвление для выпуска версии В этом сценарии группа создает ветвь для стабилизации версии и, после выпуска версии ПО, объединяет ветвь этой версии с основным деревом исходного кода:

My Team Project  Главная ветвь интеграции

Main Source Releases Release 1

 Ветвь выпускаемой версии

Source

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

My Team Project Main Source

 Главная ветвь интеграции

Контейнер ветви обслуживания

Releases

Ветвь обслуживания

Release 1 Source Other Asset Folders

 Ветвь обслуживания

Release 2 Source Other Asset Folders

Сценарий 4 – Ветвление для разработки функциональной возможности В данном сценарии создается ветвь разработки, выполняется некоторая работа в этой ветви, и затем она объединяется с основным деревом исходного кода. Организовываются ветви разработки, исходя из функциональных возможностей продукта. Ниже приведено физическое представление ветвления для разработки функциональной возможности:

My Team Project  Контейнер ветви изолированной разработки

Development Feature A

 Ветвь функциональной возможности

Source Feature B

 Ветвь функциональной возможности

Source Feature C

 Ветвь функциональной возможности

Source  Главная ветвь интеграции

Main Source

Сценарий 5 – Ветвление для изоляции группы Данный сценарий аналогичен предыдущему с ветвлением по функциональности, за исключением того, что ветви организовываются по подгруппам разработчиков, а не по функциональным возможностям. Возможно соответствие один-к-одному между группой и функциональной возможностью, но в некоторых случаях одна группа может

заниматься несколькими функциями. Ниже показано физическое представление ветвления по подгруппам:

My Team Project  Контейнер ветви изолированной разработки

Development

 Ветвь группы

Team 1 Feature A

 Изолированная ветвь для разработки

Source Feature B

 Изолированная ветвь для разработки

Source  Ветвь группы

Team 2 Feature A

 Изолированная ветвь для разработки

Source Feature B

 Изолированная ветвь для разработки

Source  Главная ветвь интеграции

Main Source

Логическая структура Логическая структура представляет отношение родитель/потомок для каждой ветви. Она может отличаться от физической структуры, отображаемой в Source Control Explorer. Например, в представленной выше физической структуре кажется, что Development и Main равнозначны, тогда как на самом деле Development является дочерней папкой Main.

На рис. 5.1 показан пример логической структуры и потока ветвлений и слияний в ней.

Рис. 5.1 Логическое отношение, представляющее поток ветвления и слияния

Сценарий выпуска версии продукта На рис. 5.2 показана типовая временная диаграмма ветвления для выпуска версии продукта:

Рис. 5.2 Временная диаграмма ветвления для выпуска версии

Последовательность событий: 1. Ветвь Release 1 создается из Main, как только реализована вся предполагаемая для данной версии функциональность. 2. Ветвь Release 1 периодически сливается с Main, что гарантирует перенос исправлений дефектов из выпускаемой версии в основную интегрирующую ветвь. 3. Сборка выпускаемой версии маркируется меткой в ветви версии для тиражирования (RTM), изменения вносятся в Main. 4. Выходит пакет обновлений, SP1. Сборка маркируется, и изменения вносятся в Main. 5. Ветвь Release 1 продолжает существование для поддержки SP1 и для обеспечения возможности создания новых пакетов обновлений.

Этот процесс повторяется для будущих версий продукта.

Примечание: При внесении исправлений в ветви версий важно определиться, в какую ветвь должно быть внесено это исправление, прежде чем реализовывать его. Если исправление выпускается как исправление в уже выпущенной версии (hotfix) или пакет обновлений, то сначала вносятся изменения в соответствующую ветвь Release (Выпускаемая версия), а затем эти изменения вносятся в Main, чтобы гарантировать их присутствие в будущих версиях.

Сценарий изолированной разработки На рис. 5.3 показана типовая временная диаграмма ветвления для изолирования разработки.

Рис. 5.3 Временная диаграмма ветвления для изолирования разработки

Последовательность событий:

1. Создается ветвь для изолированной разработки Функциональной возможности А. 2. Создается ветвь для изолированной разработки Функциональной возможности B. 3. Каждая группа по завершении определенного этапа работ переносит свои изменения в Main, что обеспечивает возможность их интегрирования в основную сборку и использования другими группами. 4. С заданной периодичностью каждая группа переносит последние изменения из Main с целью синхронизации с работой остальных групп и для сокращения количества конфликтов при последующих слияниях. 5. По завершении работы над функциональной возможностью все изменения переносятся в Main, и ветвь функциональной возможности уничтожается.

Вопросы ветвления При ветвлении необходимо руководствоваться следующими рекомендациями:



Прибегать к ветвлению следует только в случае, если группа разработки должна работать с одним набором файлов параллельно с другой группой. В







  



противном случае, сборку можно маркировать меткой и создать ветвь от нее позднее. Слияние ветвей может быть сложным и требовать много времени, особенно если внесены существенные изменения. Ветви должны быть структурированы таким образом, чтобы слияние приходилось производить лишь вдоль по иерархии (вверх или вниз по ветви), а не поперек иерархии. Ветвление поперек иерархии требует использования слияния без общей родительской версии, при котором большинство конфликтов приходится разрешать вручную. В основе иерархии ветвей лежат ветвь-родитель и ветвь-потомок, и эта иерархия может отличаться от физической структуры исходного кода на диске. При планировании слияний необходимо руководствоваться логической структурой ветвления, а не физической структурой каталога исходного кода на диске. Не следует создавать слишком разветвленные структуры, поскольку тогда на внесение изменений в основную ветвь исходного кода и на разрешение конфликтов уходит слишком много времени. Сильно разветвленная структура может означать, что распространение изменений, выполненных в дочерней ветви, на основную ветвь исходного кода может занять очень большой период времени. Это, как правило, имеет негативное влияние на сроки выполнения проекта и увеличивает время, необходимое для исправления дефектов. Ветвление следует выполнять на высоком уровне и включать конфигурационные и исходные файлы. Развивать структуру ветвления следует постепенно. Для выполнения слияния и разрешения конфликтов требуется один или более разработчиков. После слияния исходный код должен быть тщательно протестирован, потому что очень часто неверные решения при слиянии приводят к дестабилизации сборки. Слияние поперек иерархии ветвей представляет особую сложность. При таком слиянии многие конфликты, которые могли бы обрабатываться автоматически, приходится обрабатывать вручную.

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

Рекомендации по работе над большим проектом Большим группам разработки с длительными циклами разработки присущи следующие черты:

  

Им нужна более сложная структура ветвления и слияния. Для них более высока вероятность работы с зависимостями между решениями и групповыми проектами. Для них более высока вероятность работы с несколькими сценариями сборки для компонентов и групп.

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

Например, при определении схемы слияния (будет ли она выполняться по графику или управляться событиями) необходимо учесть следующее  

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

Необходимо найти компромисс между стратегией ветвления/слияния и предполагаемой частотой выполнения сборок. Более глубокая структура ветвления означает большее время интегрирования кода дочерних ветвей в главную ветвь исходного кода. Признаками неверного выбора стратегии ветвления являются:

  

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

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

Вот пример сложной структуры ветвления:



My Team Project o Development – Контейнер для изолирования активных ветвей разработки  Feature A – Изолированная ветвь разработки  Source  Feature B – Изолированная ветвь разработки  Source o Main – Главная ветвь интеграции и сборки. Все изменения сводятся воедино здесь.

o

o

 Source  Other Asset Folders Releases – Контейнер для ветвей текущей версии и обслуживания  Release 2– Активная ветвь обслуживания  Source  Other Asset Folders  Release 3 – Активная ветвь обслуживания  Source  Other Asset Folders  Release 4 – Ветвь, содержащая код, находящийся на этапе подготовки к выпуску, внесение неконтролируемых изменений в который запрещено  Source  Other Asset Folders Safe Keeping  Release 1 – Ветвь архивного хранения старой версии  Source  Other Asset Folders

Данная структура включает:

    

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

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

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

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

Дополнительные источники    

Основы ветвления и слияния можно найти в статье «Branching and Merging Primer» (Ветвление и слияние для начинающих) по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx. Более подробно о ветвлении смотрите в статье «How to: Branch Files and Folders» (Как: Ветвление каталогов) по адресу http://msdn2.microsoft.com/enus/library/ms181425(VS.80).aspx. Более подробно о слиянии смотрите в статье «How to: Merge Files and Folders» (Как: Слияние каталогов) по адресу http://msdn2.microsoft.com/enus/library/ms181428(VS.80).aspx. Дополнительное описание принципов ветвления и слияния в Visual Studio 2005 приведено в статье «Branching and Merging Team Foundation Source Control» (Ветвление и слияние в системе контроля версий Team Foundation) по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Глава 6 – Управление зависимостями системы контроля версий в Visual Studio Team System Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи      

Управлять зависимостями внутри и между решениями VSTS. Использовать проекты и сборки из других решений в том же групповом проекте. Использовать проекты и сборки из других групповых проектов. Использовать сборки сторонних производителей. Управлять ссылками на Веб-сервисы в среде коллективной разработки. Управлять ссылками на базы данных в среде коллективной разработки.

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

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

Как использовать данную главу Данная глава рассказывает об управлении зависимостями в среде коллективной разработки. Ее можно прочитать от начала и до конца или ознакомиться лишь с разделом, рассматривающим конкретный вопрос управления зависимостями. Раздел «Сценарии и решения» поможет понять, какие вообще сценарии управления зависимостями существуют в среде коллективной разработки. Этот раздел является трамплином для перехода к следующим разделам, подробно рассматривающим каждый из сценариев.

 

Раздел «Использование проектов» рассказывает о том, как работать со ссылками на другие проекты, как внутренними, так и внешними по отношению к текущему групповому проекту. Раздел «Использование сборок сторонних производителей» рассказывает, как работать со ссылками на сборки сторонних производителей, исходным кодом которых вы не располагаете.

 

Раздел «Использование Веб-сервисов» рассказывает, как работать со ссылками на совместно используемые Веб-сервисы в среде коллективной разработки. Раздел «Использование баз данных» рассказывает, как соединяться с базами данных и использовать их в среде коллективной разработки.

Сценарии и решения Обычно реализуются следующие сценарии управления зависимостями:

6. 7. 8. 9.

Используется сборка, сформированная другим проектом в том же решении. Используется сборка, сформированная другим проектом в другом решении. Используется сборка из другого группового проекта. Используется сборка стороннего производителя.

Использование сборок, сформированных другим проектом в том же решении Если требуется включить сборку из этого же решения Visual Studio, используется ссылка на проект Visual Studio. В случае применения ссылок на проекты Visual Studio может автоматически выполнять некоторые действия, например, обеспечивать синхронизацию конфигурации сборки (отладка/версия для выпуска), отслеживать версии и повторно выполнять сборку компонентов при изменении версий сборок.

Использование сборок, сформированных проектами других решений Существует два варианта использования сборки, сформированной проектом в другом решении Visual Studio:

 

Использовать ссылку на двоичный файл сборки. Добавить проект Visual Studio (файлы проектов и исходные файлы) в решение и затем использовать ссылку на проект.

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

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

Использование сборки из другого группового проекта При совместном использовании исходного кода или двоичных файлов в групповых проектах возможны два варианта:





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

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

При ветвлении возникают дополнительные издержки на слияние, они влияют на решение, использовать ли обновления в виде бинарных файлов или в виде исходного кода.

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

Использование проектов Например, имеется групповой проект Visual Studio, содержащий совместно используемый несколькими групповыми проектами код библиотеки. Можно сохранять проект в рамках исходного группового проекта или создать отдельный групповой проект специально для совместно используемого проекта.

Для второго варианта, когда создается общий совместно используемый проект, структура каталогов системы контроля версий Microsoft Visual Studio Team Foundation Server (TFS) следующая (рис. 6.1).

Рис. 6.1 Структура каталогов при общем совместно используемом проекте

Существует два варианта совместного использования проекта из собственного группового проекта

 

Ветвление Отображение рабочего пространства

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

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

Например, имеется два групповых проекта, $TeamProject1 и $Common, и Common содержит совместно используемый исходный код. Тогда в проекте, использующем

Common, создается ответвление совместно используемого каталога. Получаем следующую структуру каталогов TFS (рис. 6.2).

Рис. 6.2 Использование ветвления

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

Папка в системе контроля версий

Локальная папка

$/MyTeamProject1/Main/Source/

C:\MyTeamProject1\Main\Source

Структура каталогов рабочего пространства на стороне клиента должна быть следующей (рис. 6.3).

Рис. 6.3 Отображение рабочего пространства на стороне клиента

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

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

Например, имеется два групповых проекта, $MyTeamProject2 и $Common, и Common содержит совместно используемый исходный код. Чтобы использовать общий код, эти проекты отображены в одну и ту же структуру каталогов на жестком диске клиента. Структура каталогов рабочего пространства на стороне клиента должна быть следующей (рис. 6.4).

Рис. 6.4 Использование отображения рабочего пространства

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

Папка в системе контроля версий

Локальная папка

$/MyTeamProject2/Main/Source/

C:\DevProjects\MyTeamProject2\Main\Source\

$/Common

C:\DevProjects\MyTeamProject2\Main\Source\ Common

Более подробно читайте в статье «Working with multiple team projects in Team Build» (Как работать с несколькими групповыми проектами в Team Build) по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.

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

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

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

 

Ветвление Отображение рабочего пространства

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

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

Например, имеется два групповых проекта, $TeamProject1 и $Common, и Common содержит совместно используемые двоичные файлы. В проекте, использующем эти файлы, создается ветвь от совместно используемого каталога. Структура каталогов TFS представлена на рис. 6.5.

Рис. 6.5 Ветвление от Common

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

Папка в системе контроля версий Локальная папка $/MyTeamProject1/Main

C:\MyTeamProject1\Main

Структура каталогов рабочего пространства на стороне клиента представлена на рис. 6.6.

Рис. 6.6 Структура каталогов рабочего пространства на стороне клиента

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

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

Например, имеются два групповых проекта, $TeamProject2 и $Common, и TeamProject2 использует двоичные файлы, доступные в Common. Тогда структура каталогов рабочего пространства на стороне клиента должна быть следующей (рис. 6.7).

Рис. 6.7 Хранение совместно используемых библиотек

Отображения рабочего пространства должны быть такими:

Папка в системе контроля версий

Локальная папка

$/MyTeamProject2/Main/

C:\DevProjects\MyTeamProject2\Main\

$/Common/Main/Bin

C:\DevProjects\MyTeamProject2\Main\Source\CommonBin

Подробнее об этом рассказывает статья «Working with multiple team projects in Team Build» по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.

Рекомендации по использованию проектов и сборок Задать ссылку на файл можно двумя способами:

 

Чтобы сослаться на сборку .NET Framework, необходимо выбрать ее из списка, отображаемого на вкладке .NET диалогового окна Add References (добавить ссылки). Используйте кнопку Browse (Просмотр) диалогового окна Add Reference.

Сборки, такие как System.XML.dll, располагаются в Глобальном кэше сборок (Global Assembly Cache, GAC). Однако мы никогда не ссылаемся на сборку в GAC напрямую. При выборе сборки на вкладке .NET диалогового окна Add References на самом деле происходит ссылка на копию сборки, находящуюся в папке %windir%\Microsoft.NET\Framework\\.

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

  

Везде, где это возможно, использовать ссылки на проекты. Использовать ссылки на файлы только по необходимости. Для ссылок на проекты и файлы использовать Copy Local = True.

Более подробная информация представлена в разделе «Рекомендации по работе с системой контроля версий» данного руководства.

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

Использование Веб-сервисов В более простых системах, в которых все проекты системы располагаются в одном групповом проекте, все разработчики, в конце концов, работают с локальными рабочими копиями всех Веб-сервисов, потому что они определены проектами Visual

Studio в групповом проекте. Все проекты (включая все Веб-сервисы) устанавливаются локально при первом открытии решения из системы контроля версий. Аналогично, если Веб-сервис добавляется в решение одним из разработчиков, у всех остальных он устанавливается при следующем обновлении. При таком сценарии нет необходимости публиковать Веб-сервисы на центральном Веб-сервере среды коллективной разработки.

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

Более подробно об этом рассказывается в разделах «Рекомендации по работе с системой контроля версий» и «Практики работы с системой контроля версий» данного руководства.

Использование динамических URL для ссылки на Веб-сервисы Если требуется вызвать Веб-сервис, необходимо сначала добавить в проект Веб-ссылку. При этом создается прокси-класс, посредством которого осуществляется взаимодействие с Веб-сервисом. Код прокси-класса изначально содержит статический Универсальный указатель ресурса (Uniform Resource Locator, URL) Веб-сервиса, например, http://localhost или http://SomeWebServer.

Важно: Для Веб-сервисов текущего решения, которое выполняется на вашем компьютере, должен использоваться только http://localhost, а не http://MyComputerName. Это гарантирует, что ссылка останется достоверной на всех компьютерах.

Обычно в прокси-классе используется статический URL. В среде производственной эксплуатации или тестирования, как правило, необходим другой URL. Существует три варианта решения этой проблемы:

 

Можно задавать URL Веб-сервиса программно при создании экземпляра прокси-класса. Более гибкий подход без жесткого кодирования URL в прокси-классе – задать свойству URL Behavior (Поведение URL) ссылки на Веб-сервис значение Dynamic (Динамический). Такой подход является предпочтительным. Когда этому свойству задается значение Dynamic, в прокси-класс добавляется код для



извлечения URL Веб-сервиса из специальной секции конфигурационного файла приложения (Web.config для Веб-приложения или SomeApp.exe.config для приложения Windows). Также можно создать прокси-класс с помощью инструмента командной строки WSDL.exe, задавая ключ /urlkey. При этом подобно заданию значения свойства URL Behavior, в прокси добавляется код для извлечения URL Веб-сервиса, только в этом случае URL хранится в секции конфигурационного файла приложения.

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

Как использовать динамические URL и пользовательский конфигурационный файл Чтобы добиться максимальной гибкости конфигурации, как в среде разработки, так и в среде производственной эксплуатации, свойству URL Behavior ссылки на Веб-сервис должно быть задано значение Dynamic. При добавлении Веб-ссылки Visual Studio по умолчанию присваивает этому свойству значение Dynamic. Чтобы проверить значение данного свойства:

1. В Solution Explorer разверните список Веб-ссылок. 2. Пройдитесь по всем Веб-ссылкам списка. 3. Для каждой Веб-ссылки проверьте значение свойства URL Behavior (оно должно быть Dynamic).

Чтобы задать URL Веб-сервиса в пользовательском конфигурационном файле:

1. Когда Веб-ссылка задается впервые, Visual Studio автоматически создает файл App.config, в котором содержится ссылка на Веб-сервис. Настройки конфигурации в файле App.config выглядят следующим образом: http://localhost/someservice/Service.asmx



В данном файле имеется новая секция конфигурации, которую использует созданный прокси-класс. В данной секции располагается адрес Веб-сервиса, обнаруженный Visual Studio при формировании этого прокси-класса.

Также Visual Studio помещает в код, сформированный для этого прокси, значение URL по умолчанию. Это значение находится в файле Settings.Designer.cs. Чтобы увидеть этот файл: 1. В Solution Explorer щелкните Веб-сервис правой кнопкой мыши. 2. Выберите View in Object Browser (Просмотр в браузере объектов). В Object Browser найдите запись YourProject.Properties, где YourProject – имя проекта, содержащего ссылку на Веб-сервис. 3. Разверните YourProject.Properties и щелкните двойным щелчком Settings (Настройки). При этом откроется файл Settings.Designer.cs, содержащий подобную строку: [global::System.Configuration.DefaultSettingValueAttribute("http://localhost:/w ebservice/Service.asmx")]

Это значение по умолчанию, используемое как URL Веб-сервиса, если не найдена информация о конфигурации.

Часто возникает необходимость изменить URL вызываемого Веб-сервиса. Например, требуется протестировать приложение с использованием Веб-сервиса, выполняемого локально на компьютере разработчика, или версии Веб-сервиса, выполняющейся в среде тестирования. Также очень часто URL Веб-сервиса производственной эксплуатации отличается от URL, используемого при разработке. Поэтому значение URL должно быть задано в пользовательском конфигурационном файле, на который будет ссылаться основной файл App.config. Имя пользовательского конфигурационного файла выбирается произвольно. В следующем примере используется имя User.config, чтобы было ясно, что это файл с конфигурацией пользователя.

Этапы создания файла User.config: 1. В Solution Explorer щелкните правой кнопкой мыши проект, содержащий ссылку на Веб-сервис, выберите Add и затем щелкните New Item (Новый элемент). 2. Выберите Application Configuration File (Конфигурационный файл приложения), измените имя на User.config и щелкните Add. 3. Скопируйте настройки элемента из конфигурационного файла приложения (App.config) в файл User.config. Этот файл должен содержать только элемент, который выносится из основного

конфигурационного файла приложения. Удалите директиву и элемент , если они присутствуют, как показано в следующем примере http://localhost/someservice/Service.asmx

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

1. Добавьте атрибут configSource="user.config" в элемент главного конфигурационного файла приложения. Тем самым, получив информацию из этой секции, среда выполнения будет перенаправлена в указанный пользовательский конфигурационный файл. 2. Удалите содержимое элемента .

Теперь App.config должен выглядеть следующим образом:



В предыдущем примере YourProject – имя проекта, содержащего ссылку на Веб-сервис.

Важно: Если используется атрибут configSource, пользовательский конфигурационный файл должен присутствовать и содержать всего один элемент, . Также необходимо гарантированно удалить XMLсодержимое элемента при добавлении атрибута configSource=”user.config”.

При использовании User.config:







Убедитесь, что развертывание файла User.config происходит вместе с кодом приложения. Для этого в Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите опцию Properties и задайте свойству Copy To Output Directory (Копировать в выходной каталог) значение Copy if newer (Копировать, если это более свежая версия). Не добавляйте свой файл User.config в систему контроля версий. Так каждый разработчик и группа тестирования могут явно привязываться к определенным URL, используя собственные файлы User.config. В системе контроля версий могут располагаться другие файлы User.config, например, используемые для тестирования и производственной эксплуатации. Эти файлы должны обслуживаться пользователями, ответственными за управление средами тестирования и производственной эксплуатации. Файлы User.config для тестирования и производственной эксплуатации не должны храниться как часть проектов Веб-сервиса, они должны располагаться в других областях системы контроля версий. Храните глобальный файл User.config в системе контроля версий. Он может содержать только корневой элемент (без элемента ) или может определять местоположение Веб-сервиса по умолчанию. Наличие файла User.config обеспечивает возможность работы системы конфигурации.

Подсказка: По умолчанию пользовательский конфигурационный файл автоматически добавляется в систему контроля версий при добавлении решения. Чтобы предотвратить это, при первой регистрации изменений в файле необходимо убрать флажок напротив файла User.config. После этого можно щелкнуть правой кнопкой мыши файл в Solution Explorer и выбрать опцию Undo Pending Changes (Отменить ожидающие регистрации изменения). Тогда файл гарантированно не будет подлежать контролю версий.

Важно: Если в файле User.config, задающем URL, имеется только корневой элемент, и нет элемента настроек, прокси-класс Веб-сервиса использует URL по умолчанию, который указан в файле Settings.Designer.cs. Это значение определено как атрибут DefaultValueSettings (Значения по умолчанию) и выглядит следующим образом

[global::System.Configuration.DefaultSettingValueAttribute("http://localhost/webservic e/Service.asmx")]

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

значения, необходимо добавить атрибут restartOnExternalChanges="false" (перезапустить при внешних изменений) в описание секции конфигурационного файла, как это сделано ниже:



Если этот атрибут добавлен в секцию конфигурации файла Web.config, изменения внешнего конфигурационного файла User.config не приводят к автоматическому перезапуску Веб-приложения. Однако эти изменения по-прежнему отражаются в приложении.

Важно понимать, что если используется данный механизм, файл User.config должен присутствовать обязательно. Кто-то должен отвечать за обеспечение соответствия среды требованиям при создании сборок для производственной эксплуатации и для сред тестирования. В ходе сборки соответствующий файл User.confg должен быть получен из системы контроля версий и скопирован в соответствующий каталог, чтобы MSBuild мог найти его.

Использование баз данных Ссылки на базы данных в виде строк соединения также могут быть организованы посредством внешнего конфигурационного файла. Преимущество такого подхода в том, что любой разработчик может без труда задать собственную строку соединения в личном файле User.config. Любые изменения, вносимые одним из разработчиков, например переадресация соединения в локальную базу данных в целях тестирования модулей, не оказывают никакого влияния на других разработчиков.

Пользовательский конфигурационный файл также может использоваться для управления настройками конкретной среды, например настройками среды тестирования. Среда тестирования также может использовать файл User.config, который ссылается на тестовую базу данных.

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

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

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

Чтобы использовать конфигурационный файл пользователя для хранения строк соединения с базой данных:

1. Добавьте атрибут configSource="user.config" в элемент главного конфигурационного файла приложения.

2. Чтобы переопределить главный конфигурационный файл приложения, создайте файл User.config (расположив его в той же папке, что и конфигурационный файл приложения) и затем добавьте такую же запись в этот файл. Обратите внимание на то, что следующая строка соединения ссылается на локальную базу данных.

3. В своем проекте применяйте следующий код для получения строки соединения из пользовательского конфигурационного файла. using System.Configuration; private string GetDBaseConnectionString() { return ConfigurationManager.ConnectionStrings["DBConnStr"].ConnectionString; }

В этом коде используется статическое свойство ConnectionStrings (Строки соединения) класса System.Configuration.ConfigurationManager. В приложениях WinForm необходимо добавить явную ссылку на System.Configuration.dll. 4. Убедитесь, что файл User.config разворачивается вместе с кодом приложения. Для этого в Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите Properties и затем в окне Properties задайте свойству Copy To Output Directory значение Copy if newer.

Не добавляйте файл User.config в систему контроля версий. Так каждый разработчик и группа тестирования смогут явно задавать строку соединения через собственный файл User.config. В системе контроля версий могут располагаться другие файлы User.config, например, используемые для тестирования и производственной эксплуатации. Эти

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

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

Замечание: По умолчанию пользовательский конфигурационный файл автоматически добавляется в систему контроля версий при добавлении решения. Чтобы предотвратить это, при первой регистрации изменений в файле необходимо убрать флажок напротив файла User.config. После этого можно щелкнуть правой кнопкой мыши файл в Solution Explorer и выбрать опцию Undo Pending Changes. Тогда файл гарантированно не будет подлежать контролю версий.

Важно понимать, что если используется данный механизм, файл User.config должен присутствовать обязательно. Кто-то должен отвечать за обеспечение соответствия среды требованиям при создании сборок для производственной эксплуатации и для сред тестирования. В ходе сборки соответствующий файл User.confg должен быть получен из системы контроля версий и скопирован в соответствующий каталог, чтобы MSBuild мог найти его.

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

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

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

Дополнительные источники   

Более подробно о ссылках на проекты рассказывает статья «Project References» (Ссылки на проекты) по адресу http://msdn2.microsoft.com/enus/library/ez524kew(VS.80).aspx. Более подробная информация о ветвлении представлена в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/enus/library/ms181425(VS.80).aspx. Более подробная информация о рабочих пространствах представлена в статье «Working with Source Control Workspaces» (Работа с рабочими пространствами системы контроля версий) по адресу http://msdn2.microsoft.com/enus/library/ms181383(VS.80).aspx.

Часть III Сборки В данной части:   

Team Build Как настроить процесс непрерывной интеграции с помощью Team Build Настройка плановых сборок в Team Build

Глава 7 – Team Build Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи     

Понять архитектуру Microsoft® Visual Studio® Team System Team Build. Изучить компоненты, составляющие Team Build. Понять функциональные возможности, предоставляемые Team Build. Правильно выбрать стратегию сборки. Определить, каким образом может понадобиться изменить стратегию выполнения сборки при работе над большим проектом

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

Team Build создан на базе Microsoft Build Engine (MSBuild) и может быть использован для извлечения необходимого для сборки исходного кода, компиляции решений и, если требуется, выполнения модульного тестирования и статического анализа кода как части процесса сборки. Также результат сборки может быть опубликован в заданный совместно используемый каталог.

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

Как использовать данную главу Данная глава рассказывает о функциональности, предоставляемой Team Build для автоматизации и управления процессом сборки. Она научит понимать разные стратегии планирования сборки. Чтобы извлечь максимальную пользу из этой главы, следует:

  

Прочитать Главу 8 «Как настроить процесс непрерывной интеграции с помощью Team Build», чтобы больше узнать об использовании непрерывной интеграции с Team Foundation Server (TFS). Прочитать Главу 9 «Как настроить плановые сборки с помощью Team Build», чтобы больше узнать об использовании плановых сборок. Прочитать сопроводительные статьи «Как…», чтобы разобраться, как выполнять задачи, связанные с проведением сборки: o Как: с помощью Team Build автоматически выполнять анализ кода в Visual Studio Team Foundation Server. o Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server. o Как: настроить плановую сборку в Visual Studio Team Foundation Server.

Архитектура В данном разделе представлена архитектура Team Build через описание его физической архитектуры и логической последовательности операций.

Физическая архитектура Физическая архитектура Team Build включает следующие компоненты:

      

Мастер создания нового типа сценария сборки – Этот доступный из Team Explorer компонент на стороне клиента обеспечивает возможность создания новых типов сценариев сборок. Окно просмотра Team Build – Этот доступный из Team Explorer компонент на стороне клиента обеспечивает возможность просмотра в Team Explorer сообщения Team Build и информации о процессе сборки. Веб-сервис системы контроля версий – Этот компонент уровня приложений используется сервисом сборки для доступа к исходному коду. Веб-сервис сборки Team Foundation – Этот компонент уровня приложений принимает запросы от клиента и управляет выполнением этапов сборки. Сервис сборки – Этот сервис выполняет этапы сборки в ответ на инструкции, получаемые от Веб-сервиса Team Build. Сервис сборки можно разместить на отдельном сервере сборки или на сервере уровня приложений. Хранилище сборок Team Foundation – Этот компонент уровня данных используется для хранения записей, относящихся к процессам Team Build. База данных исходного кода – Этот компонент уровня данных используется для хранения исходного кода, к которому обращается сервис сборки во время сборки.

Логическая последовательность операций На рис. 7.1 показана логическая последовательность операций Team Build.

Рис. 7.1 Логическая последовательность операций Team Build

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

Файл TFSBuild.proj управляет процессом сборки, включая выбор проектов, участвующих в сборке, выбор конфигураций, мест публикации результатов сборки, анализ кода и выбор тестов, которые должны быть проведены. Этот файл формируется Team Build Type Creation Wizard (Мастер создания нового типа сценария сборки) при первом создании сборки и может редактироваться напрямую.

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

Ключевые моменты При работе с Team Build необходимо помнить следующие ключевые моменты его физической архитектуры:

 

Team Foundation Build является надстройкой над MSBuild. Файл TFSBuild.proj содержит все настройки сборки. Он создается с помощью мастера Team Build Type Creation Wizard. После создания файл можно редактировать напрямую.

 



Файл TFSBuild.rsp содержит параметры командной строки для MSBuild. Изменяя этот файл, можно осуществлять более тонкую настройку процесса сборки. Система уведомлений о событиях посредством событий BuildStatusChangeEvent (Событие изменения статуса сборки) и BuildCompletionEvent (Событие завершения сборки) делает возможной реализацию специальных этапов процесса сборки или формирование уведомлений. Team Build интегрируется с рабочими элементами, инструментарием анализа покрытия кода тестами и статического анализа кода и сценариями тестирования.

Как работает Team Build Team Build состоит из Сервиса Team Build, работающего поверх системы сборки MSBuild. MSBuild отвечает за сам процесс сборки, тогда как Сервис Team Build обеспечивает обмен информацией с уровнем приложений TFS. Типы сценариев сборки создаются из клиента Visual Studio, и запускать их можно с клиентского компьютера по событию сервера сборки или из командной строки, например, как плановую задачу. Запущенный процесс сборки включает следующие этапы:

10. 11. 12. 13. 14. 15. 16. 17.

Получение исходных файлов из системы контроля версий в каталог сборки. Компиляция исходного кода и получение двоичных файлов. Анализ кода (необязательный). Создание рабочего элемента в случае сбоя процесса сборки. Тестирование (необязательный). Оценка покрытия кода тестами (необязательный). Протоколирование деталей процесса сборки. Копирование сборки в место публикации результатов сборки.

После завершения сборки доступны следующие элементы и данные:

   

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

Как выбрать стратегию сборки При выборе стратегии сборки руководствуйтесь следующей схемой: 1. Продумайте, для кого создается сборка.

2. Посмотрите сценарии решения. 3. Определитесь с основными этапами.

Для кого создается сборка Потребителями сборок в большинстве случаев являются:

    

Группа разработки Группа тестирования Внутренние потребители сборок Внешние потребители сборок Заказчики

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

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

Сценарии сборки Рассмотрим самые распространенные сценарии Team Build:

 

Однократная ежедневная сборка. Большинство групп используют плановые сборки, чтобы регулярно обеспечивать двоичными файлами группу тестирования и других пользователей. Ежедневные сборки и сборки в процессе непрерывной интеграции. Некоторые группы предпочитают использовать процесс непрерывной интеграции, чтобы обеспечить своим разработчикам быструю обратную связь при каждом событии регистрации изменений. Непрерывная интеграция хороша для небольших групп, а вот сервер сборки большой группы, вероятнее всего, будет перегружен из-за высокой частоты формирования событий регистрации изменений и более длительного времени сборки. Когда такое происходит,



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

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

Чаще всего потребителями плановой сборки являются:

  

Группа тестирования. Внутренние потребители сборки. Внешние потребители.

Создание плановой сборки происходит в два этапа:

1. Создание командного файла с командной строкой сборки. 2. Командный файл выполняется по графику с помощью Windows Scheduled Tasks (Планировщик задач Windows).

Более подробно об этом рассказывается в Главе 9, «Как настроить плановые сборки с помощью Team Build».

Сборка в результате непрерывной интеграции Сборка в результате непрерывной интеграции запускается в результате каждого события регистрации изменений. Назначение непрерывной интеграции – как можно быстрее после события регистрации изменений обеспечить обратную связь о качестве

сборки. Обычно потребителями сборок в результате непрерывной интеграции являются группы разработки.

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

1. Сборка в результате непрерывной интеграции сразу после формирования события регистрации изменений. 2. Скользящая сборка после заданного числа событий регистрации изменений или через заданный промежуток времени (в зависимости от того, какое условие выполняется первым).

Более подробно об этом рассказывается в Главе 8, «Как настроить процесс непрерывной интеграции с помощью Team Build».

Регистрация изменений с порогом качества Регистрация изменений с порогом качества – это процесс проверки каждого изменения на соответствие некоторому стандарту качества перед добавлением его в дерево исходного кода. Назначение регистрации изменений с порогом качества – сокращение числа сбоев при сборке и повышение качества сборки. Это достигается путем обязательного тестирования каждого изменения перед его приемом.

Наиболее часто встречающиеся препятствия Существует несколько часто встречающихся сценариев, которые по умолчанию не поддерживаются в полной мере Team Build. Ознакомьтесь со следующими сценариями и подумайте, с какими из них может столкнуться ваша группа разработки: 



Сборка проекта с внешними зависимостями. Если для установления внешних зависимостей в групповом проекте используется ветвление, можно использовать ссылки на проекты, и сборка будет выполняться на сервере сборки без каких-либо дополнительных шагов. Если внешние зависимости реализованы через отображение рабочего пространства на стороне клиента, для успешной сборки необходимо обслуживать отображение на сервере сборки. Более подробно об этом рассказывается в Главе 6 «Управление зависимостями системы контроля версий в Visual Studio Team System». Сборка проекта создания пакета установки приложения. Team Build не поддерживает проекты создания пакета установки приложения по умолчанию. Проект создания пакета установки компилируется после сборки, и полученные в результате этого специального этапа двоичные файлы копируются в каталог публикации результатов сборки. Более подробную информацию об этом можно найти в статье «Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project» (По шагам: Конфигурирование Team Foundation Build для сборки проекта создания пакета установки Visual Studio) по адресу http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx.





Сборка приложений .NET 1.1. Team Build не поддерживает приложения .NET 1.1 по умолчанию. Дополнение MSBuild – Комплект инструментов для .NET 1.1 (MSBee) – поддерживает сборки .NET 1.1, но требует, чтобы проекты и решения были обновлены до Visual Studio 2005. Если это невозможно, скомпилировать приложения .NET 1.1 можно в ходе специального этапа после сборки. Скачать MSBee можно по адресу http://www.codeplex.com/MSBee. Более подробно о создании специального этапа сборки для компиляции приложений .NET 1.1 рассказывается в блоге Нагараджу (Nagaraju) (http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx) или в статье «Microsoft SDC DevEnv task» (http://www.codeplex.com/sdctasks). Сборка приложений Microsoft Visual Basic® 6.0. Team Build не поддерживает приложения Visual Basic 6.0 по умолчанию. Компиляция приложения Visual Basic 6.0 выполняется в ходе специального этапа после сборки. Примеры компиляции после сборки, которые могут использоваться для компиляции приложений .NET 1.1, ищите в блоге Нагараджу (http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx) или в статье «MSBuild task to build VB6» (Задача MSBuild для сборки VB6) (http://freetodev.spaces.live.com/blog/cns!EC3C8F2028D842D5!261.entry).

Рекомендации по работе над большим проектом При работе в большой группе разработки необходимо учитывать дополнительные факторы. Отличие больших групп разработки от меньших обычно заключается в следующем:

  

Им нужна более сложная структура ветвления и слияния. Для них более высока вероятность работы с зависимостями между решениями и групповыми проектами. Для них более высока вероятность работы с несколькими сценариями сборки для компонентов и групп.

При работе с большими группами разработки необходимо помнить следующее:

  

Скорее всего время сборки для больших групп будет большим. Частота сборок в результате непрерывной интеграции должна быть меньшей, чем время сборки, во избежание организации очереди и загрузки сервера сборки. Если группа использует ветвление, можно настроить сервер сборки для каждой ветви. Это позволит ориентировать каждую сборку на цели ветви, например, интеграцию или разработку. Для ветвей интеграции, вероятнее всего, будут выполняться лишь плановые сборки. Ветви разработки могут использовать сборки в результате непрерывной интеграции и плановые сборки.

Настройка сборки Редактируя файл TFSBuild.proj, можно изменять информацию о сборке, такую как сервер сборки, место размещения результатов сборки или каталог сборки.

Файл TFSBuild.proj содержит большую часть информации, необходимой для выполнения сценария сборки. Эти данные включают местоположения размещения сборки и то, должны ли проводиться в процессе сборки статический анализ кода и модульное тестирование. Для изменения процесса сборки редактируется файл TFSBuild.proj. Для редактирования этого файла:

1. Файл изымается из системы контроля версий для редактирования. 2. В файле обновляется информация о сборке. 3. Файл помещается обратно в систему контроля версий, и изменения вступают в силу.

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

Более подробную информацию о настройке процесса сборки можно найти в разделе «Настройка» частей «Рекомендации по выполнению процесса сборки» и «Практики сборки» данного руководства.

Заключение Team Build создан на базе MSBuild. Он интегрируется с TFS через уровень приложений и взаимодействует с рабочими элементами, инструментарием анализа покрытия кода тестами и статического анализа кода, сценариями тестирования и системой создания и отображения отчетов.

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

Дополнительные источники 

Более подробно о Team Build рассказывает статья «Overview of Team Foundation Build» (Обзор Team Foundation Build), которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms181710(vs.80).aspx.

Глава 8 – Как настроить процесс непрерывной интеграции с помощью Team Build Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Понять назначение процесса непрерывной интеграции. Настроить процесс непрерывной интеграции, используя Microsoft® Visual Studio® Team System Team Build. Оптимизировать процесс непрерывной интеграции и сократить количество «узких мест» в нем.

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

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

Как использовать данную главу В этой главе мы изучим стратегии непрерывной интеграции и научимся, используя Team Build, настраивать и конфигурировать процессы сборки, получаемые в процессе непрерывной интеграции. Пошаговый обзор и анализ процесса настройки непрерывной интеграции приведен в разделе «Как: настроить процесс непрерывной интеграции в Visual Studio Team Foundation Server».

Новичкам в TFS и Team Build и тем, кто желает подробнее рассмотреть доступные варианты автоматизации и планирования сборок, рекомендуется прочитать Главу 7 «Team Build».

Стратегии сборки в результате непрерывной интеграции Непрерывная интеграция (Continuous integration, CI) – это процесс создания сборок при каждой регистрации изменений кода в системе контроля версий. Существует несколько различных стратегий сборки в результате непрерывной интеграции:

   

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

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

  

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

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

Более подробно об этом рассказывается в разделе «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server».

Скользящая сборка после определенного количества регистраций изменений Если сервер сборки перегружен в результате выполнения сборок после каждой регистрации изменений, можно прибегнуть к стратегии сборки после определенного количества регистраций. Это самый простой пример скользящей сборки и у него есть один очень существенный недостаток. Поскольку сервер сборки, прежде чем начать

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

Скользящая сборка через определенный промежуток времени Создание сборки по прошествии заданного интервала времени после каждой регистрации изменений является более совершенным подходом, чем создание сборок после определенного количества регистраций. Этот подход гарантирует создание сборки в заданный период времени после каждой регистрации. Необходимо помнить, что в этом случае каждая сборка ассоциируется с разным числом регистраций изменений: некоторые сборки могут включать только одно изменение, тогда как другие – намного больше. Чем больше изменений вошло в сборку, тем сложнее определить, какое из них привело к сбою сборки.

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

Определение интервала скользящей сборки Чтобы определить идеальный интервал скользящей сборки, следует разделить среднюю частоту регистраций изменений на продолжительность выполнения сборки. Например, если сборка занимает 10 минут и изменения регистрируются в среднем каждые 5 минут, можно задать две регистрации как интервал регистрации изменений и период ожидания – 10 минут. Это обеспечит завершение текущей сборки до начала следующей. При возникновении перегрузки сервера сборки, можно увеличить значения этих параметров.

Процесс непрерывной интеграции в Team Foundation Server Team Foundation Server 2005 не обеспечивает стандартного решения для поддержки процесса непрерывной интеграции, но предоставляет разработчику инфраструктуру для реализации собственного решения по организации процесса непрерывной интеграции.

Подробнее о настройке процесса непрерывной интеграции в TFS рассказывается в разделе «Как: настроить процесс непрерывной интеграции в Visual Studio Team Foundation Server». В нем используется решение, предоставленное группой разработки Visual Studio Team System. Это решение устанавливает Веб-сервис, который выполняется под учетной записью, имеющей доступ к серверу TFS. Team Foundation Server при возникновении определенных событий может посылать сообщение электронной почты или вызывать Веб-сервис. Механизм событий используется данным решением для подписки Веб-сервиса на CheckinEvent (Событие регистрации изменений). Тогда каждый раз при регистрации изменений Веб-сервис будет запускать Team Build.

Примечание: Пользователи TFS 2008 могут планировать сборки из Visual Studio. Для этого щелкаем правой кнопкой мыши на описании типа сценария сборки под узлом Builds в Team Explorer, выбираем Edit Build Definition, щелкаем Trigger и активируем сборку при регистрации изменений.

Заключение Процесс непрерывной интеграции используется для обеспечения выполнения сборки при каждой регистрации изменений в коде в системе контроля версий разработчиком. Хотя Team Build не обеспечивает идеального решения для поддержки непрерывной интеграции, есть возможность настроить процесс сборки и реализовать собственное решение получения сборок в результате непрерывной интеграции.

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

 

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

Дополнительные источники 



Более подробно об использовании решения организации процесса непрерывной интеграции Visual Studio Team System рассказывает статья «Continuous Integration Using Team Foundation Build» (Непрерывная интеграция с использованием Team Foundation Build) (http://msdn2.microsoft.com/enus/library/ms364045(VS.80).aspx). Скачать пакет установки MSI решения по организации процесса непрерывной интеграции Visual Studio Team System можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de0e81d3de2482/ci.msi.



Более подробно о гибкой разработке и непрерывной интеграции в Team Foundation Server смотрите в статье «Extend Team Foundation Server To Enable Continuous Integration» (Расширение Team Foundation Server для обеспечения процесса непрерывной интеграции) по адресу http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx.

Глава 9 – Настройка плановых сборок в Team Build Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи  

Понять назначение плановых сборок. Настроить плановую сборку с помощью Microsoft® Visual Studio® Team System Team Build.

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

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

Как использовать данную главу Эта глава расскажет о стратегиях плановых сборок и научит настраивать и конфигурировать плановые сборки, используя Team Build. Пошаговый обзор и анализ процесса настройки плановой сборки приведен в разделе «Как: настроить плановую сборку в Visual Studio Team Foundation Server».

Новичкам в TFS и Team Build, а также тем, кто желает подробнее рассмотреть доступные варианты автоматизации и планирования сборок, рекомендуется сначала прочитать Главу 7 «Team Build».

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

Стратегия выбора частоты плановых сборок Частота выполнения сборки – одно из наиболее важных решений при создании плановых сборок. Сборки могут выполняться каждый час, каждую ночь или каждую неделю.

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

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

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

Плановая сборка в Team Foundation Server Пользовательский интерфейс Team Build в TFS 2005 не поддерживает возможности организации плановых сборок. Планировщик задач Microsoft Windows® Task Scheduler может обеспечить выполнение сборок в заданный момент времени, запуская командный файл TFSBuild.

Этапы создания плановой сборки: 18. Создаем строку команды запуска TFSBuild. TfsBuild start

19. Помещаем строку команды запуска в командный файл. Обратите внимание, что необходимо задать полный путь к файлу TFSBuild.exe, чтобы его можно было запускать из окна командной строки Windows. Вот пример команды, используемой в командном файле: "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild" start

20. Создаем Windows Scheduled Task (Плановая задача Windows), которая выполняет командный файл через заданный промежуток времени.

Более подробная информация представлена в разделе «Как: настроить плановую сборку в Visual Studio Team Foundation Server».

Примечание: Пользователи TFS 2008 могут планировать сборки из Visual Studio. Для этого щелкаем правой кнопкой мыши на описании типа сценария сборки под узлом Builds (сборки) в Team Explorer, выбираем Edit Build Definition (Редактировать тип сценария сборки), щелкаем Trigger (Условия запуска) и задаем нужное расписание.

Заключение Плановые сборки используются для регулярного создания сборок, предоставляемых группе тестирования или другим потребителям сборок для получения обратной связи о качестве сборки. Пользовательский интерфейс Team Foundation Server 2005 не поддерживает возможности организации плановых сборок. Поэтому для выполнения сборок в заданный момент времени может использоваться Windows Task Scheduler (Планировщик задач Windows), который будет запускать командный файл TFSBuild с заданной частотой.

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

Дополнительные источники 

Подробнее о настройке плановых сборок рассказывает статья «How To – Configure a Scheduled Build (Command Line)» (Как – конфигурировать плановую сборку (с использованием командной строки)) по адресу http://msdn2.microsoft.com/en-us/library/ms181727(VS.80).aspx.

Глава 9 – Настройка плановых сборок в Team Build Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи  

Понять назначение плановых сборок. Настроить плановую сборку с помощью Microsoft® Visual Studio® Team System Team Build.

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

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

Как использовать данную главу Эта глава расскажет о стратегиях плановых сборок и научит настраивать и конфигурировать плановые сборки, используя Team Build. Пошаговый обзор и анализ процесса настройки плановой сборки приведен в разделе «Как: настроить плановую сборку в Visual Studio Team Foundation Server».

Новичкам в TFS и Team Build, а также тем, кто желает подробнее рассмотреть доступные варианты автоматизации и планирования сборок, рекомендуется сначала прочитать Главу 7 «Team Build».

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

Стратегия выбора частоты плановых сборок Частота выполнения сборки – одно из наиболее важных решений при создании плановых сборок. Сборки могут выполняться каждый час, каждую ночь или каждую неделю.

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

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

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

Плановая сборка в Team Foundation Server Пользовательский интерфейс Team Build в TFS 2005 не поддерживает возможности организации плановых сборок. Планировщик задач Microsoft Windows® Task Scheduler может обеспечить выполнение сборок в заданный момент времени, запуская командный файл TFSBuild.

Этапы создания плановой сборки: 21. Создаем строку команды запуска TFSBuild. TfsBuild start

22. Помещаем строку команды запуска в командный файл. Обратите внимание, что необходимо задать полный путь к файлу TFSBuild.exe, чтобы его можно было запускать из окна командной строки Windows. Вот пример команды, используемой в командном файле: "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild" start

23. Создаем Windows Scheduled Task (Плановая задача Windows), которая выполняет командный файл через заданный промежуток времени.

Более подробная информация представлена в разделе «Как: настроить плановую сборку в Visual Studio Team Foundation Server».

Примечание: Пользователи TFS 2008 могут планировать сборки из Visual Studio. Для этого щелкаем правой кнопкой мыши на описании типа сценария сборки под узлом Builds (сборки) в Team Explorer, выбираем Edit Build Definition (Редактировать тип сценария сборки), щелкаем Trigger (Условия запуска) и задаем нужное расписание.

Заключение Плановые сборки используются для регулярного создания сборок, предоставляемых группе тестирования или другим потребителям сборок для получения обратной связи о качестве сборки. Пользовательский интерфейс Team Foundation Server 2005 не поддерживает возможности организации плановых сборок. Поэтому для выполнения сборок в заданный момент времени может использоваться Windows Task Scheduler (Планировщик задач Windows), который будет запускать командный файл TFSBuild с заданной частотой.

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

Дополнительные источники 

Подробнее о настройке плановых сборок рассказывает статья «How To – Configure a Scheduled Build (Command Line)» (Как – конфигурировать плановую сборку (с использованием командной строки)) по адресу http://msdn2.microsoft.com/en-us/library/ms181727(VS.80).aspx.

Часть V Управление проектом В данной части:  

Управление проектом Рабочие элементы

Глава 11 – Управление проектом Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Изучить возможности, предоставляемые Microsoft® Visual Studio® Team System (VSTS) для руководителей проектов. Выбрать стратегию создания проекта группы. Создавать и управлять проектами с использованием Visual Studio Team System.

Обзор Данная глава знакомит с возможностями управления проектами, предоставляемыми Visual Studio Team System, и рассказывает, как с их помощью можно решать многие проблемы и задачи, обычно возникающие при управлении проектами по разработке программного обеспечения.

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

Как использовать данную главу В этой главе будут изучены специальные возможности управления проектами TFS и VSTS.   

Прочитайте разделы «Обзор системы управления проектами» и «Задачи, традиционно решаемые системой управления проектами», чтобы понять, какие проблемы пытается решать система управление проектами TFS. Раздел «Стратегии работы над групповым проектом» поможет выбрать стратегию создания и организации группового проекта. Остальные разделы помогут лучше понять шаблоны процессов, рабочие элементы и другие возможности управления проектами.

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

3.

4.

5.

6.

программного обеспечения. Также здесь выполняется оценка того, заинтересован ли заказчик в таких сценариях. Формирование набора функциональных возможностей для поддержания выработанных сценариев. На данном этапе сценарии разбиваются на отдельные элементы, имеющие значение для заказчиков, таким образом, появляется возможность обсуждать ожидания заказчика относительно этих элементов. Формирование набора рабочих элементов. На данном этапе сценарии и функциональные возможности разбиваются на конкретные задачи. Иными словами, завершение рабочих элементов будет означать реализацию соответствующей функции или сценария. Распределение задач по областям. На данном этапе задачи распределяются по областям. Эти области выделяются на базе функциональных возможностей или в зависимости от организации конкретной группы. Создание плана работ. На данном этапе либо создается полный график выполнения работ, либо производится разбиение всей работы на итерации.

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







Работа с разрозненными источниками информации. Инструменты управления проектами обычно используются изолированно, что приводит к возникновению разрозненных источников информации, которые не так просто интегрировать. Также обычно сложно свести воедино данные инструментов управления проектами с данными, предоставляемыми другими членами группы, например, учесть дефекты, выявленные изолированной системой отслеживания дефектов, при формировании показателей. Сложности со сбором показателей проекта. Сбор показателей проекта очень важен для отслеживания статуса, принятия обоснованных решений и ответа на фундаментальные вопросы, такие как «Будет ли проект поставлен вовремя и будет ли выполнен бюджет?». Отвечая на такие ключевые вопросы, руководитель проекта обычно полагается на данные, полученные от Microsoft Office Project или системы отслеживания дефектов, используемой группами разработки и тестирования. Объединить данные, предоставляемые этими несопоставимыми системами, сложно, на это уходит много времени, в процессе сведения данных очень легко допустить множество ошибок. Для большинства показателей, формируемых инструментальными средствами, не существует унифицированной системы хранения и доступа. Создание отчетов – это обычно напряженный ручной труд, связанный с многократным копированием и вставкой информации из разных инструментальных средств. Сложности с обеспечением выполнения требований. Зачастую работа, запланированная для группы разработки, требования заказчика и основные







нефункциональные требования, определенные для создаваемой системы, существенно отличаются друг от друга. Еще одна «пропасть» существует между тем, какой объем работ был запланирован, и тем, что из этого было фактически выполнено. Из-за этих несоответствий теряются важнейшие данные, что приводит к невыполнению требований. Управление процессами и изменениями в них. Объяснить группе, каких процессов она должна придерживаться, очень сложно. Еще сложнее может быть реализовать изменения для решения систематически возникающих проблем, не снизив производительности группы. Недостаток поддающихся контролю обмена информацией и отслеживания задач. Взаимодействие и слаженность группы обычно обеспечиваются совещаниями и распределением списков задач между разработчиками с целью помочь им правильно выбрать приоритеты. Отслеживать процесс выполнения отдельной задачи может быть очень сложно. Также руководители проектов часто тратят массу ценного времени на сбор информации о статусе процесса из разных планов и списков. Члены группы также тратят время на отчеты о состоянии и обновление различных документов и форм. Контроль качества. Предсказать количество и серьезность дефектов в создаваемом ПО сложно, поэтому обычно плановые оценки и затраты являются «наилучшими предположениями». В этих оценках традиционно учитываются коэффициент запаса, величина которого зависит от степени уверенности руководителя в текущем состоянии проекта.

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

Функциональность управления проектами в Team Foundation Server К основным функциям управления проектами, предоставляемым Visual Studio Team System, относятся:



 

Управление процессом. Система управления процессами Team Foundation Server включает руководство по процессу Microsoft Solution Framework (MSF), а также шаблоны процессов, которые обеспечивают новые групповые проекты типами рабочих элементов, отчетами, SharePoint-порталом проекта и настройками системы контроля версий. Безопасность и права доступа. Новые проекты содержат стандартные группы и права доступа, которые отображаются в обычные роли группы разработки. Централизованное управление рабочими элементами. Рабочие элементы, включая дефекты, риски, задачи, сценарии и нефункциональные требования (quality of service, QoS), централизованно регистрируются, управляются и обслуживаются в базе данных рабочих элементов TFS. Централизованное хранение упрощает доступ и просмотр этих элементов всеми членами группы.







Интеграция Microsoft Office Excel® и Microsoft Office Project. Благодаря возможности интеграции Office Excel и Office Project руководители проектов могут работать с хранилищем рабочих элементов и информацией по срокам выполнения проекта, используя уже хорошо знакомые инструменты. Показатели и составление отчетов. TFS предоставляет сервис создания и отображения отчетов, который превращает рабочие данные, такие как рабочие элементы, результаты сборки и результаты тестирования, в показатели, хранящиеся в хранилище данных TFS. Благодаря встроенным отчетам можно запрашивать разнообразные показатели состояния и качества проекта. Порталы проекта. Для каждого группового проекта TFS создает ассоциированный портал проекта, использующий сервисы Microsoft Windows SharePoint®. Портал используется для управления документацией проекта, быстрого просмотра ключевых отчетов и оценки текущего статуса проекта.

Преимущества Функциональность управления проектами TFS дает следующие преимущества:

     

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

Создание и управление проектами с использованием Team Foundation Server Общий подход к созданию проектов в Team Foundation Server можно представить следующими этапами: 1. Выбор шаблона процесса. Можно использовать или поставляемый стандартный шаблон, или создать собственный. 2. Создание группового проекта. В основу проекта ляжет ваш шаблон процесса. 3. Добавление в групповой проект соответствующих групп и членов. 4. Принятие решения о продолжительности итерационного цикла проекта. Включает создание итераций в групповом проекте. 5. Регистрация сценариев в TFS как рабочих элементов. 6. Определение того, какие сценарии должны быть завершены в каждой итерации. 7. Определение нефункциональных требований. Связь нефункциональных требований со сценариями. 8. Разбиение сценариев на истории с целью обеспечить разработчиков управляемыми рабочими элементами. Разработчики предоставляют предварительные оценки по срокам выполнения для каждого рабочего элемента. 9. Создание графика выполнения проекта. Создается график выполнения проекта (с помощью Microsoft Project) и добавляется в Team Project.

10. Определение критериев приемки. Определяются критерии приемки рабочих элементов (соотносящиеся с требованиями QoS). 11. Определение требований к отчетам. Определяются ключевые показатели выполнения проекта и оговариваются требования к составляемым отчетам.

Более подробно о создании и управлении проектом рассказывается в разделе «Как: управлять проектами в Visual Studio Team Foundation Server».

Стратегии работы над групповыми проектами Чтобы начать работать с TFS, необходим, по крайней мере, один групповой проект. Когда руководитель проекта создает новый групповой проект, создается соответствующий Веб-сайт группового проекта с библиотеками документов, в которых содержатся шаблоны документов и встроенные отчеты. Создается база данных рабочих элементов для отслеживания всех работ по проекту. Устанавливается шаблон методологии, определяющий правила, политики, группы доступа и запросы для всех работ по проекту. Кроме того, в системе контроля версий создается ветвь исходного кода.

При выборе структуры группового проекта необходимо руководствоваться предъявленными требованиями. Структура проекта может меняться в процессе работы над ПО. Существует три основных стратегии создания нового проекта, которые могут использоваться по отдельности или в сочетании друг с другом:

  

Один проект на приложение Один проект на выпускаемую версию Один проект на группу

Один проект на приложение Это самая распространенная стратегия создания групповых проектов. Такой подход подходит как для больших, так и для небольших приложений, а также для параллельной разработки нескольких версий приложения. При таком подходе для каждого приложения, находящегося в разработке, создается по одному проекту.

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

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

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

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

 





Руководство по процессу. Предоставляется для каждого шаблона и обеспечивает контекстно-зависимую информацию, справку и указание членам группы, нуждающимся в помощи для выполнения или понимания определенной деятельности. Руководство по выполнению процесса интегрировано в Visual Studio Help System. Шаблоны документов. Эти шаблоны позволяют членам группы единообразно создавать новые документы (спецификации, оценки рисков и планы проектов). Рабочие элементы и последовательность операций. Рабочие элементы имеют собственный набор полей и правил, определяющих последовательность операций рабочего элемента и то, как члены группы могут распределить и выполнить работу. Группы доступа. Эти группы используются для определения того, кто может управлять и изменять отчеты, результаты работы, такие как исходный код и документация, и рабочие элементы. Руководитель проекта может администрировать группы доступа, для этого ему не обязательно быть администратором Windows. Политики регистрации изменений. Эти политики могут использоваться для применения правил и порогов качества ко всему коду, регистрируемому в системе контроля версий. Например, можно поставить условие, что весь регистрируемый код должен отвечать определенному критерию, скажем, соответствовать корпоративным стандартам написания кода, или должен подвергаться модульному тестированию. Более подробно о том, как создавать и конфигурировать специальные политики регистрации изменений,



рассказывает раздел «Как: создавать специальные политики регистрации изменений в Visual Studio Team Foundation Server». Отчеты. Используются для отслеживания процесса исполнения и текущего статуса проекта. VSTS поставляется с множеством встроенных отчетов, включая отчеты о качестве кода, о ходе выполнения графика работ, об эффективности тестирования и многие другие. Можно создавать собственные отчеты и настраивать существующие.

Шаблоны процессов MSF для гибкой разработки ПО и MSF для совершенствования процесса согласно CMMI С VSTS поставляются следующих два шаблона процессов.





MSF для гибкой разработки ПО (MSF for Agile Software Development). Этот простой шаблон процесса для небольших, гибких или неформальных проектов по разработке ПО основывается на сценариях и управляемых контекстом действиях. Ориентирован на проект и людей. MSF для совершенствования процесса согласно CMMI® (MSF for CMMI® Process Improvement). Этот шаблон процесса разработан для более серьезных проектов по разработке ПО. Он расширяет шаблон MSF для гибкой разработки ПО, предоставляя поддержку для аудитов, верификации и формальных процессов. Он полагается на процесс и соответствие процессу, и ориентирован на организацию.

Если предоставляемые шаблоны недостаточно близко отвечают требованиям конкретного процесса и методологии, можно добавить в систему новые шаблоны процессов или настроить поставляемые. Более подробно о настройке существующих шаблонов рассказывается в разделе «Как: настроить шаблон процессов в Visual Studio Team Foundation Server».

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

Project Administrator (Администратор проекта) Contributor (Участник) Reader (Читатель) Build Services (Сервисы сборки)

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

минимально необходимые права доступа и вводить только тех пользователей или группы, которые должны входить в группу этого нового группового проекта.

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

Управление рабочими элементами Рабочие элементы используются как единицы работы для обмена информацией и координации совместной деятельности в группе. Выбранный шаблон процесса обеспечивает исходный набор типов рабочих элементов. Руководители проекта создают и организовывают дополнительные рабочие элементы, которые должны быть внесены в проект разработки. Рабочий элемент может описывать задачу, риск, сценарий, дефект или нефункциональное требование (QoS). Для улучшения прослеживаемости можно устанавливать связи между рабочими элементами. Например, можно ассоциировать определенную задачу с соответствующим ей сценарием или требованием QoS.

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

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

Шаблон процесса MSF для гибкой разработки ПО Типы рабочих элементов, предоставляемые данным шаблоном процесса:



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

 

 

Задача – Представляет единицу работы, которая должна быть выполнена. У каждой роли свои требования к задаче. Например, разработчик использует задачи разработки для распределения работ. Нефункциональное требование – Документирует характеристики системы, такие как производительность, нагрузка, доступность, устойчивость к нештатным условиям эксплуатации, специальные возможности и удобство обслуживания. Дефект – Используется для сообщения о потенциальной проблеме в системе. Риск – Используется для выявления и управления рисками в проекте.

Шаблон процесса MSF для совершенствования процесса согласно CMMI® Типы рабочих элементов, предоставляемые данным шаблоном процесса:

      

Требование – Фиксирует требования, определенные на этапе сбора требований. Запрос о необходимости внесения изменения – Фиксирует любые запросы на внесение изменений, возникающие после сбора требований. Проблема – Представляет проблемы проектов, которые должны отслеживаться. Задача – Представляет единицу работы, которая должна быть выполнена. У каждой роли собственные требования к задаче. Например, разработчик использует задачи разработки для распределения работ. Рецензия – Представляет единицы работы по составлению отзывов, например, рецензия исходного кода, рецензия проектирования и т.д. Дефект – Используется для сообщения о потенциальной проблеме в системе. Риск – Используется для выявления и управления рисками в проекте.

Интеграция Microsoft Project Установка VSTS или приложения Team Explorer предоставляют расширения для Microsoft Project. В больших проектах, в которых задействовано большое количество ресурсов, для работы с данными графика работ на проекте в TFS можно использовать Microsoft Office Project.

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

Подробнее об этом рассказывается в статье «Working with Work Items in Microsoft Project» (Работа со списками рабочих элементов в Microsoft Project) (http://msdn2.microsoft.com/en-us/library/ms244368(VS.80).aspx).

Интеграция Microsoft Excel Установка VSTS или приложения Team Explorer предоставляют расширения для Microsoft Excel. В больших проектах, где задействовано большое количество рабочих элементов, можно использовать возможность интеграции с Excel: создавать рабочие элементы в электронной таблице Excel и загружать их в базу данных рабочих элементов для использования другими членами группы.

Подробнее смотрите в статье «Working with Work Item Lists in Microsoft Excel» (Работа со списками рабочих элементов в Microsoft Excel) (http://msdn2.microsoft.com/enus/library/ms181694(VS.80).aspx).

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

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

Используемый шаблон проекта определяет доступные по умолчанию отчеты, но также существует возможность добавить собственные специальные отчеты. Содержимое и использование каждого отчета, созданного шаблоном процесса, объясняется в руководстве по процессу для этого шаблона. Team Foundation Server построен на Microsoft SQL Server™ 2005 и использует SQL Server для хранения всех данных, связанных с рабочими элементами, атрибутами качества, тестированием, результатами тестирования и результатами сборок. Для объединения и анализа этих данных и создания отчетов TFS использует SQL Server Analysis Services. Отчеты, созданные шаблоном процесса или отдельными членами группы с помощью Microsoft Office Excel или Visual Studio 2005 Report Designer, становятся доступными посредством SQL Server 2005 Reporting Services и SharePoint-сайта портала группы.

Более подробно о настройке отчетов рассказывается в разделе «Как: создать специальный отчет для Visual Studio Team Foundation Server».

Заключение Team Foundation Server обеспечивает такие возможности управления проектами, как централизованное управление рабочими элементами, управление процессами, управление безопасностью и правами доступа, сбор показателей проекта и составление отчетов. Все это упрощает решение задач по управлению проектами по разработке ПО в Visual Studio.

Жизненный цикл разработки ПО был выбран неотъемлемой частью инструментария для поддержки задач по разработке ПО. TFS предоставляет шаблоны процессов MSF Agile и MSF CMMI, которые поддерживают две очень разные методики разработки. Можно изменять предоставляемые шаблоны процессов или создавать с нуля собственный процесс, удовлетворяющий нуждам процесса разработки конкретной группы.

Дополнительные источники 





Более подробно об управлении и организации проектов по разработке ПО с использованием VSTS рассказывает статья «Visual Studio 2005 Team System: Software Project Management» (Visual Studio 2005 Team System: Управление проектом по разработке ПО) по адресу http://msdn2.microsoft.com/enus/library/aa302181.aspx. Более подробная информация об использовании Microsoft Office Excel для решения задач по управлению проектами приведена в статье «Working with Work Item Lists in Microsoft Excel» по адресу http://msdn2.microsoft.com/enus/library/ms181694(VS.80).aspx. Подробнее об использовании Microsoft Office Project для решения задач по управлению проектами рассказывает статья «Working with Work Items in Microsoft Project» по адресу http://msdn2.microsoft.com/enus/library/ms244368(VS.80).aspx.

Глава 12 – Рабочие элементы Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Изучить назначение и структуру рабочих элементов. Описать последовательность операций рабочего элемента. Научиться настраивать рабочие элементы соответственно конкретным требованиям группы.

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

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

Как использовать данную главу Что использовать данную главу с максимальной пользой, необходимо:  

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

Сценарии и решения Рабочие элементы – основной инструмент руководителей проектов и ведущих разработчиков групп для отслеживания работ в проекте: того, что уже сделано и что еще предстоит сделать. Члены группы используют рабочие элементы для отслеживания собственной очереди работ и для назначения работ друг другу, например, в форме дефектов или задач.

Обычно рабочие элементы в проектах используются для:

      

Формирования требований пользователей или нефункциональных требований (QoS) для приложения. Отслеживания соответствия требованиям процессов разработки и тестирования. Создания задач разработки, представляющих работу, которая должна быть выполнена для реализации компонентов и функциональности приложения. Создания дефектов для представления дефектов реализации компонентов и функциональности приложения. Сортировки дефектов и задач соответственно приоритетам и для равномерного их распределения между членами группы. Отслеживания задач разработки для оценки темпов продвижения в направлении к статусу «Написание кода полностью завершено». Отслеживания дефектов и других показателей качества для определения качества приложения и его готовности к поставке.

То, как рабочие элементы используются в проекте, зависит от того, какие типы рабочих элементов определены для проекта. Описания рабочих элементов хранятся в шаблоне процесса, который выбирается при создании проекта. Можно выбрать один из двух стандартных шаблонов – Microsoft® Solution Framework (MSF) для гибкой разработки ПО (MSF Agile) или MSF для совершенствования процесса согласно CMMI® (MSF CMMI) ― или настроить рабочие элементы соответственно конкретным требованиям и процессу группы.

Структура рабочего элемента Каждый тип рабочего элемента можно описать следующим образом: 

 

Он имеет назначение и предполагаемое использование. Например, дефекты используются для отслеживания дефектов качества, задачи – для отслеживания запланированных работ, требования QoS – для описания критических аспектов, не связанных с функциональностью, таких как требования к безопасности и производительности, и .т.д. Он имеет последовательность операций, описанную посредством состояний и переходов. Например, шаги от статуса «Opened» (Открыт) к статусу «Resolved» (Решен) и «Closed» (Закрыт). У него есть набор полей, которые можно устанавливать6 и запрашивать, и по которым можно составлять отчет. Например, поля Priority (Приоритет), Status (Статус) и Iteration (Итерация).

Типы рабочих элементов Шаблоны процессов MSF Agile и MSF CMMI определяют наборы рабочих элементов, которые отображаются в роли и деятельности, описанные в руководстве по процессу.

Типы рабочих элементов шаблона MSF Agile MSF Agile содержит следующие типы рабочих элементов:  6

Дефект. Представляет реальную или потенциальную проблему в приложении.

в любое из допустимых значений – прим. переводчика

   

Риск. Представляет возможное событие или условие, которое может иметь негативное воздействие на проект. Сценарий. Представляет один из сюжетов взаимодействия пользователя с системой. Задача. Представляет необходимость выполнения некоторой работы членом группы. Нефункциональное требование. Представляет требование, являющееся неким ограничением рабочих характеристик системы.

Типы рабочих элементов шаблона MSF CMMI MSF CMMI содержит следующие типы рабочих элементов:       

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

Последовательность операций рабочего элемента Каждый рабочий элемент имеет предопределенную последовательность операций, которая представляет все возможные состояния рабочего элемента, а также переходы между состояниями. Каждое состояние обычно ассоциируется с ролью в TFS. Например, когда тестировщик открывает новый дефект в MSF Agile, состояние рабочего элемента (дефекта) Active. Когда разработчик исправляет дефект, рабочий элемент меняет состояние на Resolved. Когда тестировщик подтверждает исправление дефекта, его состояние меняется на Closed.

Примеры последовательностей операций Далее приведены примеры последовательностей операций двух самых распространенных типов рабочих элементов.

Задача MSF CMMI Задача MSF CMMI может находиться в следующих состояниях:    

Proposed (предложена). Например, предложена разработчиком, тестировщиком или архитектором. Active (активна). Например, принята ведущим разработчиком или руководителем. Resolved (решена). Например, решена разработчиком. Closed (закрыта). Например, протестирована и закрыта тестировщиком.

На рис. 12.1 показаны все состояния и возможные переходы между ними.

Рис. 12.1 Переходы между состояниями рабочего элемента MSF CMMI

Дефект MSF Agile Дефект MSF Agile может находиться в следующих состояниях:   

Active (активен). Например, открыт тестировщиком. Resolved (решен). Например, решен разработчиком. Closed (закрыт). Например, протестирован и закрыт тестировщиком.

На рис. 12.2 показаны все состояния и возможные переходы между ними.

Рис. 12.2 Переходы между состояниями рабочего элемента MSF Agile

Как настраивать рабочие элементы Существует несколько сценариев, при которых может потребоваться изменить типы рабочих элементов, описанные в MSF Agile или MSF CMMI:   

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

Для поддержания этих сценариев в TFS можно сделать следующее:   

Добавлять/удалять типы рабочих элементов. Изменять поля в существующих рабочих элементах. Изменять состояния и переходы в существующих рабочих элементах.

Более подробно о настройке рабочих элементов рассказывает раздел «Как: настроить шаблон процесса в Visual Studio Team Foundation Server».

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

Шаблоны процессов MSF Agile и MSF CMMI предоставляют набор стандартных типов рабочих элементов. Для удовлетворения требованиям процесса существует возможность настроить предлагаемые или создать новые типы рабочих элементов

Дополнительные источники  



Более подробно о рабочих элементах рассказывается в статье «Managing Team Foundation Work Items» (Управление рабочими элементами Team Foundation) (http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx). Скачать шаблон процесса MSF CMMI и ознакомиться с предлагаемыми им типами рабочих элементов можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB984EB4-BF6B-FB5B266171EB&displaylang=en. Скачать шаблон процесса MSF Agile и ознакомиться с предлагаемыми им типами рабочих элементов можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F48FB-824E-828BF593C34D&displaylang=en.

ЧАСТЬ VI Шаблоны процессов В данной части:  

Шаблоны процессов Проекты MSF Agile

Глава 13 – Шаблоны процессов Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Понять назначение, содержимое и структуру шаблонов процессов. Рассмотреть основные различия между шаблонами процессов Microsoft® Solution Framework (MSF) для гибкой разработки ПО (MSF Agile) и MSF для совершенствования процесса согласно CMMI® (MSF CMMI). Настроить шаблоны процессов соответственно конкретным требованиям группы.

Обзор Данная глава объясняет роль шаблонов процессов в Microsoft Visual Studio® 2005 Team Foundation Server (TFS). В ней рассмотрены важнейшие особенности и различия между двумя поставляемыми шаблонами: MSF Agile и MSF CMMI.

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

Visual Studio Team System (VSTS) и TFS предоставляют интегрированную среду, поддерживающую большинство работ процесса, выполняемых в проекте по разработке ПО. TFS реализует свои методологии обеспечения жизненного цикла через использование шаблонов процессов. Шаблон процесса – это набор файлов на Extensible Markup Language (XML), предоставляющих спецификации процессов и артефактов, которые составляют методологию разработки. В данной главе рассматривается архитектура шаблона процесса и его компоненты, что поможет лучше понимать, как использовать и настраивать поставляемые шаблоны процессов.

Если существующие шаблоны процессов не отвечают нуждам группы, можно создать новый шаблон процесса, изменить существующие шаблоны или выбрать один из шаблонов, предлагаемых партнерами Microsoft. Шаблоны партнеров Microsoft можно найти по адресу http://msdn2.microsoft.com/en-us/teamsystem/aa718801.

Как использовать данную главу Данная глава поможет понять архитектуру и структуру процесса, а также то, как его можно настраивать. Чтобы использовать главу с максимальной пользой, следует:

 

Прочитать раздел «Шаблоны процессов MSF Agile и MSF CMMI», чтобы узнать о стандартных шаблонах процессов и о том, как выбрать шаблон, лучше всего соответствующий нуждам группы. Прочитать раздел «Руководство по настройке процесса», чтобы научиться настраивать существующие шаблоны процессов соответственно нуждам группы.

Шаблоны процессов MSF Agile и MSF CMMI Team Foundation Server поставляется с двумя шаблонами процессов: MSF Agile и MSF CMMI. Эти шаблоны ориентированы на два разных стиля разработки ПО. MSF Agile используется, если ПО создается по гибкой методологии. MSF Agile поддерживает разработку через тестирование и другие гибкие практики. MSF CMMI следует использовать, если ПО создается по методике комплексной модели производительности и зрелости CMMI (Capability Maturity Model® Integration) Института по разработке ПО (Software Engineering Institute, SEI). Это формальный процесс, предназначенный для улучшения существующих процессов разработки.

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

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

Архитектура шаблона процесса В архитектуре шаблона процесса можно выделить три основные части:

  

Подключаемые модули шаблона процесса XML-файлы описания процесса New Team Project Wizard (Мастер создания группового проекта)

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

     

Классификация – Определяет исходную итерацию и области группового проекта. Группы и права доступа – Определяет исходные группы доступа группового проекта и их права доступа. Сервисы Windows SharePoint – Определяет портал проекта для группы на основании шаблона сайта Microsoft Windows SharePoint®. Также определяет файлы шаблона и руководство по процессу. Отслеживание рабочих элементов – Определяет исходные типы рабочих элементов, запросы и экземпляры рабочих элементов группового проекта. Отчеты – Определяет исходные отчеты группового проекта и настраивает сайт отчетов. Контроль версий – Определяет исходные права доступа к системе контроля версий группового проекта и наличие комментариев к регистрации изменений.

Чтобы настроить шаблон процесса, можно изменить любой файл описания подключаемого модуля. Также можно удалить любой файл описания подключаемого модуля, кроме классификации.

XML-файлы описания процесса XML-файлы описания процесса –это набор XML-файлов, описывающих ряд задач, выполнение которых обеспечит правильное конфигурирование нового группового проекта для процесса. Мастер New Team Project, используемый для создания группового проекта, выполняет необходимые подключаемые модули. Каждый подключаемый модуль считывает список задач, которые он должен выполнить, из соответствующего XML-файла описания процесса. Посредством XML-файлов описания процесса задаются конфигурации и настройки, которые должны быть реализованы подключаемыми модулями. Далее об XML-файлах более подробно:



XML-файл отслеживания рабочих элементов– Этот файл описания процесса называется Workitems.xml и располагается в папке Work Item Tracking (Отслеживание рабочих элементов) каталога шаблона процесса. Должны быть заданы три основных типа задач: типы рабочих элементов, запросы к рабочим элементам и экземпляры рабочих элементов. o Типы рабочих элементов – Определяют правила, поля, состояния и переходы для элементов работы, которые будут отслеживаться для группового проекта, таких как задачи, дефекты и требования. o Запросы к рабочим элементам – Используются для группировки рабочих элементов, например, задачи или активные дефекты. Запросы к рабочим элементам определены в файлах запросов к рабочим элементам (work item







query, WIQ), находящихся в папке Queries (запросы), которая, в свою очередь, располагается в папке Work Item Tracking каталога шаблона процесса. o Экземпляры рабочих элементов – Исходный набор экземпляров рабочих элементов, создаваемый по умолчанию при создании группового проекта. XML-файл классификации – Этот файл описания процесса называется Classification.xml и располагается в папке Classification (Классификация) каталога шаблона процесса. Он состоит из двух частей: Iterations (Итерации) и Areas (Области). o Итерации – Используются для определения количества повторений группой определенного набора основных действий (таких как планирование, разработка, тестирование). Итерации оказывают влияние на запросы к рабочим элементам и отчеты, потому что используются для группировки рабочих элементов. o Области – Используются для организации работы в групповом проекте. Например, группа могла бы организовать работу, опираясь на продукт или функциональную возможности, т.е. выделяя область UI (пользовательский интерфейс), область приложения и область базы данных. С помощью областей рабочие элементы группируются для запросов и отчетов. XML-файл сервисов Windows SharePoint– Этот файл описания проекта называется WssTasks.xml и располагается в папке Windows SharePoint Services (сервисы Windows SharePoint) в каталоге шаблона процесса. В нем должны быть заданы три основных задачи: Site Template (Шаблон сайта) – какой шаблон сайта использовать, Document Libraries (Библиотеки документов) – какие библиотеки документов создавать и Folders and Files (Папки и файлы) – какие папки и файлы копировать в библиотеки документов. o Шаблон сайта – Должен быть задан шаблон сайта, на котором будет базироваться портал проекта. Этот шаблон сайта также должен быть доступен на портале TFS SharePoint. Шаблоны сайтов не входят в шаблон процесса. o Библиотека документов – Можно оговорить необходимость создания дополнительных библиотек документов после создания портала проекта. o Папки и файлы – Можно оговорить необходимость создания дополнительных папок после создания портала проекта. Также можно задать файлы для копирования, например, файлы шаблона. XML-файл контроля версий – Этот файл описания процесса называется VersionControl.xml и располагается в папке Version Control (Контроль версий) каталога шаблона процесса. Он определяет исходные права доступа к системе контроля версий, наличие комментариев к регистрации изменений и необходимость в обеспечении возможности изъятия версии файла для редактирования из системы контроля версий исключительно одним пользователем. o Наличие комментариев к регистрации изменений – Определяет, должны ли быть включены комментарии к регистрации изменений. Такие комментарии предоставляются разработчиком при регистрации изменений для описания того, как изменения кода связаны, или связаны ли они с групповыми процессами. Например, комментарий к регистрации изменения может показывать, является ли изменение частью рецензии на предмет безопасности, и может включать детали об изменениях, имеющих отношение к анализу безопасности. o Изъятие версии файла для редактирования из системы контроля версий исключительно одним пользователем – Используется для управления возможностью изъятия версии файла многими пользователями одновременно. o Права доступа – Определяют, какие действия над элементами, подлежащими контролю версий, могут осуществлять группы доступа и отдельные члены группы.





XML-файл отчетов – Этот файл описания процесса называется ReportsTasks.xml и располагается в папке Reports (отчеты) каталога шаблона процесса. Он определяет исходные отчеты группового проекта. o Сайт отчетов – Сайт, составляющий отчеты, имеет ссылку на себя, обозначенную как Reports на домашней странице портала проекта. o Папки – Можно создавать папки на сайте отчетов. Созданная папка(-и) появится на сайте проекта и в Team Explorer в папке Reports. o Отчеты – Используются для добавления отчетов с помощью файлов .rdl. XML-файл групп и прав доступа – Этот файл описания проекта называется GroupsandPermissions.xml и располагается в папке Groups and Permissions (Группы и права доступа) в каталоге шаблона процесса. Используется для определения исходных групп доступа группового проекта. o Группы – Используется для определения новой группы доступа TFS. o Права доступа – Используется для определения прав доступа для каждой заданной группы.

Мастер создания группового проекта Новые групповые проекты создаются с помощью мастера New Team Project. Для создания проекта этот мастер использует подключаемые модули и XML-файлы описания процесса.

Подход к настройке процесса Настройка шаблона процесса осуществляется по следующей схеме:

1. Просмотреть шаблоны процессов, предлагаемые TFS, и выбрать из них наиболее близко подходящий к процессу, используемому в вашей организации. 2. Скачать выбранный шаблон процесса. 3. Настроить различные компоненты шаблона процесса. 4. Загрузить настроенный шаблон в TFS. 5. Убедиться в том, что внесенные изменения удовлетворяют требованиям вашего процесса.

Этот основной подход используется в следующих решениях для настройки шаблонов процессов:





Настройка XML-файлов вручную. Настройка вручную чревата большим количеством ошибок, но, тем не менее, обеспечивает наиболее тонкую настройку шаблонов процессов. Более подробно об этом смотрите в статье «Customizing Process Templates» (Как настраивать шаблоны процессов) по адресу http://msdn2.microsoft.com/enus/library/ms243782(VS.80).aspx. Редактор шаблонов процессов, доступный в инструментальных средствах, расширяющих возможности TFS. Самая последняя версия Visual Studio 2005 Team Foundation Server Power Tool ― набор расширений, инструментов и утилит командной строки, улучшающих работу с TFS – предоставляет графическое средство для просмотра и настройки шаблонов процессов. Подключившись к TFS, можно использовать этот инструмент для настройки описаний типов рабочих элементов и глобальных списков

активного проекта. Более подробно смотрите в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server».

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











 

Группы и права доступа. В стандартных шаблонах процессов есть набор групп с различными правами доступа. Если стандартные группы и права доступа, ассоциированные с этими шаблонами, не подходят или не соответствуют требованиям процесса, эти группы можно обновить или создать новые. Также можно добавлять в группу отдельных пользователей, удалять пользователей из группы или предоставлять и отменять права доступа группы. Комментарии и политики регистрации изменений системы контроля версий. В стандартных шаблонах процессов есть набор комментариев и политик регистрации изменений системы контроля версий. Если стандартные комментарии к регистрации изменений не подходят или не соответствуют требованиям процесса, можно добавлять или удалять поля комментариев или делать некоторые поля обязательными и необязательными. Если стандартные политики регистрации изменений не подходят или не соответствуют требованиям процесса, можно добавлять, обновлять или удалять отдельные политики регистрации изменений. Области и итерации. Стандартные шаблоны процессов не предоставляют структуру классификации ни для областей, ни для итераций. Их можно настроить соответственно требованиям конкретного процесса. Рекомендуемый подход – выделить области, исходя из компонентов или функциональности проекта. В качестве итераций могут рассматриваться временные циклы, для которых повторяется определенный набор основных действий (таких как планирование, разработка и тестирование). Портал группы. Стандартные шаблоны процессов предоставляют портал группы по умолчанию, который может быть концентратором для обмена информацией между членами группы и другими членами организации. Можно изменять внешний вид, поведение и содержимое портала соответственно требованиям процесса. Руководство по процессу. Стандартные шаблоны процессов предоставляют соответствующее руководство по процессу, объясняющее роли, формы, отчеты и порядок операций, используемые в групповом проекте. При настройке шаблона процесса соответственно конкретным требованиям необходимо редактировать руководство по процессу и отражать в нем изменения для различных компонентов. Отчеты. Стандартные шаблоны процессов предоставляют набор стандартных отчетов. Если они не подходят, можно создать собственные отчеты на основании конкретных требований. Типы рабочих элементов и запросы к ним. В стандартных шаблонах процессов есть набор типов рабочих элементов, стандартных экземпляров рабочих элементов и запросов. Если стандартные типы рабочих элементов, экземпляры рабочих элементов и запросы не соответствуют или не отвечают требованиям конкретного процесса, их можно настроить. Например, можно: o o o

Добавлять новые типы рабочих элементов. Удалять существующие типы рабочих элементов. Добавлять стандартные экземпляры рабочих элементов.

o o

Удалять стандартные экземпляры рабочих элементов. Создавать собственные общедоступные или индивидуальные запросы.

Также можно изменить существующий тип рабочего элемента; например:

o o o o o o o o o

Добавить поля. Переименовать поля. Ограничить список допустимых значений полей. Изменить состояния и поддерживаемые переходы между состояниями. Сделать поля обязательными или доступными только для чтения. Сделать поля зависимыми друг от друга. Автоматически заполнять значения полей. Изменять представление информации в форме. Менять столбец Microsoft Office Project, в который отображается определенное поле.

Как проходит процесс настройки? Настройка шаблона процесса проходит следующим образом:

1. Пользователь запускает мастер New Team Project. 2. Мастер запрашивает: o Имя группового проекта. o Шаблон процесса, который должен использоваться при создании группового проекта. Какое окно отображается в мастере, зависит от используемого подключаемого модуля. Например, если шаблон процесса не включает подключаемый модуль Windows SharePoint Services, окна с запросом информации о портале проекта представлено не будет. 3. После того, как пользователь предоставил информацию, запрашиваемую мастером, и нажал Finish (Завершить), мастер вызывает подключаемые модули для создания группового проекта. Порядок вызова подключаемых модулей определяется XMLфайлами описания процесса. 4. Соответственно инструкциям, содержащимся в шаблоне процесса, мастер создает и конфигурирует заданные элементы. 5. Пользователю не надо задавать какую-либо информацию о типах рабочих элементов, которые должны быть созданы, потому что инструкции уже предоставлены шаблоном процесса.

Примечание: Если во время создания нового группового проекта возникают какие-либо проблемы, мастер выводит сообщение об ошибке, описывающее проблему и предлагающее ее решение.

Заключение Если программное обеспечение создается по гибкой методологии, используйте шаблон процесса MSF Agile. Если группа следует методологии Capability Maturity Model Integration института Software Engineering Institute (SEI), применяйте шаблон MSF CMMI.

Ключевые компоненты архитектуры шаблона процесса – подключаемые модули шаблона процесса, XML-файлы описания процесса и мастер New Team Project.

Если стандартные шаблоны процессов не удовлетворяют требованиям вашего процесса, можно настроить шаблон, вручную изменяя XML-файлы описания процесса, или с помощью инструмента Process Editor (Редактор процесса).

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

Дополнительные источники      

О том, как выбрать шаблон процесса рассказывает статья «Choosing a Process Template» (Выбор шаблона процесса) (http://msdn2.microsoft.com/enus/library/ms400752(vs.80).aspx). Скачать шаблон процесса MSF CMMI можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB98-4EB4-BF6BFB5B266171EB&displaylang=en. Скачать шаблон процесса MSF Agile можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E828BF593C34D&displaylang=en. Более подробно о настраивании шаблонов процессов рассказывает статья «Process Template Customization Overview» (Как настраивать шаблоны процессов, обзор) (http://msdn2.microsoft.com/en-us/library/ms194945(VS.80).aspx). Скачать Team Foundation Server Power Tools, включая Process Template Editor можно по адресу http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx. Шаблоны процессов, предлагаемые партнерами Microsoft, представлены по адресу http://msdn2.microsoft.com/en-us/teamsystem/aa718801.

Глава 14 – Проекты MSF Agile Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Понять, когда должен использоваться шаблон процесса Microsoft® Solution Framework (MSF) для гибкой разработки ПО (MSF Agile). Выяснить, как обычно группы используют шаблон процесса MSF Agile. Настроить шаблон процесса MSF Agile соответственно конкретным требованиям группы.

Обзор Процесс, определенный шаблоном MSF Agile, объединяет в себе ключевые идеи гибкой разработки ПО и принципы и практики MSF. Этот процесс поддерживает стратегию гибкой разработки ПО, при которой приложения создаются на базе сценариев посредством множества итераций. Этот шаблон обеспечивает необходимые для коллективной разработки автоматизацию и управление, включая управление конфигурированием, управление проектом, отслеживание рабочих элементов и портал проекта для обмена информацией.

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

Как использовать данную главу Данная глава поможет лучше понять принципы работы шаблона процесса и руководства по процессу MSF Agile. Также в ней приведены примеры успешного использования этого шаблона процесса различными группами. Чтобы извлечь максимальную пользу из этой главы, следует:

  

Прочитать раздел «Стандартные элементы MSF Agile». Чтобы подробно разобраться и понять стандартные элементы шаблона процесса MSF Agile, включая стандартные отчеты, рабочие элементы и права доступа. Прочитать раздел «Примеры применения MSF Agile на практике». Чтобы увидеть, как MSF Agile успешно используется реальными группами для разработки и выпуска приложений. Прочитать Главу 13 «Шаблоны процессов». В Главе 13 «Шаблоны процессов» представлена общая информация о шаблонах процессов.

Последовательность операций для MSF Agile Шаблон процесса MSF Agile определяет набор задач, которые должны быть выполнены в ходе итераций различными участниками жизненного цикла разработки ПО, включая бизнес-аналитиков, архитекторов, руководителей проекта, разработчиков и тестировщиков. На рис. 14.1 показаны основные работы, связанные с каждой из описанных задач.

Задача

Основная работа

Создать перечень невыполненных работ по проекту

Создание концептуального представления проекта

Создать архитектуру решения

Создание прототипа архитектуры Определение интерфейсов Создание архитектуры инфраструктуры

Создать пользовательские сценарии использования

Выделение сценариев Фиксация сценариев в TFS Расстановка приоритетов сценариев

Создать нефункциональное требование

Определение целей в области безопасности Определение целей в области производительности Фиксация требований в TFS Расстановка приоритетов требований

Создать план итерации

Разбиение сценариев и требований на задачи разработки и тестирования Проведение оценки задач разработки и тестирования Планирование и распределение задач разработки и тестирования

Разработка в ходе итерации

Написание кода в рамках задач разработки Создание/обновление модульного теста для задачи разработки Выполнение модульных тестов и проведение анализа кода

Тестирование в ходе итерации

Написание тестов для проверки пригодности в рамках задач тестирования

Выполнение сценариев тестирования и проведение исследующего тестирования Создание дефектов в состоянии «Открыт» для выявленных проблем Проанализировать прогресс за итерацию

Оценка прогресса в выполнении задач за итерацию Сортировка дефектов, выявленных в ходе итерации Оценка граничных значений показателей тестирования

Рис. 14.1 Задачи и ключевые работы MSF Agile

Стандартные элементы MSF Agile При создании нового группового проекта с использованием шаблона процесса MSF Agile в основном окне Microsoft Visual Studio® отображается страница с основными положениями руководства по процессу. Это стартовая точка руководства по процессу MSF Agile. Данная информация также доступна с домашней страницы портала проекта.

Конфигурация инструментальных средств выходит за рамки описания процесса и включает рабочие элементы (такие как сценарии, нефункциональные требования (QoS), задачи, дефекты и риски), отчеты проекта, роли (группы и права доступа) и портал проекта. Шаблон MSF Agile поддерживает следующие основные элементы:

     

Рабочие элементы Группы и права доступа Систему контроля версий Области и итерации Отчеты Портал

В следующих разделах более подробно рассматриваются стандартные элементы шаблона процесса MSF Agile.

Рабочие элементы Шаблон процесса MSF Agile включает следующие типы рабочих элементов:



Дефект (Bug). Представляет проблему или потенциальную проблему приложения.

   

Риск (Risk). Представляет возможное событие или условие, которое могло бы иметь негативное воздействие на проект. Сценарий (Scenario). Представляет отдельную сюжетную линию взаимодействия пользователя с создаваемой системой. Задача (Task). Определяет конкретный элемент работы для члена группы. Нефункциональное требование (Quality of Service Requirement). Представляет нефункциональное требование, такое как безопасность, производительность или возможность обслуживания.

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

 





 



Настройка: Задание прав доступа (Set up: Set Permissions). Назначение этой задачи – распределить членов группы по четырем группам доступа: Сервисы сборки, Администраторы проекта, Участники или Читатели. Настройка: Миграция исходного кода (Set up: Migration of Source Code). Назначение этой задачи – перенос существующего исходного кода из Microsoft Visual SourceSafe®, если происходит перенос существующего проекта в Microsoft Visual Studio Team Foundation Server (TFS). Перенос кода должен быть завершен до предоставления членам группы возможности доступа к групповому проекту. Настройка: Перенос рабочих элементов (Set up: Migration of Work Items). При переносе существующего проекта в TFS можно переносить рабочие элементы, такие как дефекты и задачи из Clearquest или файл с разделенными запятыми значениями (comma-separated value, CSV). Этот перенос рабочих элементов должен быть завершен до предоставления членам группы возможности доступа к групповому проекту. Настройка: Задание политик регистрации изменений в файле в системе контроля версий (Set up: Set Check-in Policies). Назначение этой задачи – определение бизнес-правил или политик регистрации изменений исходного кода. Настройка: Конфигурирование сборки (Set up: Configure Build). Назначение этой задачи – первоначальное создание дерева исходного кода и настройка сборки на периодическое выполнение (обычно ежедневное). Настройка: Отправка почтового сообщения пользователям для установки проекта и начала работы над ним (Set up: Send Mail to Users for Installation and Getting Started). Назначение этой задачи – отправка членам группы сообщения по электронной почте с информацией о том, с каким TFS они должны установить соединение и над каким групповым проектом должны начать работу. Создание концептуального описания проекта (Create Vision Statement). Цель этой задачи – создание концептуального представления проекта, т.е. представления желаемого конечного результата проекта, одобренного всеми заинтересованными сторонами.





 

 

 

Настройка: Создание описания проекта на портале группового проекта (Set up: Create Project Description on Team Project Portal). Назначение этой задачи – изменить стандартное описание проекта, чтобы обеспечить лучшее описание нового группового проекта, например его назначения, целей или концептуального представления. Создание стереотипов пользователей (Create Personas). Назначение этой задачи – создание стереотипов, которые будут представлять пользователей, взаимодействующих с системой. Стереотипы пользователей могут использоваться как целевые пользователи системы при работе над эскизом проекта приложения. Определение длительности итерации (Define Iteration Length). Назначение этой задачи – определение итерационного цикла проекта, который зависит от размера и сложности проекта. Создание плана стратегии тестирования, включающего показатели качества поставляемого продукта (Create Test Approach Worksheet including Test Thresholds). Назначение этой задачи – понять стратегию тестирования в самом начале работы над проектом. Понимание используемого подхода тестирования может способствовать более эффективному планированию задач тестирования и позволит разработчикам реализовывать проект с учетом потребностей тестирования. Мозговой штурм и расстановка приоритетов в списке сценариев (Brainstorm and Prioritize Scenarios List). Цель этой задачи – определить и назначить приоритеты ключевых сценариев использования. Мозговой штурм и расстановка приоритетов в списке нефункциональных требований (Brainstorm and Prioritize Quality of Service Requirements List). Цель этой задачи – определить нефункциональные требования, такие как сценарии безопасности, производительности и возможности обслуживания. Настройка: Создание структуры проекта (Set up: Create Project Structure). Цель этой задачи – создание структуры проекта, отражающей области, в которых будет работать группа разработки. Создание плана итераций (Create Iteration Plan). Назначение этой задачи – принятие решения о распределении работ по разработке на итерации.

Отчеты С шаблоном процесса MSF Agile доступны следующие отчеты по умолчанию:

 

 

Дефекты по приоритетности (Bugs by Priority). Правильно ли были выявлены дефекты? Этот отчет показывает соотношение выявленных высокоприоритетных дефектов к выявленным дефектам с низким приоритетом. Частоты дефектов (Bug Rates). Насколько эффективно происходит выявление, исправление и закрытие дефектов? Данный отчет показывает общую тенденцию по выявлению новых дефектов, задержке исправления дефектов и исправлению дефектов. Сборки (Builds). Каково качество сборки? Данный отчет представляет список доступных сборок, включая информацию об их качестве и другие данные. Скорость выполнения проекта (Project Velocity). Насколько быстро группа выполняет работу? Данный отчет показывает, насколько быстро группа выполняет запланированную работу, и представляет темпы ежедневного изменения проекта.



   





   

Показатели качества (Quality Indicators). Каково качество ПО? Данный отчет сводит воедино результаты тестирования, дефекты, покрытие кода тестами и коэффициент изменения кода для удобства отслеживания качества и состояния проекта. Результаты нагрузочного тестирования (Load Test Summary). Данный отчет представляет результаты нагрузочного тестирования приложения. Регрессии (Regressions). Данный отчет представляет список всех тестов, которые ранее были пройдены успешно, но теперь дают сбой. Реактивации (Reactivations). Сколько рабочих элементов было реактивировано? Данный отчет показывает рабочие элементы, которые были разрешены или закрыты преждевременно. Взаимосвязанные рабочие элементы (Related Work Items). Какие рабочие элементы зависят от других рабочих элементов? Данный отчет представляет список рабочих элементов, связанных с другими рабочими элементами, что позволяет отследить зависимости. Оставшаяся работа (Remaining Work). Сколько еще работы надо сделать, и когда она будет завершена? Данный отчет показывает объем еще невыполненной, выполненной и завершенной работы с течением времени. Проецирование тенденций изменения объема оставшейся работы в будущее позволяет предсказать момент окончания работы над кодом. Незапланированная работа (Unplanned Work). Каков объем незапланированных работ? Данный отчет представляет соотношение общего объема работ к оставшемуся и распознает запланированную и незапланированную работу. Очередность работ (Triage). Для каких рабочих элементов необходимо установить очередность работ? В данном отчете представлены рабочие элементы, до сих пор находящиеся в состоянии «Предложенный». Рабочие элементы (Work Items). Какие рабочие элементы являются активными? В этом отчете представлен список всех активных рабочих элементов. Рабочие элементы по владельцу (Work Items by Owner). По сколько рабочих элементов назначено каждому члену группы? Данный отчет показывает распределение рабочих элементов по членам группы. Рабочие элементы по состоянию (Work Items by State). Сколько активных, разрешенных и закрытых рабочих элементов в проекте? Данный отчет представляет список активных, разрешенных и закрытых рабочих элементов.

Группы и права доступа В шаблоне процесса MSF Agile доступны следующие группы по умолчанию:

   

Читатели (Readers). Члены этой группы имеют права доступа только для чтения. Участники (Contributors). Члены этой группы могут добавлять, изменять и удалять элементы группового проекта. Сервисы сборки (Build Services). Члены этой группы обладают правами доступа к сервису сборки для группового проекта. Эта группа используется только для учетных записей сервисов. Администраторы проекта (Project Administrators). Члены этой группы могут осуществлять в групповом проекте все операции.

Система контроля версий MSF Agile использует следующие стандартные настройки системы контроля версий:





Изъятие версии файла для редактирования из системы контроля версий одновременно несколькими пользователями. По умолчанию MSF Agile допускает изъятие версии файла для редактирования из системы контроля версий одновременно несколькими пользователями, что обеспечивает возможность одновременной работы над одним файлом нескольких членов группы. Все возникающие в результате этого конфликты должны разрешаться в момент регистрации изменений. Права доступа. Права доступа к системе контроля версий по умолчанию: o Администраторы проекта. Обладают всеми правами доступа. o Сервисы сборки. Имеют права на чтение, задержку внесения изменения, регистрацию изменений, маркировку, начало сборки и редактирование сборки. o Участники. Имеют права на чтение, задержку внесения изменений, регистрацию изменений, изъятие версии файла для редактирования, маркировку и запуск сборки. o Читатели. Имеют право на доступ только для чтения.

Области и итерации Стандартный шаблон процесса MSF Agile не определяет структуру классификации ни для областей, ни для итераций. Рекомендуется выделять области, исходя из компонентов или функциональных возможностей проекта. За итерации можно принять временные циклы, для которых будет повторяться определенный набор основных действий, таких как планирование, разработка и тестирование.

Примеры применения MSF Agile на практике Следующие примеры показывают, как процесс MSF Agile был адаптирован и использован группой patterns & practices (шаблоны и практики) в рамках корпорации Microsoft, а также группой разработки, не входящей в состав Microsoft.

Пример 1: Группы patterns & practices Следующий пример представляет выполнение типового проекта группой patterns & practices с использованием процесса MSF Agile.

Новый проект, итерация 0 

Руководитель, ответственный за выпуск продукта: 1. Проводит сбор требований, взаимодействуя с заказчиками и основными заинтересованными сторонами, и фиксирует их в документе Microsoft Office Word под названием Project Back Log (Перечень невыполненных работ по проекту). 2. В Microsoft Office PowerPoint® создает концептуальное описание проекта. 3. Методом мозгового штурма совместно с заказчиками и различными заинтересованными сторонами определяет сценарии, которые



обеспечат выполнение требований и реализацию концептуального описания проекта. 4. Совместно с руководителем проекта и другими заинтересованными сторонами определяет приоритетность сценариев. Руководитель проекта: 1. Фиксирует сценарии как рабочие элементы в TFS. 2. В зависимости от размера проекта выбирает продолжительность итерационного цикла и объемы поставок.

Предварительное планирование  

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

Планирование итерации 

Руководитель проекта: 1. Совместно с разработчиками и другими членами группы разбивает сценарии на задачи разработки. 2. Фиксирует задачи разработки в TFS и связывает их со сценариями. 3. Определяет критерий приемки для каждой задачи разработки. 4. Разбивает требования QoS на задачи тестирования. 5. Фиксирует задачи тестирования в TFS и связывает их с QoS. 6. Определяет критерий приемки для каждой задачи тестирования. 7. Планирует и распределяет задачи между исполнителями.  Разработчик проводит предварительную оценку времени, необходимого на выполнение каждой из задач разработки. Важно – Если для реализации задачи (разрабатываемой пользовательской истории) по предварительным оценкам может потребоваться больше одного-двух дней, ее следует разбить на подзадачи. 

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

Во время итерации   

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

После итерации 

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



Руководитель, ответственный за выпуск продукта: 1. Добавляет вновь обнаруженные сценарии. 2. Пересматривает приоритеты сценариев (где это необходимо). 3. Совместно с руководителем проекта вырабатывает QoS-требования для проекта и связывает их со сценариями.

Пример 2: Привлечение конечного пользователя продукта Следующий пример показывает, как используется процесс MSF Agile в условиях привлечения конечного пользователя продукта.

Новый проект, итерация 0 



 



Бизнес-аналитик: 1. Создает краткое (в одну страницу) концептуальное представление проекта. 2. Выбирает пользователя в рамках своей организации, который может использоваться для получения исходных данных о продукте, и создает стереотипы пользователей системы. 3. Путем мозгового штурма совместно с пользователем вырабатывает сценарии (только названия). 4. Совместно с пользователем назначает приоритеты сценариев. 5. Пишет сценарии для следующей итерации. Руководитель проекта: 1. Собирает разработчиков и получает от них предварительные оценки времени, необходимого на разработку. Даются примерные оценки по порядку величин. 2. Проверяет, не приведет ли оценка затрат к изменению приоритетов. 3. Планирует сценарии для следующей итерации. Архитектор разбивает сценарии на архитектурные задачи. Разработчик: 1. Разбивает сценарии на задачи разработки. 2. Определяет подходящую стратегию сборки (использует сборку в результате процесса непрерывной интеграции, если это возможно). Тестировщик разбивает сценарии на задачи тестирования.

Во время итерации    

Руководитель проекта: 1. Управляет выполнением итерацией. 2. Управляет выполнением проекта. Архитектор определяет архитектуру решения. Разработчик, реализовывает задачу по разработке. Тестировщик, тестирует сценарий.

После итерации 0 В данной точке задачи немного меняются. 

Бизнес-аналитик: 1. Обновляет состав стереотипов пользователей системы (где это необходимо). 2. Добавляет все вновь выявленные сценарии.

  



3. Пересматривает приоритеты сценариев (где это необходимо). 4. Пишет сценарии для предстоящей итерации. Руководитель проекта: 1. Проводит предварительную оценку для каждого нового сценария. 2. Планирует сценарии для следующей итерации. Архитектор разбивает сценарии на архитектурные задачи. Разработчик: 1. Разбивает сценарии на задачи разработки. 2. Обновляет процесс сборки (с использованием процесса непрерывной интеграции, если возможно). Тестировщик разбивает сценарии на задачи тестирования.

Настройка шаблона процесса MSF Agile Существует два метода настройки шаблона процесса MSF Agile соответственно конкретным требованиям организации:





Настройка XML-файлов вручную. Настройка вручную чревата большим количеством ошибок, но, тем не менее, обеспечивает наиболее тонкую настройку шаблонов процессов. Более подробно об этом рассказывается в статье «Customizing Process Templates» по адресу http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx. Process Template Editor (Редактор шаблонов процессов). Самая последняя версия Visual Studio 2005 Team Foundation Server Power Tool ― это набор расширений, инструментов и утилит командной строки, улучшающих работу с TFS – предоставляет графическое средство для просмотра и настройки шаблонов процессов. Подключившись к TFS, можно использовать этот инструмент для настраивания описаний типов рабочих элементов и глобальных списков активного проекта. Более подробно смотрите в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server».

Заключение Шаблон процесса MSF Agile определяет набор задач, которые должны быть выполнены различными участниками жизненного цикла разработки ПО. Шаблон процесса MSF Agile поддерживает гибкую разработку и определяет рабочие элементы, группы и права доступа, систему контроля версий, области и итерации, отчеты и портал группы.

Если стандартный шаблон процесса не удовлетворяет требованиям конкретного процесса, его можно настроить двумя способами: вручную, настраивая XML-файлы описания процесса, или используя Process Editor Tool, поставляемый с TFS Power Tools.

Дополнительные источники 

Скачать шаблон процесса MSF Agile можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F48FB-824E-828BF593C34D&displaylang=en.

  

Скачать Team Foundation Server Power Tool, включая Process Template Editor, можно по адресу http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx. Более подробно о настройке шаблона процесса рассказывает статья «Process Template Customization Overview» (http://msdn2.microsoft.com/enus/library/ms194945(VS.80).aspx). Более подробно о настройке шаблонов процессов вручную смотрите в статье «Customizing Process Templates» (http://msdn2.microsoft.com/enus/library/ms243782(VS.80).aspx).

Часть VII Создание и отображение отчетов В данной части: 

Создание и отображение отчетов

Глава 15 – Создание и отображение отчетов Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи     

Описать архитектуру системы создания и отображения отчетов Microsoft® Visual Studio® Team Foundation Server (TFS). Определить, какие компоненты составляют систему создания и отображения отчетов TFS. Описать назначение каждого предоставляемого отчета. Выяснить, какие отчеты содержатся в каждом из шаблонов процессов. Настроить и создать новые отчеты.

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

Система создания и отображения отчетов TFS использует Microsoft SQL Server™ 2005 Reporting Services (сервисы создания и отображения отчетов) для создания, управления и формирования отчетов. В каждом шаблоне процесса имеется набор встроенных отчетов, которые развертываются в папку отчетов проекта при создании проекта. Используя Reporting Services, можно также изменять предоставляемые и создавать для проекта специальные отчеты. Новые отчеты можно сделать доступными для других групповых проектов, добавив их в существующий шаблон процесса.

Как использовать данную главу Данная глава описывает принципы работы системы создания и отображения отчетов TFS и то, как она может помочь в оценке состояния и статуса проекта. Чтобы использовать эту главу максимально эффективно, следует:

   

Прочитать раздел «Сценарии и решения». Понять общие причины использования системы создания и отображения отчетов TFS и узнать назначение каждого стандартного отчета. Прочитать раздел «Физическая архитектура». Узнать, какие компоненты образуют систему создания и отображения отчетов и как они взаимосвязаны между собой. Прочитать раздел «Как настраивать отчеты». Изучить механизмы, доступные для настраивания и создания отчетов. Прочитать сопроводительные статьи «Как…». Прочитать следующие сопроводительные статьи «Как…», в которых приводится пошаговый анализ и разбор различных процедур, обсуждаемых в данной главе. o Как: настроить отчет в Visual Studio Team Foundation Server o Как: создать специальный отчет для Visual Studio Team Foundation Server o Как: создать отчет о динамике рисков для Visual Studio Team Foundation Server

Сценарии и решения Отчеты являются основным средством получения информации о текущем состоянии проекта, находящегося в состоянии разработки. При создании нового группового проекта на основании выбранного шаблона процесса автоматически формируется набор отчетов. Эти отчеты можно найти на сайте портала проекта Microsoft Office SharePoint® или в узле отчетов в Team Explorer внутри Visual Studio.

Вот общие вопросы, на которые могут дать ответы отчеты TFS:

      

Когда приложение будет готово к поставке? Работы ведутся по плану? Каково качество сборки? Каков статус разработки заданных сценариев? Как скоро будут завершены работы по разработке? Осуществляется ли исправление дефектов? Возникают ли вновь уже устраненные дефекты?

Отчеты Team Foundation Server Каждый из шаблонов процессов Microsoft Solution Framework (MSF) для гибкой разработки ПО (MSF Agile) и MSF для совершенствования процесса согласно CMMI® (MSF CMMI) включает набор отчетов по умолчанию.

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





Дефекты по приоритетности (Bugs by Priority). Правильно ли были выявлены дефекты? Этот отчет показывает соотношение выявленных высоко приоритетных дефектов к выявленным дефектам с низким приоритетом. Он доступен в обоих поставляемых шаблонах процессов. Частоты дефектов (Bug Rates). Насколько эффективно происходит выявление, исправление и закрытие дефектов? Данный отчет показывает общую тенденцию по выявлению новых дефектов, задержке исправления дефектов и исправлению дефектов. Он доступен в обоих поставляемых шаблонах процессов.

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

 





Фактическое качество по отношению к запланированной скорости (Actual Quality versus Planned Velocity). Сколько сценариев можно реализовать, не потеряв при этом качества? Этот отчет представляет для каждой итерации отношение предполагаемого объема выполненных работ к общему качеству. Он доступен в обоих шаблонах процессов. Сборки (Builds). Каково качество сборки? Этот отчет представляет список доступных сборок с указанием их качества и другой информации по каждой сборке. Этот отчет доступен в MSF CMMI. Показатели качества (Quality Indicators). Каково качество ПО? Данный отчет сводит воедино результаты тестирования, дефекты, покрытие кода тестами и коэффициент изменения кода для удобства отслеживания качества и состояния проекта. Он доступен в MSF Agile и MSF CMMI. Скорость (Velocity). Насколько быстро группа выполняет работу? Данный отчет показывает, насколько быстро группа выполняет запланированную работу и представляет темпы ежедневного изменения проекта. Отчет доступен в MSF Agile и MSF CMMI. Детали сценариев (Scenario Details). По каким сценариям создается приложение? Этот отчет предоставляет информацию по каждому сценарию, включая данные о степени завершенности, рисках и ходе тестирования. Этот отчет доступен в MSF CMMI.

Тестирование Отчеты о тестировании позволяют отслеживать эффективность и ход тестирования. Предоставляются следующие отчеты о тестировании:

  

Регрессии (Regressions). Какие тесты уже были пройдены успешно, но теперь дают сбой? Данный отчет представляет список всех тестов, которые ранее были пройдены успешно, но теперь дают сбой. Отчет доступен в MSF CMMI. История тестирования требований (Requirements Test History). Насколько хорошо протестированы сценарии и требования? Этот отчет показывает ход тестирования заданных сценариев и требований. Он доступен в MSF CMMI. Непройденный тест без активного дефекта (Test Failure Without Active Bug). Всем ли сбоям поставлены в соответствие дефекты? Данный отчет показывает тесты, которые дали сбой, но не ассоциированы ни с одним открытым дефектом. Этот отчет доступен в MSF CMMI.





Открытый дефект для уже пройденного теста (Test Passing With Open Bug). Отвечает ли действительности список дефектов и соответствует ли он качеству приложения? Этот отчет показывает устаревшие дефекты, для которых ассоциированные с ними тесты уже пройдены. Отчет доступен в MSF CMMI. Результаты нагрузочного тестирования (Load Test Summary). Каковы результаты нагрузочного тестирования производительности приложения? Данный отчет представляет результаты нагрузочного тестирования приложения. Он доступен в MSF Agile.

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













 



Открытые проблемы и заблокированные рабочие элементы (Open Issues and Blocked Work Items Trend). Сколько еще осталось открытых проблем? Этот отчет показывает оставшиеся открытыми проблемы, а также тенденции по направлению к их решению. Отчет доступен в MSF CMMI. Реактивации (Reactivations). Сколько рабочих элементов было реактивировано? Данный отчет показывает рабочие элементы, которые были разрешены или закрыты преждевременно. Отчет доступен в MSF Agile и MSF CMMI. Взаимосвязанные рабочие элементы (Related Work Items). Какие рабочие элементы зависят от других рабочих элементов? Данный отчет представляет список рабочих элементов, связанных с другими рабочими элементами, что позволяет отследить зависимости. Отчет доступен в MSF CMMI. Что осталось сделать (Remaining Work). Сколько еще работы надо сделать, и когда она будет завершена? Данный отчет показывает объем еще невыполненной, выполненной и завершенной работы с течением времени. Проецирование тенденций изменения объема оставшейся работы в будущее позволяет предсказать момент окончания работы над кодом. Отчет доступен в MSF Agile и MSF CMMI. Очередность работ (Triage). Для каких рабочих элементов необходимо установить очередность работ? В данном отчете представлены рабочие элементы, до сих пор находящиеся в состоянии «Предложенный». Отчет доступен в MSF CMMI. Незапланированная работа (Unplanned Work). Каков объем незапланированных работ? Данный отчет представляет соотношение общего объема работ к оставшемуся, и распознает запланированную и незапланированную работу. Отчет доступен в MSF Agile и MSF CMMI. Рабочие элементы (Work Items). Какие рабочие элементы являются активными? В этом отчете представлен список всех активных рабочих элементов. Отчет доступен в MSF CMMI. Рабочие элементы по владельцу (Work Items by Owner). По сколько рабочих элементов назначено каждому члену группы? Данный отчет показывает распределение рабочих элементов по членам группы. Он доступен в MSF CMMI. Рабочие элементы по состоянию (Work Items by State). Сколько активных, разрешенных и закрытых рабочих элементов в проекте? Данный отчет

представляет список рабочих элементов, организованных по их состоянию. Он доступен в MSF CMMI.

Как настраивать отчеты Может возникнуть необходимость в отчете, который не представлен ни в одном из шаблонов процессов MSF. Существует три способа настройки отчетов:







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

Измененный существующий отчет или созданный с нуля новый отчет можно опубликовать на Report Server (сервере отчетов), что обеспечит возможность доступа к нему остальным членам группы. Изменять существующий отчет или создавать новый можно следующими методами:

 

Создать в Microsoft Office Excel® сводные таблицы данных из баз данных системы создания и отображения отчетов. Создать в Visual Studio новый проект Report Server и затем создавать новые отчеты или импортировать существующие.

Создание проекта Report Server в Visual Studio – наиболее мощный и гибкий метод создания и изменения отчетов.

Примечание: Можно использовать Report Builder, доступный с сайта системы создания и отображения отчетов группы; однако этот инструмент не поддерживается полностью сценариями создания и отображения отчетов Visual Studio и поэтому его применение не рекомендуется.

Дополнительная информация  

Более подробно о настройке существующего отчета смотрите в разделе «Как: настроить отчет в Visual Studio Team Foundation Server». Более подробно о создании специального отчета смотрите в разделе «Как: создать специальный отчет в Visual Studio Team Foundation Server».



Пошаговое руководство по созданию отчета о динамике рисков предлагается в разделе «Как: создать отчет о динамике рисков в Visual Studio Team Foundation Server».

Физическая архитектура Team Foundation Server создан на базе SQL Server 2005 и использует SQL Server Analysis Services (Сервисы анализа данных) для агрегации данных и формирования отчетов. Новые отчеты можно создавать с помощью Microsoft Excel или Visual Studio 2005 Report Designer. Отчеты размещаются на SQL Server 2005 Reporting Services, их можно просматривать с Веб-сайта сервера отчетов, SharePoint-портала проекта группы или из узла Reports в Team Explorer. На рис. 15.1 представлена физическая архитектура системы создания и отображения отчетов.

Рис. 15.1 Физическая архитектура системы создания и отображения отчетов

Каждый компонент TFS обслуживает собственный набор баз данных для обработки транзакций. Сюда входят рабочие элементы, система контроля версий, тесты, дефекты и Team Build. Эти данные собираются в реляционной базе данных и затем размещаются в кубе Online Analytical Processing (OLAP) (аналитическая обработка

данных в реальном масштабе времени) для обеспечения поддержки построения отчетов о тенденциях и более глубокого анализа данных.

Реляционная база данных TfsWarehouse – это хранилище данных, созданное для запроса данных, а не для транзакций. Из различных баз данных TFS, оптимизированных для обработки транзакций, данные передаются в это хранилище для составления отчетов. Оно не является основным хранилищем системы составления и отображения отчетов, но может использоваться для построения отчетов. Источник данных TfsReportDS указывает на реляционную базу данных. Team System Data Warehouse OLAP Cube – это база данных OLAP, доступ к которой осуществляется посредством SQL Server Analysis Services. Куб полезен для составления отчетов, обеспечивающих анализ данных в таких направлениях, как «сколько дефектов закрыто в текущем месяце по сравнению с предыдущим месяцем?» Источник данных TfsOlapReportDS указывает на Team System Data Warehouse OLAP Cube в базе данных Analysis Services.

Компоненты системы создания и отображения отчетов Система создания и отображения отчетов включает следующие серверные и клиентские компоненты.

Компоненты на стороне сервера К компонентам на стороне сервера относятся:    

Базы данных сервера отчетов. Эти базы данных содержат описания отчетов, предыдущие версии отчетов и конфигурационные данные. Веб-сервис сервера отчетов. Этот Веб-сервис предоставляет программный доступ к серверу отчетов. Веб-сайт управления отчетами. Этот сайт предоставляет пользователям доступ к Report Server посредством Веб-браузера. Служба Windows. Этот сервис обеспечивает создание и доставку по графику сохраненных экземпляров отчетов, построенных в определенный момент времени.

Компоненты на стороне клиента К компонентам на стороне клиента относятся:  

Окно просмотра. Этот компонент обеспечивает доступ к Веб-сайту управления отчетами. Team Explorer. Этот компонент обеспечивает доступ к отчетам посредством Visual Studio.

Инструментальные средства создания отчетов Инструментальные средства создания отчетов включают: 

Business Intelligence Designer Studio (BIDS). Этот компонент позволяет разработчикам проектировать и развертывать отчеты из Visual Studio 2005.

 

Excel. Excel может использоваться для формирования сводных таблиц данных хранилища системы создания и отображения отчетов. Построитель отчетов (Report Builder). Этот компонент позволяет конечным пользователям создавать специальные отчеты. Он не поддерживается полностью сценариями системы создания и отображения отчетов Team Foundation и не рекомендуется к использованию.

Заключение Шаблоны процессов MSF Agile и MSF CMMI предоставляют ряд стандартных отчетов по дефектам, управлению выпуском, тестированию и отслеживанию рабочих элементов:    

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

Чтобы изменить существующий отчет или создать новый, можно использовать Report Builder, доступный с сайта системы создания и отображения отчетов группы, с помощью Excel создать сводные таблицы данных из баз данных системы создания и отображения отчетов или создать новый проект Report Server в Visual Studio.

Дополнительные источники 

Более подробную информацию о Team Foundation Server Reporting можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx.

Часть VIII Настройка и обслуживание среды коллективной разработки В данной части:  

Развертывание Team Foundation Server Обеспечение доступа к Team Foundation Server через Интернет

Глава 16 – Развертывание Team Foundation Server Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи  

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

Обзор Данная глава рассматривает основные подходы к развертыванию Microsoft® Visual Studio® Team Foundation Server (TFS) и ключевые решения при развертывании TFS в организации. Здесь обсуждаются два варианта развертывания, и описывается, на основании чего принимается решение об использовании того или иного варианта развертывания.

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

Как использовать данную главу Эта глава поможет выбрать стратегию развертывания TFS. Чтобы использовать ее с максимальной пользой, следует:





Понять архитектуру TFS. Убедитесь, что вы полностью понимаете архитектуру TFS. Об архитектуре Team Foundation Server рассказывает раздел «Архитектура TFS». Более подробную информацию можно найти в Главе 2 «Архитектура Team Foundation Server». Выбрать стратегию развертывания. Выбрать стратегию развертывания, наиболее соответствующую нуждам вашей организации. Чтобы определиться, какая из стратегий лучше всего подойдет вашей группе, прочитайте раздел «Сценарии развертывания».

Архитектура TFS На рис. 16.1 представлена архитектура TFS.

Рис. 16.1 Архитектура TFS

Архитектура TFS образована тремя уровнями: уровнем данных, уровнем приложений и клиентским уровнем. Это лишь логическое разделение и все три уровня могут быть установлены на одном компьютере.

Для хранения рабочих элементов, данных системы контроля версий, результатов тестирования и всевозможных отчетов уровень данных TFS использует Microsoft SQL Server™.

Уровень приложений включает клиентский интерфейс на базе Веб-технологий, интегрированный в Internet Information Services (IIS), Веб-сервисы TFS и сервисы Microsoft Office SharePoint®. Также к уровню приложений относятся все серверы сборки и проксисерверы системы контроля версий.

Клиентский уровень – это приложения, осуществляющие доступ к TFS. Для соединения с Team Server разработчики используют Team Explorer, установленный как самостоятельный инструмент или как часть Visual Studio 2005. Руководители проектов используют Microsoft

Office Excel® или Microsoft Office Project. Также соединение с сервером можно осуществлять посредством инструментальных средств сторонних производителей.

Более подробно смотрите в Главе 2 «Архитектура Team Foundation Server».

Примечание: TFS 2005 и TFS 2008 обладают очень высокой степенью совместимости. При обновлении до TFS 2008 нет необходимости переводить всех клиентов на VS 2008. Также можно обновлять клиентов до VS 2008 без обновления серверов до TFS 2008.

Сценарии развертывания Развертывание TFS может выполняться по следующим схемам:

 

Развертывание на одном сервере o В рамках рабочей группы. o Используя службу каталогов Microsoft Active Directory®. Развертывание на двух серверах

Развертывание на одном сервере с использованием рабочей группы При таком подходе к развертыванию создается рабочая группа без контроллера домена Active Directory. Такой режим установки используется для маленьких групп. В этом режиме каждому пользователю для регистрации на сервере необходима локальная учетная запись. Для данного типа развертывания возможна установка только на одном сервере, установка на двух серверах не поддерживается.

Развертывание на одном сервере с Active Directory При наличии Active Directory возможны два варианта развертывания. Можно установить уровень данных и уровень приложений на одном сервере или на разных серверах.

Какой тип развертывания подходит для моей организации? Выбирая тип развертывания для своей организации, на одном или на двух серверах, необходимо ответить на следующие вопросы:

 

Сколько пользователей необходимо поддерживать? В TFS 2005 при количестве пользователей более 400 лучше прибегнуть к развертыванию на двух серверах. В TFS 2008 этот порог будет 450 пользователей. Сколько проектов будет поддерживать TFS? Если требуется поддерживать большое количество проектов, следует прибегнуть к развертыванию на двух серверах. Каждый экземпляр TFS может поддерживать до 500 проектов. Если требуется поддерживать более 500 проектов, рассмотрите возможность настройки нескольких экземпляров Team Foundation Server.



Есть ли в моем распоряжении сервер, который может быть полностью отдан под TFS? При развертывании Team Foundation Server на одном сервере сервер должен полностью выделяться под функциональность TFS. TFS не должен использоваться ни для каких других задач, он не должен быть почтовым сервером, сервером файлов или сервером баз данных для других приложений.

Преимущества развертывания на одном сервере Принимая решение о схеме развертывания, следует учитывать следующие преимущества развертывания на одном сервере:





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

Преимущества развертывания на двух серверах Принимая решение о схеме развертывания, следует учитывать следующие преимущества развертывания на двух серверах:





Масштабируемость. Схема развертывания на одном сервере обеспечивает работу до 400 пользователей в TFS 2005 и 450 пользователей в TFS 2008, тогда как развертывание на двух серверах позволяет увеличить количество пользователей до 2000 в TFS 2005 и до 2200 в TFS 2008. Передача нагрузки при сбое. В случае отказа или на время обслуживания можно перенаправить сервер уровня приложений на другой сервер уровня данных. Также можно конфигурировать и развернуть дополнительный сервер, который может выполнять роль резервного или дублирующего сервера уровня приложений.

Развертывание на одном сервере На рис. 16.2 представлено типовое развертывание на одном сервере. На сервере установлены уровни приложений и данных TFS, а также SharePoint Services и SQL Server.

Рис. 16.2 Типовая установка на одном сервере

Развертывание на двух серверах На рис. 16.3 представлена типовая установка на двух серверах. Уровень приложений TFS вместе с SharePoint Services установлен на одном сервере, а уровень данных TFS и SQL Server – на другом сервере.

Рис. 16.3 Типовая установка на двух серверах

Другие серверы При любой схеме развертывания, на одном или на двух серверах, можно установить отдельно сервер сборки и прокси-сервер. Они могут быть установлены как на одном сервере с уровнем приложений, так и на разных серверах.

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

Прокси-сервер Team Foundation Прокси-сервер Team Foundation кэширует копии файлов системы контроля версий. Проксисервер необходим, если доступ к серверу системы контроля версий осуществляется по сети и наблюдается большая задержка.

Топологии Team Foundation Server Приняв решение о типе развертывания, на одном или двух серверах, можно перейти к выбору топологии развертывания. Существует несколько топологий развертывания, от простой до сложной. Каждая топология разработана специально для групп с определенным количеством членов.

Простая топология На рис. 16.4 показана простая топология развертывания, при которой компоненты уровня приложений и данных TFS располагаются на одном сервере. Прокси-сервер TFS установлен на отдельном сервере. Сервер доступен с клиентских рабочих станций того же домена

Такая конфигурация подходит группам разработки или для пилотных проектов с количеством участников до 400 в TFS 2005 и до 450 в TFS 2008.

Рис. 16.4 Простая конфигурация Team Foundation Server

Топология средней сложности На рис. 16.5 представлен TFS, установленный на разных уровнях. Сервисы приложений развернуты на одном сервере, а базы данных – на другом сервере уровня данных.

Рис. 16.5 Топология Team Foundation Server средней сложности

На рис. 16.5 также показаны средства тестирования и серверы сборки, развернутые на отдельных серверах. Клиентские сервера или находятся в одном домене с этими серверами, или между ними и данными серверами установлены доверительные отношения. Топологии такого уровня сложности ориентированы на более крупные группы разработки от 450 до 3600 участников.

Сложная топология Сложная топология, представленная на рис. 16.6, подобна топологии среднего уровня сложности. Однако в данном случае появляются компоненты для передачи нагрузки при сбое в виде резервного сервера уровня приложений и уровень данных с технологиями кластеризации SQL.

Рис. 16.6 Сложная топология Team Foundation Server

На рис. 16.6 также показан дочерний домен, удаленный географически, использующий соединение с ограниченной полосой пропускания. Этот клиент использует прокси-сервер TFS для сокращения времени доступа к системе контроля версий.

Дополнительные рекомендации При развертывании TFS необходимо учесть следующее: 



Если принято решение разместить сайт Team Foundation Server SharePoint на уже установленном SharePoint-сервере, можно перенести сайт TFS SharePoint на другой сервер. Более подробно об этом рассказывается по адресу http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx. Перенос механизма аналитической обработки данных и OLAP-куба на третью машину доказал свою эффективность для больших групп. Можно настроить кластеризацию SQL на уровне данных и получить конфигурацию со всеми активными узлами с SQL на одном сервере и OLAP на другом, каждый из которых является резервным для своего двойника. Более подробно смотрите на http://msdn2.microsoft.com/enus/library/aa721760(vs.80).aspx и http://msdn2.microsoft.com/enus/library/ms252505(VS.80).aspx.

Примечание: TFS 2008 поддерживает Windows SharePoint Services v3 и Microsoft Office SharePoint Server 2007, выполняющиеся на любом из серверов, участвующих в развертывании.

Стратегия масштабирования и резервирования Team Foundation Server При установке и развертывании Team Foundation Server необходимо также принять решение о резервировании серверов и передаче нагрузки при сбое. Стратегии резервирования и передачи нагрузки выбираются в зависимости от размера установки, средств и ресурсов, доступных организации. Поскольку уровень данных использует SQL Server 2005, стратегии принимаются соответственно подходу, применяемому к резервированию SQL Server.

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

Выбор соответствующих стратегий установки и резервирования/восстановления для компании. При установке TFS необходимо принять несколько решений о стратегиях установки и резервирования/восстановления. Выбирая стратегию установки необходимо учитывать следующее:

     

Размер групп Количество проектов Размер проектов Дислокацию групп Необходимость в передаче нагрузки при сбое Необходимость резервирования

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

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

Конфигурация

Уровни

CPU

Жесткий диск

Память

Один сервер, менее 20 пользователей

Сервер уровня приложений и данных

Одиночный процессор, 2.2 гигагерца (GHz)

8 гигабайта (GB)

1 GB

Один сервер; от 20 до 100 пользователей

Сервер уровня приложений и данных

Два процессора, 2.2 GHz

30 GB

2 GB

Два сервера; от 100 до 250 пользователей

Сервер уровня приложений

Одиночный процессор, 2.2 GHz

20 GB

1 GB

Сервер уровня данных

Два процессора, 2.2 GHz

80 GB

2 GB

Сервер уровня приложений

Два процессора, 2.8 GHz

40 GB

4 GB

Сервер уровня данных

Четыре процессора, 2.7 GHz

Хранилище прямого доступа, RAID 0 массив дисковых накопителей с частотой вращения шпинделя 14 000 – 15 000 оборотов в минуту

16 GB

Два сервера; от 250 до 2000 пользователей

Таблица 16.1 Оборудование, необходимое для развертывания TFS

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

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

  

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

Здесь могут использоваться те же стандартные практики резервирования, которые применяются для любой базы данных SQL Server 2005.

Существует три сценария использования резервных копий для восстановления TFS:

  

Восстановление только данных. Полное восстановление при развертывании на одном сервере. Полное восстановление при развертывании на двух серверах.

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

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

Резервный сервер уровня приложений Хотя на серверах уровня приложений нет данных, для которых можно было бы создавать резервные копии, существует вероятность выхода сервера из строя. Чтобы уменьшить убытки от отказа, необходимо использовать «горячее» резервирование сервера и, тем самым, обеспечить возможность передачи нагрузки при сбое сервера уровня приложений.

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

Обеспечение передачи нагрузки при сбое усложняет установку и увеличивает затраты на обслуживание. При выборе стратегии среди остальных затрат обязательно необходимо учитывать и эти затраты на обслуживание.

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

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

Уровень данных

Кластеризация серверов уровня данных Если организация имеет необходимые ресурсы, следует рассмотреть возможность объединения используемых серверов в кластер. Кластер обеспечит непрерывный доступ к уровню данных. Однако стоит заметить, что требования к оборудованию при кластеризации высоки. Стоимость установки и обслуживания кластера с точки зрения ресурсов велика.

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

Кластер должен быть подготовлен к установке до установки TFS в кластер. Более подробно о кластеризации SQL Server 2005 рассказывается в материале «SQL Server 2005 Failover Clustering White Paper» (Техническое описание организации кластера для передачи нагрузки при сбоях SQL Server 2005), который можно скачать по адресу http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282c6830fead499&displaylang=en.

Зеркальное копирование серверов уровня данных Зеркальное копирование подразумевает синхронизацию данных одного сервера с копией этих данных на другом сервере. Сервер уровня данных – это основной сервер, сервер с копией данных – это резервный или зеркальный сервер. В случае выхода из строя сервера уровня данных можно вручную переключиться на зеркальный сервер.

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

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

TFS не поддерживает автоматическое переключение ролей, поэтому переключение должно выполняться вручную.

Чтобы конфигурировать зеркальное копирование SQL Server 2005 для уровня данных 1. 2. 3. 4. 5.

Создайте резервную копию всех баз данных и протокола транзакций. Создайте резервную копию ключа шифрования Reporting Services. Установите SQL Server 2005 на зеркальный сервер. Восстановите данные уровня данных на зеркальном сервере. Чтобы конфигурировать зеркальный сервер для каждой базы данных основного сервера уровня данных запустите Configure Database Mirroring Security Wizard (Мастер настройки безопасности зеркального копирования базы данных). 6. Начните зеркальное копирование.

Передача нагрузки при сбое зеркальному серверу Передача нагрузки зеркальному серверу выполняется вручную по следующей схеме: 1. На уровне приложений TFS a. Меняется конфигурация Report Service для использования другого сервера. b. Останавливается Веб-сайт по умолчанию. c. Останавливается Веб-сайт SharePoint. d. Останавливается сервис SharePoint Timer. e. Останавливается сервис TfsServerScheduler. f. Останавливается пул приложений ReportServer. g. Останавливается пул приложений TFS App Pool. 2. На зеркальном сервере уровня данных проверяется правильность добавленных учетных записей сервисов. 3. Выполняется перенос всех баз данных с основного сервера на зеркальный. 4. Создается хранилище данных на новом сервере. 5. Сервер уровня приложений конфигурируется для использования зеркального сервера следующим образом: a. Из окна командной строки запускается TFSAdminUtil RenameDT MirrorDataTierServer. b. Выполняется перезапуск IIS. c. Вносятся изменения в строки соединения Reporting Services, чтобы они ссылались на зеркальный сервер уровня данных. d. Вносятся изменения в SharePoint-сервер для использования зеркального сервера уровня данных e. Запускается сервис SharePoint Timer. f. Запускается сервис TfsServerScheduler. g. Запускается пул приложений ReportServer. h. Запускается пул приложений TFS App Pool. i. Запускаются Reporting Services. j. Выполняется запуск Веб-сервиса StampWorkItemCache.

Уровень приложений

Передача нагрузки при сбое на уровне приложений Настроив основной сервер уровня приложений, можно добавить компьютер «горячего» резерва, чтобы обеспечить возможность передачи нагрузки при сбое уровня приложений «нагорячо».

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

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

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

Передача нагрузки при сбое между серверами уровня приложений Передача нагрузки при сбое между серверами уровня приложений выполняется вручную. При выходе из строя основного сервера, необходимо вручную активировать сервер «горячего» резерва, выполнив шаги, представленные ниже. Чтобы передать нагрузку с основного сервера на резервном сервере можно выполнить утилиту TFSAdminUtil, передавая команду ActivateAT.

Чтобы передать нагрузку на сервер «горячего» резерва: 1. Активировав резервный сервер уровня приложений, переведите исходный сервер в автономный режим. 2. На резервном сервере a. Зарегистрируйтесь как администратор. b. Запустите TFSAdminUtil, передавая команду ActivateAT c. Запустите Веб-сервисы на резервном сервере. Эта команда   

Зарегистрирует имя сервера «горячего» резерва в базе данных сервисов интегрирования TFS. Соединит сервер «горячего» резерва уровня приложений с активным сервером уровня данных. Проверит соответствие соединенных серверов уровня приложений и уровня данных.

Более подробно об активации резервного сервера уровня приложений при передаче нагрузки не него рассказывается в статье «How to: Activate a Fail-Over Application-Tier Server» (Как: активировать резервный сервер уровня приложений) по адресу http://msdn2.microsoft.com/en-us/library/ms252501(VS.80).aspx.

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

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

Уровень приложений не поддерживает автоматической передачи нагрузки при сбое. Если необходимо обеспечить быструю передачу нагрузки, можно предоставить сервер «горячего» резерва и при сбое передавать на него нагрузку вручную.

Дополнительные источники   





 

Более подробно об установке TFS смотрите в статье «Visual Studio 2005 Team Foundation Installation Guide» (Руководство по установке Visual Studio 2005 Team Foundation) по адресу http://go.microsoft.com/fwlink/?linkid=40042. Более подробно о возможностях масштабирования TFS рассказывается в статье «Team Foundation Server Capacity Planning» (http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx). Подробнее о переносе OLAP-куба и механизма анализа на отдельный сервер рассказывает статья «How To: Move the Data Warehouse SQL Server Analysis Services Database to a Separate Server» (Как: перенести базу данных хранилища SQL Server Analysis Services на отдельный сервер) (http://msdn2.microsoft.com/enus/library/aa721760(vs.80).aspx). Чтобы получить подробную информацию о кластеризации SQL Server 2005, скачайте «SQL Server 2005 Failover Clustering White Paper» по адресу http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282c6830fead499&displaylang=en. Более подробно о создании кластера серверов SQL Server для передачи нагрузки при сбое рассказывает статья «How To: Create a New SQL Server 2005 Failover Cluster (Setup)» (Как: создать новый кластер серверов SQL Server 2005 для передачи нагрузки при сбое (настройка)) по адресу http://uat.technet.microsoft.com/enus/library/ms179530(SQL.90).aspx. Подробнее о том, как настроить кластер серверов SQL Server для уровня данных, рассказывается в статье «Clustering the Data-Tier Server» (Кластеризация сервера уровня данных) (http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx). О переносе сайта TFS SharePoint на другой сервер подробно рассказывает статья «Moving your TFS SharePoint site» (Перенос сайта TFS SharePoint) по адресу http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx.

 



 







 

Более подробную информацию о масштабируемости Team Foundation Server можно найти в блоге Брайана Гарри (Brian Harry) по адресу http://blogs.msdn.com/bharry/archive/2005/12/09/502190.aspx. Подробнее о планировании восстановления после сбоя рассказывает статья «Visual Studio Team System User Education» (Обучение пользователей Visual Studio Team System) по адресу http://www.microsoft.com/technet/itshowcase/content/vs05teamsystemnote.mspx. Более подробно о сбоях и восстановлении Team Foundation Server рассказывается в статье «Ensuring Team Foundation Server Availability» (Как гарантировать доступность Team Foundation Server) (http://msdn2.microsoft.com/engb/library/ms253159(VS.80).aspx). Кластеризация серверов уровня данных подробно рассматривается в статье «Clustering the Data-Tier Server» (http://msdn2.microsoft.com/en-gb/library/ms252505(VS.80).aspx). Зеркальное копирование уровня данных Team Foundation Server подробно рассматривается в статье «Mirroring the Team Foundation Data-Tier Server» (Зеркальное копирование Team Foundation Data-Tier Server) по адресу http://msdn2.microsoft.com/en-gb/library/aa980644(VS.80).aspx. Подробнее о конфигурировании зеркального копирования SQL Server для уровня данных рассказывает статья «How to: Configure SQL Server Mirroring for the Team Foundation Data-Tier Server» (Как: конфигурировать зеркальное копирование SQL Server для Team Foundation Data-Tier Server) по адресу http://msdn2.microsoft.com/enus/library/aa980629(VS.80).aspx. Более подробно о передаче нагрузки при сбое сервера уровня данных рассказывается в статье «How To: Fail Over to a Mirrored Data-Tier Server» (Как: передать нагрузку зеркальному серверу уровня данных) по адресу http://msdn2.microsoft.com/engb/library/aa980627(VS.80).aspx. Более подробно о передаче нагрузки при сбое сервера уровня данных в случае недоступности основного сервера рассказывается в статье «How To: Fail Over to a Mirrored Data-Tier Server if the Principal Data-Tier Server is Unavailable» (Как: передать нагрузку зеркальному серверу уровня данных, если основной сервер уровня данных недоступен) по адресу http://msdn2.microsoft.com/en-gb/library/aa980528(VS.80).aspx. Как активировать сервер уровня приложений при передаче нагрузки подробно рассказывается в статье «How To: Activate a Fail-Over Application-Tier Server» по адресу http://msdn2.microsoft.com/en-us/library/ms252501(VS.80).aspx. Как активировать сервер уровня приложений при передаче нагрузки подробно рассказывается в статье «Activating a Fail-Over Application-Tier Server» (Как активировать сервер уровня приложений для передачи нагрузки при сбое) по адресу http://msdn2.microsoft.com/en-us/library/ms252486(VS.80).aspx.

Глава 17 – Обеспечение доступа к Team Foundation Server через Интернет Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Задачи   

Изучить ключевые сценарии удаленного доступа и их применение. Предоставить удаленный доступ через Интернет к своему Microsoft® Visual Studio® 2005 Team Foundation Server (TFS). Повысить производительность удаленного доступа за счет использования Team Foundation Server Proxy.

Обзор Данная глава объясняет, как обеспечить удаленный доступ к TFS через Интернет. Существует три возможных варианта предоставления удаленного доступа к TFS:   

Через виртуальную частную сеть (virtual private network, VPN) Через обратный прокси-сервер, такой как Microsoft Internet Security and Acceleration (ISA) Server. Размещение TFS сервера во внешней сети.

До версии Service Pack 1 (SP1) TFS поддерживал только доступ через VPN. В TFS SP1 появляется поддержка Базовой аутентификации, что обеспечивает возможность, кроме VPN, использовать и внешнюю сеть, и обратный прокси-сервер.

Как использовать данную главу Данная глава поможет настроить сервер TFS для удаленного доступа через Интернет. Чтобы использовать эту главу с максимальной пользой, следует:  



Использовать список сценариев. Список сценариев поможет быстро определить, какой подход следует применить для обеспечения внешнего доступа через Интернет к серверу. Использовать приведенные пошаговые руководства. Данная глава предлагает пошаговые руководства по установке и конфигурированию доступа с использованием сертификатов и Протокола защищенных соединений (Secure Sockets Layer, SSL), используемых с базовой и сжатой аутентификациями. Использовать раздел «Повышение производительности удаленного доступа». В разделе «Повышение производительности удаленного доступа» приводятся методы сокращения объемов трафика, передаваемого по Интернет.

Ключевые стратегии Ключевыми стратегиями предоставления удаленного доступа к серверу TFS являются:

  

Использование соединения VPN. TFS располагается во внутренней сети, и внешние пользователи организовывают к нему доступ через VPN. Внутренние пользователи имеют прямой доступ к TFS. Публикация TFS через обратный прокси-сервер. TFS располагается во внутренней сети, и один или более обратных прокси-серверов, таких как ISA Server, передают TFS клиентские запросы из Интернет. Размещение TFS во внешней сети (сценарии установки на внешнем по отношению к организации сервере). Доступ к TFS осуществляют только внешние клиенты, и он размещается вне межсетевого экрана во внешней сети.

Стандартные сценарии 





Удаленный офис. Если поддерживаются удаленные пользователи с доступом через VPN, используется решение с VPN. Это самое простое из возможных решений с предельно понятной схемой безопасности, обеспечивающее удаленный доступ ко всем функциям TFS и позволяющее использовать TFS Proxy для повышения производительности. Внешняя группа. Если поддерживаются удаленные пользователи, не имеющие доступа через VPN или доступа к домену, используется сценарий с обратным прокси-сервером. Это решение сложнее реализовать, но оно обеспечивает удаленным пользователям возможность доступа к внутреннему TFS без необходимости использования VPN. Распределенное сообщество разработчиков. Если поддерживается сообщество удаленных пользователей, которые будут работать с предназначенным специально для них TFS, например, сайт для совместной разработки членами сообщества, используется внешняя сеть. Это решение обеспечивает наиболее глубокое разделение удаленных пользователей и внутренних сетевых ресурсов.

Использование соединения VPN Ни рис. 17.1 показана архитектура предоставления TFS через VPN.

Рис. 17.1 Архитектура предоставления TFS через VPN

При таком подходе удаленная группа разработки использует прямое VPN-соединение с TFS во внутренней сети. Для TFS без SP1 или если требуется Встроенная аутентификация Windows (Integrated Windows authentication), использование VPN-соединения является единственно возможным вариантом. TFS создан для работы в условиях малой полосы пропускания, каким является доступ через VPN, и обеспечивает приемлемую производительность при данном сценарии.

Преимущества   

Доступна вся функциональность TFS, включая TFS Proxy. Этот подход поддерживает Встроенную аутентификацию Windows и позволяет использовать существующую инфраструктуру организации. Если уже имеется установленная VPN, это самый простое из возможных решений.

Недостатки 

Решение VPN может быть не настроено для используемой инфраструктуры или, не доступно для удаленных пользователей.

Более подробно о создании VPN рассказывается на сайте http://support.microsoft.com/kb/324747.

Публикация TFS через обратный прокси-сервер При таком подходе сервер TFS устанавливается во внутренней сети и предоставляется для доступа из внешней сети посредством функциональности Веб-публикации ISA Server. Удаленные пользователи организовывают доступ к TFS через SSL и используют Базовую аутентификацию. Такой сценарий возможен только для TFS SP1.

Сети без контроллера домена в пограничной сети На рис. 17.2 представлена архитектура предоставления TFS посредством ISA с контроллером домена во внутренней сети.

Рис. 17.2 TFS через ISA, контроллер домена в архитектуре внутренней сети

Если в пограничной сети нет контроллера домена, в межсетевом экране можно открыть порт для обеспечения возможности соединения ISA Server с внутренним контроллером домена по протоколу Lightweight Directory Access Protocol (LDAP)7, в частности, для аутентификации внешних пользователей TFS.

Сети с контроллером домена в пограничной сети На рис. 17.3 показана архитектура предоставления TFS через ISA, когда контроллер домена располагается в пограничной сети.

Рис. 17.3 TFS через ISA, архитектура с контроллером домена в пограничной сети

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

7

Упрощенный протокол доступа к справочникам (прим. переводчика)

внутренних пользователей применяется Встроенная аутентификация Windows, и они имеют прямой доступ к TFS.

Преимущества   

Обратные прокси-серверы, такие как ISA Server, осуществляют аутентификацию пользователей и контролируют трафик. Удаленным пользователям нет необходимости осуществлять доступ к домену. Удаленным пользователям нет необходимости осуществлять доступ к VPN.

Недостатки      

TFS Proxy нельзя использовать на удаленной площадке. Удаленные пользователи не могут добавлять пользователей в группы TFS. Удаленные пользователи не могут добавлять группы Microsoft Active Directory® в папки системы контроля версий. Удаленные пользователи не смогут запустить или управлять сборками удаленно. Удаленные пользователи не могут создавать новые групповые проекты. Удаленные пользователи не могут публиковать результаты тестирования на TFS.

Примечание: Базовая аутентификация всегда должна использоваться совместно с SSL. При базовой аутентификации удостоверения передаются в виде открытого текста. SSL используется для защиты этой информации.

Размещение TFS во внешней сети (сценарий установки на внешнем по отношению к организации сервере) На рис. 17.4 представлена архитектура размещения TFS во внешней сети.

Рис. 17.4 Архитектура размещения TFS во внешней сети

При таком подходе вся инфраструктура TFS – и уровень приложений, и уровень данных – размещается в пограничной сети, вне внутренней сети. Все соединения с TFS, как внешних, так и внутренних пользователей, осуществляются через Интернет. TFS может работать с или без контроллера домена (domain controller, DC). Если пограничная сеть не имеет доступа к DC, сервис Active Directory TFS не будет функционировать. Например, без DC невозможно добавление пользователей в группы TFS или добавление группы Active Directory в папки системы контроля версий. Этот сценарий возможен лишь для TFS SP1.

Преимущества  

Внутренняя сеть полностью изолирована от пользователей TFS. Удаленные пользователи не нуждаются в доступе к домену.

Недостатки     

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

Примечание: Базовая аутентификация всегда должна использоваться совместно с SSL. При базовой аутентификации удостоверения передаются в виде открытого текста. SSL используется для защиты этой информации.

Базовая аутентификация / SSL Если для TFS SP1 требуется обеспечить поддержку сценария с использованием внешней сети или обратного прокси-сервера, необходимо конфигурировать IIS на уровне приложений TFS и тем самым активировать Базовую аутентификацию через SSL. При Базовой аутентификации регистрационные удостоверения передаются по Интернет в незащищенном формате Base64кодирования. Для защиты удостоверений клиентов Базовая аутентификация должна применяться только для соединений Secure HTTP (HTTPS), которые используют SSL.

Чтобы соединение удаленных клиентов с TFS через SSL происходило с Базовой аутентификацией, тогда как локальные клиенты продолжали использовать Встроенную аутентификацию Windows, необходим фильтр Server API (ISAPI). Фильтр ISAPI выбирает клиентов, которые были конфигурированы как «external/Internet» (внешний/Интернет) и возвращает в качестве отклика 401, чтобы заставить этих клиентов использовать другие методы аутентификации, например, Базовую аутентификацию.

Дополнительные источники 

Подробнее о том, как конфигурировать сервер для использования Базовой аутентификации и HTTPS, рассказывает статья «Walkthrough: Setting up Team Foundation





Server to Require HTTPS and Secure Sockets Layer (SSL)» (По шагам: как настроить Team Foundation Server на использование HTTPS and Secure Sockets Layer (SSL)) по адресу http://msdn2.microsoft.com/en-us/library/aa833873(VS.80).aspx. Как настраивать фильтр ISAPI подробно рассказывает статья «Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL) and an ISAPI Filter» (По шагам: как настроить Team Foundation Server с Secure Sockets Layer (SSL) и фильтром ISAPI) (.http://msdn2.microsoft.com/en-us/library/aa833872(VS.80).aspx). Больше информации о фильтрах ISAPI для TFS можно найти в сообщении «The TFS extranet ISAPI filter mechanics» (Принципы ISAPI-фильтра для работы TFS с внешними пользователями) блога Джеймса Маннинга (James Manning) по адресу http://blogs.msdn.com/jmanning/archive/2006/10/27/the-tfs-quot-extranet-quot-isapifilter-mechanics.aspx.

Прокси-сервер Team Foundation На рис. 17.5 показана архитектура, используемая с Team Foundation Server Proxy.

Рис. 17.5 Архитектура TFS Proxy

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

Как повысить производительность прокси-сервера Рассмотрим рекомендации по повышению производительности прокси-сервера: 









Убедитесь, что кэширование активировано, и отслеживайте производительность кэша. Регулярно проверяйте счетчики производительности (устанавливаемые по умолчанию) и протоколы событий (для ошибок и предупреждений) на своем прокси-сервере. Обратите внимание, что TFS Proxy сохраняет статистику по производительности кэша в XML-файле ProxyStatistics.xml, и что интервал сохранения статистических данных можно изменить. Файл ProxyStatistics.xml располагается в папке App_Data каталога установки прокси-сервера. Регулярно выполняйте плановый перенос самых последних файлов на прокси-сервер, таким образом, последние версии файлов гарантированно будут доступны в кэше прокси-сервера, и при последующих запросах к прокси-серверу клиенты будут получать именно эти файлы. Если известно, что предполагается загрузка больших файлов через канал с малой полосой пропускания (< 3 мегабита в секунду [Mbps]), задайте соответствующее значение атрибуту executionTimeout (пауза между выполнениями) в файле Web.config (по умолчанию это значение – один час, ). Если прокси-сервер выводится из эксплуатации на длительный период времени, необходимо дезактивировать прокси на клиентах, чтобы предотвратить бессмысленные попытки установления соединения. По умолчанию попытки установления соединения повторяются каждые пять минут. Рассмотрите возможность использования сокрытия рабочего пространства с целью предотвращения просмотра и ненужной передачи файлов из определенных рабочих пространств. Это обеспечит сокрытие папок заданных рабочих пространств от просмотра, уменьшит нагрузку на канал передачи и сохранит локальное дисковое пространство за счет предотвращения копирования в локальное рабочее пространство папок и файлов, которые не нужны в настоящее время. Хотя в своем рабочем пространстве можно скрыть существующее отображение папки, лучше специально для сокрытия создать новое отображение папки.

Более подробные рекомендации по оптимизации производительности можно найти в разделах «Распределенная / удаленная разработка» и «Рекомендации: рекомендации по работе с системой контроля версий» данного руководства.

Зеркальные учетные записи TFS Proxy поддерживается в удаленных организациях только через VPN-соединение. Однако если TFS был развернут для небольшой удаленной группы, которой необходим TFS Proxy, с использованием внешней сети или обратного прокси-сервера, для работы с прокси-сервисом можно использовать зеркальные учетные записи.

Для работы с прокси можно использовать учетные записи рабочих групп, в которых для TFS, TFS Proxy и всех остальных удаленных клиентских компьютеров используются одни и те же имена пользователя и пароли. Тот факт, что для всех пользователей должно сохраняться строгое соответствие имени пользователя/пароля в трех разных местах, увеличивает

временные затраты на администрирование и ограничивает применимость этого метода только для небольших удаленных групп.

Примечание: TFS 2008 позволяет выполнять аутентификацию пользователей на прокси VC с использованием их регистрационных удостоверений. Это делает применение учетной записи рабочей группы для прокси-сервиса VC привлекательным вариантом в средах, где невозможно использование VPN-соединения.

Дополнительные источники   

Подробнее о Proxy рассказывает статья «Team Foundation Server Proxy and Source Control» (Team Foundation Server Proxy и система контроля версий) по адресу http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx. Более подробно о работе с TFS Proxy рассказывается в статье «Managing Remote Connections to TFS Proxy» (Управление удаленными соединениями с TFS Proxy) (http://msdn2.microsoft.com/en-us/library/ms253156(VS.80).aspx). О поиске и устранении неисправностей TFS Proxy подробно рассказывается в статье «Troubleshooting TFS Server Proxy» (Поиск и устранение неисправностей TFS Server Proxy) по адресу http://msdn2.microsoft.com/en-us/library/ms400681(VS.80).aspx.

Удаленный сервер сборки На рис. 17.6 показана архитектура использования удаленного сервера сборки.

Рис. 17.6 Архитектура с удаленным сервером сборки

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

прокси-сервера перед каждой сборкой. Удаленный сервер сборки обладает следующими преимуществами:  

Сборки удаленной группы выполняются на сервере сборки этой группы и не оказывают влияния на нагрузку внутреннего сервера сборки. Удаленная группа получает двоичные файлы с удаленного сервера сборки без необходимости передачи двоичных файлов по сети.

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

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

Заключение Для TFS без SP1 удаленный доступ обеспечивается за счет использования VPN. При работе с TFS SP1 можно разместить TFS во внешней сети и использовать Базовую аутентификацию через SSL или можно предоставить доступ через обратный прокси-сервер.

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

Дополнительные источники 

 



Подробнее о настройке TFS для использования при удаленной разработке рассказывает статья «Walkthrough: Setting up TFS for a Remote Development Location» (По шагам: как настроить TFS для удаленной разработки) (http://msdn2.microsoft.com/en-us/library/ms242919(VS.80).aspx). Подробнее о настройке TFS с SSL рассказывается в статье «Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL)» (http://msdn2.microsoft.com/enus/library/ms242875(VS.80).aspx). Базовая и сжатая аутентификация на TFS подробно рассматривается в статье «Team Foundation Server, Basic Authentication, and Digest Authentication» (Team Foundation Server, Базовая аутентификация и сжатая аутентификация) по адресу http://msdn2.microsoft.com/en-us/library/aa833874(VS.80).aspx. Подробнее о TFS Proxy рассказывает статья «Team Foundation Server Proxy and Source Control» (http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx).

  

Более подробно о работе с TFS Proxy рассказывается в статье «Managing Remote Connections to TFS Proxy» (Управление удаленными соединениями с TFS Proxy) по адресу http://msdn2.microsoft.com/en-us/library/ms253156(VS.80).aspx. О поиске и устранении неисправностей TFS Proxy подробно рассказывается в статье «Troubleshooting TFS Server Proxy» по адресу http://msdn2.microsoft.com/enus/library/ms400681(VS.80).aspx. Более подробную информацию о проверке производительности TFS Proxy можно получить по адресу http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx.

Часть IX Visual Studio 2008 Team Foundation Server В данной части: 

Что нового в Visual Studio 2008 Team Foundation Server

Глава 18 – Что нового в Visual Studio Team System 2008 Team Foundation Server Microsoft® Visual Studio® Team System 2008 Team Foundation Server представляет ряд новых возможностей и функций. Основным изменениям подверглись:  

 

Администрирование, настройка и эксплуатация. Установка была упрощена с целью сокращения времени установки и улучшена для обеспечения поддержки большего числа сценариев развертывания. Сборка. Предусматриваются сборки в результате процесса непрерывной интеграции, плановые сборки и стандартные решения по управлению очередями сборок. Управление и расширяемость сборки были упрощены, теперь большее количество функциональных возможностей доступно из пользовательского интерфейса (UI). Система контроля версий. Получила намного лучшую поддержку работы в автономном режиме, также была улучшена ее производительность. Отслеживание рабочих элементов. Данная система включает усовершенствованный построитель запросов и улучшенную поддержку вложений рабочих элементов.

Все эти изменения перечислены и кратко описаны ниже. Также приводится таблица, объясняющая, как учитывать эти изменения в рекомендациях данного руководства. Эта глава поможет в планировании обновления Microsoft Visual Studio Team Foundation Server.

Администрирование, настройка и эксплуатация 



   

Упрощенная установка – По сравнению с Visual Studio 2005 TFS установка упрощена и ускорена. К улучшениям относятся устранение отдельной установки уровня данных, а также отмена требования доменной учетной записи. Team Foundation Server 2008 поддерживает использование встроенных учетных данных компьютера (таких как Network Service) везде, где это возможно. Поддержка SharePoint 2007 – Добавлена поддержка SharePoint 2007 и Windows SharePoint Services 3.0. Team Foundation Server 2008 будет поддерживать размещение SharePoint и Team Foundation Application Tier Server на разных серверах. Поддержка Windows Server 2008 – Поддерживается следующая версия Microsoft Windows Server™; например, Microsoft Windows Server 2008 и Internet Information Services (IIS) 7.0. Поддержка клиентских сертификатов X.509 – Поддерживается использование клиентских сертификатов X.509 для повышения безопасности аутентификации. Синхронизация большой группы – Улучшается производительность и надежность, обеспечивается возможность поддержки большого числа пользователей — до 2200 и более пользователей для одного экземпляра TFS. Поддержка именованных экземпляров SQL – Обеспечивается возможность совместного использования SQL Server несколькими экземплярами TFS или другими приложениями. Таким образом, разные экземпляры TFS смогут использовать одну и ту же установку SQL Server 2005.



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

Сборка 



  

   

 

 

Сборки в результате процесса непрерывной интеграции – Поддерживается создание условий запуска сборки, которые позволяют указывать в конфигурационном файле точное время начала сборки в результате непрерывной интеграции. Например, можно задать такие условия запуска, чтобы сборка выполнялась при каждой регистрации изменений, или можно настроить скользящую сборку, которая выполняется не чаще, чем через каждые Х минут. Поддержка организации очереди сборок – Поддерживается организация очереди сборок и управление очередью. Это особенно полезно для Процесса непрерывной интеграции, поскольку в результате частых регистраций изменений может возникнуть большая очередь сборок. Плановые сборки – Поддерживаются плановые сборки, график выполнения которых можно конфигурировать соответственно требованиям организации. Управление правилами хранения результатов сборки – Поддерживается управление правилами хранения результатов сборки, что обеспечивает возможность устанавливать политики автоматического удаления сборок. Задание свойств сборки – Обеспечивает возможность задавать для типа сборки используемый исходный код и его версии, а также другие свойства сборки. Предлагается большое количество свойств для настройки сборки. Кроме того, при помещении сборок в очередь могут передаваться параметры командной строки MSBuild. Расширяемость объектов сборки – Улучшена расширяемость объектов сборки. Например, теперь есть возможность без труда выполнять объекты перед и после сборки каждого решения или проекта Visual Studio. Управление сборкой – Появилась возможность останавливать и удалять сборки из Visual Studio. Конфигурирование сборки – Проще задавать тесты, выполняемые как часть сборки. Гибкость при выборе папки для размещения файла сборки проекта – Теперь не требуется, чтобы файл проекта MSBuild (и ассоциированного с ним rspфайла) обязательно хранился в папке TeamBuildTypes, он может располагаться в любой папке системы контроля версий Поддержка тестов GUI – Теперь тесты Графического пользовательского интерфейса (graphical user interface, GUI) могут выполняться как часть сборки. Политика регистрации изменений – Поддерживается новая политика регистрации изменений, которая запрещает пользователям регистрацию изменений в коде в случае, если сборка в результате непрерывной интеграции дает сбой. Управление сервером сборки – Улучшена возможность управления несколькими серверами сборки. Отображение рабочих пространств – Описание сборки может быть ассоциировано с «реальным» рабочим пространством, т.е. может использоваться код из нескольких групповых проектов, могут быть определены отображения на клиенте и т.д. Управление отображениями рабочих папок будет осуществляться не в файле workspacemapping.xml, а в GUI.

Система контроля версий  

  





 

Построчный анализ версий файлов (Annotate) – Поддерживается возможность при просмотре исходного кода видеть всю подробную информацию о том, кто вносил последние изменения в каждый раздел кода. Сравнение папок (Folder Diff) – Поддерживается сравнение папок, при котором содержимое папок рекурсивно сравнивается с целью выявления отличных файлов. Сравниваться могут только локальные папки, локальные папки с папками на сервере и папки на сервере с папками на сервере. Уничтожение – Поддерживается функция Destroy (уничтожение) с возможностью удаления файлов и папок из системы контроля версий. Уничтоженные файлы и папки не могут быть восстановлены. Получение последней версии при изъятии файла для редактирования – Включает опцию для загрузки последней версии файла при его изъятии для редактирования. Отображения рабочих пространств – Допускается отображение папки или файла под скрытой папкой и отображения с поддержкой групповых символов, таким образом, можно отображать все файлы в папке без отображения подпапок. Улучшение производительности – Внесено множество разнообразных изменений для улучшения производительности системы контроля версий по всем аспектам. Хотя для меньших серверов/проектов (< 10000 файлов) улучшения будут не так заметны, для больших проектов (в частности тех, где количество файлов исчисляется сотнями тысяч) разница будет ощутимой. Справка командной строки Team Foundation Server 2008– Поддерживается возможность получения Справки командной строки для инструмента tf. Справку можно получить, выполняя «tf help», и для отдельных команд – выполняя «tf command /help». Улучшения работы в автономном режиме– Улучшен процесс перехода в автономный режим и в Visual Studio Integrated Development Environment (IDE) добавлена встроенная возможность tfpt для возвращения в режим «online». Сохранение информации о переопределении политики регистрации изменений – Поддерживается внесение переопределений политики регистрации изменений в хранилище данных.

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

8

Улучшение работы с вложениями – Обеспечивается поддержка добавления вложения методом drag-and-drop и поддержка выбора нескольких файлов для вложения. Построитель запросов (Query Builder) – с Query Builder стало удобней работать за счет следующих новшеств: o Фильтрация выпадающего списка теперь выполняется на базе текущего проекта o Улучшенные списки MRU8 o Возможность переноса столбцов методом drag-and-drop o Сортировка нескольких столбцов через использование комбинации клавиш SHIFT + щелчок левой кнопки мыши

Most recent used – список последних по времени использования файлов (прим. переводчика)

Вопросы совместимости с Visual Studio 2005 Team System Клиент Visual Studio 2008 Team Foundation Server может работать с Visual Studio 2005 Team Foundation Server и клиент Visual Studio 2005 может работать с Visual Studio 2008 Team Foundation Server с учетом следующих моментов совместимости.  

Надстройки Visual Studio – Надстройки Visual Studio на стороне клиента должны быть перекомпилированы (или необходимо изменить их политику), потому что сборки Team Foundation Server Object Model (TFSOM) изменятся. Сборки проектов – Большинство операций – такие как составление списка описаний сборок, запуск и остановка сборок и проверка отчетов о сборках – будут дееспособны для сочетаний клиентов Visual Studio 2008 и сервера Visual Studio 2005 TFS. Известны следующие проблемы: 1. Экземпляр Visual Studio 2008 Team Foundation Server будет работать только с сервером сборки Visual Studio 2008 Team Foundation Server. 2. Чтобы клиент Visual Studio 2005 начал сборку на экземпляре Visual Studio 2008 Team Foundation Server, описание сборки должно храниться в папке $//TeamBuildTypes/. 3. Изменения, внесенные в свойства в файле tfsbuild.proj, хранящемся в базе данных на Team Foundation Server 2008, не будут обновлены в базе данных и не будут учтены при синхронизации. 4. При работе с функцией Непрерывной интеграции в Team Foundation Server 2008 клиент Visual Studio 2005 сможет начать сборку, но не сможет ставить ее в очередь, просматривать список сборок в очереди, просматривать список агентов сборок и т.д. 5. Используя клиент Visual Studio 2008 Team Foundation Server, невозможно создать новый тип сценария сборки на сервере Visual Studio 2005 TFS. 6. При использовании клиента Visual Studio 2008 Team Foundation Server нельзя изменить параметры диалогового окна для начала сборки Visual Studio 2005 Team Foundation Server.

Изменения в руководстве Руководство для Visual Studio 2005 Team Foundation Server

Руководство для Visual Studio 2008 Team Foundation Server

Развертывание на двух серверах будет поддерживать до 2000 пользователей.

Можно использовать развертывание на двух серверах для обеспечения поддержки до 2200 пользователей. Хорошее оборудование обеспечит поддержку до 3600 пользователей.

Для получения учетных записей сервиса TFS необходимы доменные учетные записи.

Доменные учетные записи больше не нужны, вместо них можно использовать встроенные учетные записи компьютера, например, учетная запись Network Service.

Используйте специальное решение для создания сборок в результате непрерывной интеграции.

Для создания и конфигурирования сборок в результате непрерывной интеграции или скользящих сборок могут использоваться условия запуска сборок Visual Studio.

Для определения качества сборки используйте автоматизированные тесты.

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

Типы сценариев сборок должны размещаться в специальной папке, чтобы Team Build мог распознать их.

Файлы проектов описания сборок (tfsbuild.proj) могут храниться где угодно в каталоге системы контроля версий.

Для создания плановых сборок используйте специальное решение.

Плановые сборки Visual Studio могут создаваться без специального решения.

Доступен ряд стандартных политик регистрации изменений.

Для дефектных сборок CI предлагается новая политика регистрации изменений. Согласно ей регистрация изменений в дефектных сборках запрещена.

Для перехода от VSS к Team Foundation Server используйте инструмент converter.exe.

Для создания решений по преобразованию и синхронизации между Team Foundation Server и другими системами контроля версий, включая VSS, используйте инструментарий Visual Studio.

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

Теперь Team Foundation Server 2008 разрешает отображение папки или файла под скрытой папкой и отображения с поддержкой групповых символов, таким образом можно отображать все файлы папки без отображения подпапок.

Для изменения отображения рабочего пространства используйте файл workspacemapping.xml

Для управления отображением рабочего пространства используется Team Foundation Server 2008 GUI, файл workspacemapping.xml больше не используется.

Для работы в автономном режиме используйте TFS Power Tool

Для работы в автономном режиме используйте Visual Studio IDE.

Получение последней версии файла и изъятие ее для внесения изменений являются двумя отдельными операциями системы контроля версий.

Есть специальная опция для автоматического получения последней версии файла при его изъятии для внесения изменений.

Настройте предварительные этапы сборки для получения зависимостей при использовании сборок проектов из другого группового проекта.

Шаблон рабочего пространства для описания сценария сборки управляется из VS GUI и обладает всей гибкостью, свойственной стандартному рабочему пространству, включая пути отображений из нескольких групповых проектов.

Для удаления сборок используйте инструмент командной строки TFSBuild.

Для остановки и удаления сборок используйте Visual Studio IDE.

Дополнительные источники 

Подробнее о Visual Studio 2008 Team Foundation Server рассказывает статья «An Overview of Microsoft Visual Studio Code Name "Orcas" White Paper» (Обзор Microsoft Visual Studio под кодовым названием "Orcas") по адресу http://go.microsoft.com/?linkid=6625887.

Рекомендации: Team Build Область применения  

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) Microsoft Visual Studio Team System

Содержание Стратегия      

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

Ветвление  

Использование новых типов сценариев сборки при неполном ветвлении. Изменение путей к решениям в файлах TFSBuild.proj при полном ветвлении.

Политики регистрации изменений  

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

Сборки в процессе непрерывной интеграции   

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

Настройка   

Использование специального этапа после сборки для сборки проекта создания пакета установки приложения. Использование дополнений MS Build Toolkit Extras для сборки приложений Microsoft .NET 1.1. Использование TFSBuild.proj для изменения сценария сборки.



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

Развертывание 

Установка сервисов сборки на отдельном сервере для больших групп.

Производительность    

Использование инкрементных сборок для повышения производительности. Как избежать синхронизации ненужных папок при сборке. Использование рабочих пространств во избежание извлечения ненужных папок и проектов при сборке группового проекта. Использование нескольких серверов сборки для повышения производительности сборки.

Проекты      

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

Плановые сборки 

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

Разработка через тестирование   

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

Рабочие элементы 

Использование рабочих элементов для отслеживания дефектов сборки.

Стратегия      

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

Использование плановой сборки для обеспечения регулярности сборки Используйте плановую сборку для создания сборок через постоянные предсказуемые интервалы времени.

Группа тестирования и другие группы должны получать надежные сборки с заданной периодичностью. Это обеспечивает регулярную обратную связь по сборке.

Team Build в Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) не поддерживает выполнение плановых сборок из пользовательского интерфейса. Для запуска сборок в заданное время можно использовать Microsoft Windows® Task Scheduler и утилиту командной строки TFSBuild.

Примечание: Пользователи TFS 2008 могут планировать сборки прямо в Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать расписание сборки.

Чтобы создать плановую сборку

1. Создайте следующую командную строку TFSBuild: TfsBuild start

2. Поместите командную строку в командный файл.

3. Создайте Windows Scheduled Task, которая будет выполнять командный файл с заданной периодичностью.

Дополнительные источники  

Подробнее о настройке плановых сборок в Team Build рассказывает Глава 9 «Настройка плановых сборок в Team Build» данного руководства. Подробнее о настройке плановых сборок в TFS рассказывает раздел «Как: настроить плановую сборку в Visual Studio Team Foundation Server» данного руководства.

Использование сборки в процессе непрерывной интеграции для быстрого получения обратной связи при регистрации изменений Используйте сборки в процессе непрерывной интеграции (CI-сборки), чтобы обеспечить группе разработки быструю обратную связь по любым изменениям, приводящим к сбоям, и по качеству сборки после каждой регистрации изменений. Таким образом, группа разработки сможет быстро устранять возникающие проблемы и повышать качество кода.

Team Foundation Server 2005 не обеспечивает стандартного CI-решения, но предлагает разработчику инфраструктуру для реализации собственного решения CI-сборки.

Подробнее о настройке CI-сборки в TFS рассказывается в разделе «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server». В нем используется решение, предоставленное группой разработки Microsoft Visual Studio Team System (VSTS). Это решение устанавливает Веб-сервис, который выполняется под учетной записью, имеющей доступ к серверу TFS. Team Foundation Server при возникновении определенных событий может посылать сообщение электронной почты или вызывать Веб-сервис. Такой механизм событий используется решением CI для подписки Веб-сервиса на событие CheckinEvent. Таким образом, каждый раз при возникновении события регистрации изменений Веб-сервис запускает Team Build.

Примечание: Пользователи TFS 2008 могут конфигурировать процесс непрерывной интеграции из Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать активацию сборок по событию регистрации изменений.

Дополнительные источники 

Развернутая информация представлена в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

   

Подробнее о настройке CI-сборки рассказывает раздел «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server» данного руководства. Подробнее об использовании CI-решения VSTS рассказывается в статье «Continuous Integration Using Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx. Скачать пакет установки (MSI) CI-решения VSTS можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de0e81d3de2482/ci.msi. Более подробно о гибкой разработке и CI в TFS можно прочитать в статье «Extend Team Foundation Server To Enable Continuous Integration» по адресу http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx.

Использование скользящей сборки в случаях, когда сборка в процессе непрерывной интеграции негативно отражается на производительности сервера сборки Выполнение сборки непосредственно после каждой регистрации изменений – самая простая стратегия CI, как правило, обеспечивающая самую оперативную обратную связь. Однако если регистрации изменений имеют место довольно часто, сервер сборки может не справиться с нагрузкой. Тогда следует использовать скользящие сборки, которые выполняются после заданного числа регистраций изменений или через заданный промежуток времени. При принятии решения о необходимости использования скользящей сборки, необходимо принять во внимание следующие факторы:

  

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

Если продолжительность сборки превышает среднюю частоту регистраций изменений, сборки будут выполняться непрерывно, потому что предыдущая сборка не будет успевать завершаться до следующей регистрации изменений, которая дает начало последующей сборке. Это может иметь негативное воздействие на производительность сервера сборки и блокировать другие сборки (например, плановые сборки). Необходимо выяснить, в какой промежуток времени регистрации выполняются особенно часто, и определить, будут ли CI-сборки мешать выполнению плановых или других важных сборок.

Дополнительные источники 

Подробнее об этом рассказывается в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

Использование ветвления для сокращения сбоев при сборке Во избежание сбоев при сборке активную разработку следует вести в ветви Development, а интеграционную сборку выполнять в ветви Main.

Вот пример структуры ветвления после создания ветви Development:

 

Development – Ветвь разработки o Source Main – Ветвь интеграции o Source – исходный код o Other Assets folders – папки других ресурсов

Рекомендации по работе с ветвью выпускаемой версии: 





 

Когда выполнять ветвление. Если при создании ежедневной сборки возникают проблемы со стабилизацией сборки и интеграцией, следует создать главную ветвь и ветвь разработки, что гарантирует большую предсказуемость ежедневных сборок. Также для повышения качества регистрируемого кода, можно ввести более строгие политики регистрации изменений. Когда не стоит прибегать к ветвлению. Если создаются только CI-сборки или ежедневные сборки уже предсказуемо стабильны, возможно, нет необходимости нести дополнительные издержки по содержанию ветви интеграции. Права доступа при работе с ветвями: o Разработчики, ответственные за слияние и интеграцию, должны иметь право на чтение/запись в ветвь Main, но все остальные – только право на чтение. o Право на чтение/запись в ветвь Dev должно быть у всех. Частота сборки: o Ежедневные сборки для ветви Main. o CI-сборки для ветви Dev. Тестирование: o Для ветви Main выполняются интеграционное тестирование, тестирование производительности и безопасности. o Для ветви Dev выполняется функциональное и тестирование для получения быстрой обратной связи.

Ветвь Main используется как среда опытной интеграции изменений, зарегистрированных в ветви разработки. Вся активная разработка осуществляется в ветви Dev, и не приводящие к сбоям изменения интегрируются в ветвь Main.

Дополнительные источники  

Подробнее о выборе стратегии ветвления и слияния рассказывает Глава 5 «Выбор стратегии ветвления и слияния» данного руководства. Вводную информацию по ветвлению и слиянию можно найти в материале «Branching and Merging Primer» по адресу http://msdn2.microsoft.com/enus/library/aa730834(VS.80).aspx.

  

Более подробно о ветвлении рассказывает статья «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/enus/library/ms181425(VS.80).aspx. Более подробно о слиянии рассказывает статья «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/enus/library/ms181428(VS.80).aspx. Дополнительное описание процесса ветвления и слияния в Visual Studio 2005 можно найти в статье «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

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

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

Чтобы активировать политику анализа кода при регистрации изменений для группового проекта, щелкаем правой кнопкой мыши групповой проект в Team Explorer, выбираем Team Project Settings (Настройки группового проекта) и щелкаем Source Control (Система контроля версий). Выбираем вкладку Check-in Policy (Политика регистрации изменений), нажимаем Add и выбираем и конфигурируем соответствующую политику.

Дополнительные источники 





Подробнее о создании и использовании специальной политики регистрации изменений рассказывает раздел «Как: Создавать специальные политики регистрации изменений в коде в Visual Studio Team Foundation Server» данного руководства. О том, как настраивать политику регистрации изменений, расскажет статья «Walkthrough: Customizing Check-in Policies and Notes» (По шагам: как настроить политики регистрации изменений и комментарии к ним) по адресу http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx. Увидеть пример кода, который не допустит регистрации файлов, содержащих определенные шаблоны, можно в статье «Checkin Policy to Disallow Certain Patterns» (Политика регистрации изменений, запрещающая определенные шаблоны) по адресу http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx.





Увидеть пример кода, который требует обязательного ввода комментариев при регистрации изменений, можно в статье «Sample Checkin Policy: Make Sure the Comment Isn’t Empty» (Пример политики регистрации изменений: гарантируем непустой комментарий) по адресу http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx. Как добавить новую политику регистрации изменений можно узнать в статье «I’ve Made a New Check-In Policy! How Do I Add It?» (Я создал новую политику регистрации изменений! Как ее добавить?) по адресу http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx.

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

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

Дополнительные источники 



Подробнее об уведомлениях о завершении сборки рассказывается в статье «How to: Receive Build Notification E-Mail» (Как: настроить получение сообщений о завершении сборки по электронной почте) по адресу http://msdn2.microsoft.com/en-us/library/ms181725(VS.80).aspx. Дополнительную информацию об уведомлениях о завершении сборки можно найти в статье «How to: Add or Edit Alerts» (Как: Добавлять или редактировать уведомления) по адресу http://msdn2.microsoft.com/enus/library/ms181335(VS.80).aspx.

Ветвление  

Использование новых типов сценариев сборки при неполном ветвлении. Изменение путей к решениям в файлах TFSBuild.proj при полном ветвлении.

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

Существует два типа неполных ветвей: 

Неполная ветвь, не включающая типы сценариев сборки. Имеет место в рамках группового проекта и просто включает в новые папки ветви решения и исходные файлы, но не включает папки TeamBuildTypes.



Неполная ветвь, включающая типы сценариев сборки. Имеет место в рамках группового проекта и, кроме других папок, содержащих соответствующее решение и исходные файлы, включает некоторые подпапки TeamBuildTypes (т.е. типы сценариев сборки).

При создании неполной ветви, которая не включает Team Build Types, все существующие Team Build останутся работоспособными, но для сборки кода данной ветви придется создать новый Team Build Type. Новые типы сценариев сборки создаются с помощью мастера Team Build Wizard (Мастер сценариев сборки). Вновь создаваемые типы сценариев сборки будут указывать на местоположение новой ветви, а также могут указывать на родительскую ветвь для решений, которые должны быть включены в сборку, но не имеют собственной ветви.

При создании неполной ветви, включающей Team Build Types, скопированные типы сценариев сборки будут указывать на исходную, родительскую ветвь и поэтому не обеспечат сборку новой ветви. В типы сценариев сборки необходимо внести изменения, чтобы они указывали на новую ветвь кода.

Дополнительные источники 

Подробнее об обновлении типов сценариев сборки рассказывает статья «How to: Update Build Types on Branched Team Projects» (Как: Обновлять типы сценариев сборки в ветвях групповых проектов) по адресу http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx.

Изменение путей к решениям в файлах TFSBuild.proj при полном ветвлении При создании новой ветви, включающей Team Build Types, пути в типах сценариев сборки по-прежнему указывают на предыдущее местоположение кода. Применять сценарии сборки для новой ветви можно только после обновления путей в файлах проектов типов сценариев сборки, чтобы они указывали на новые, возникшие после операции ветвления, каталоги.

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

Чтобы обновить типы сценариев сборки, откройте их файлы из соответствующей ветви, внесите изменения и зарегистрируйте изменения в данной ветви.

Дополнительные источники 

Более подробно об обновлении типов сценариев сборки рассказывает статья «How to: Update Build Types on Branched Team Projects» по адресу http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx.

Политики регистрации изменений  

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

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

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

Дополнительные источники 

 





Подробнее о создании и использовании специальной политики регистрации изменений рассказывает раздел «Как: создавать специальные политики регистрации изменений в коде в Visual Studio Team Foundation Server» данного руководства. О том, как настраивать политику регистрации изменений, расскажет статья «Walkthrough: Customizing Check-in Policies and Notes» по адресу http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx. Увидеть пример кода, который не допустит регистрации файлов, содержащих определенные шаблоны, можно в статье «Checkin Policy to Disallow Certain Patterns» по адресу http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx. Увидеть пример кода, который требует обязательного ввода комментариев при регистрации изменений, можно в статье «Sample Checkin Policy: Make Sure the Comment Isn’t Empty» по адресу http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx. Как добавить новую политику регистрации изменений можно узнать в статье «I’ve Made a New Check-In Policy! How Do I Add It?» по адресу http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx.

Использование политик регистрации изменений для ассоциирования рабочих элементов со сборкой Задайте политику связи регистрации изменений с рабочими элементами, что заставит разработчиков ассоциировать регистрацию изменений с рабочим элементом.

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

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

Дополнительные источники 



Подробнее о создании и использовании специальной политики регистрации изменений рассказывается в разделе «Как: создавать специальные политики регистрации изменений в коде в Visual Studio Team Foundation Server » данного руководства. О том, как настраивать политику регистрации изменений, рассказывается в материале «Walkthrough: Customizing Check-in Policies and Notes» по адресу http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx.

Сборки в процессе непрерывной интеграции   

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

Использование сборки в процессе непрерывной интеграции для быстрого получения обратной связи при регистрации изменений Используйте сборки в процессе непрерывной интеграции (CI-сборки), чтобы обеспечить группе разработки быструю обратную связь по любым изменениям, приводящим к сбоям, и по качеству сборки после каждой регистрации изменений. Таким образом, группа разработки сможет быстро устранять возникающие проблемы и повышать качество кода.

Team Foundation Server 2005 не обеспечивает стандартного CI-решения, но предлагает разработчику инфраструктуру для реализации собственного решения CI-сборки.

Подробнее о настройке CI-сборки в TFS рассказывается в разделе «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server». В нем используется решение, предоставленное группой разработки Microsoft Visual Studio Team System (VSTS). Это решение устанавливает Веб-сервис, который выполняется под учетной записью, имеющей доступ к серверу TFS. Team Foundation Server при возникновении определенных событий может посылать сообщение электронной почты или вызывать Веб-сервис. Такой механизм событий используется решением CI для подписки Веб-сервиса на событие CheckinEvent. Таким образом, каждый раз при возникновении события регистрации изменений Веб-сервис запускает Team Build.

Примечание: Пользователи TFS 2008 могут конфигурировать процесс непрерывной интеграции из Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать активацию сборок по событию регистрации изменений.

Дополнительные источники     

Развернутая информация представлена в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства. Подробнее о настройке CI-сборки рассказывает раздел «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server» данного руководства. Подробнее об использовании CI-решения VSTS рассказывается в статье «Continuous Integration Using Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx. Скачать пакет установки (MSI) CI-решения VSTS можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de0e81d3de2482/ci.msi. Более подробно о гибкой разработке и CI в TFS можно прочитать в статье «Extend Team Foundation Server To Enable Continuous Integration» по адресу http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx.

Использование скользящей сборки в случаях, когда сборка в процессе непрерывной интеграции негативно отражается на производительности сервера сборки Выполнение сборки непосредственно после каждой регистрации изменений – самая простая стратегия CI, как правило, обеспечивающая самую оперативную обратную связь. Однако если регистрации изменений имеют место довольно часто, сервер сборки может не справиться с нагрузкой. Тогда следует использовать скользящие сборки, которые выполняются после заданного числа регистраций изменений или

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

  

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

Если продолжительность сборки превышает среднюю частоту регистраций изменений, сборки будут выполняться непрерывно, потому что предыдущая сборка не будет успевать завершаться до следующей регистрации изменений, которая, в свою очередь, даст начало последующей сборке. Это может иметь негативное воздействие на производительность сервера сборки и блокировать другие сборки (например, плановые сборки). Необходимо посмотреть, в какой промежуток времени регистрации выполняются особенно часто, и выяснить, будут ли CI-сборки мешать выполнению плановых или других важных сборок.

Дополнительные источники 

Подробнее об этом рассказывается в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

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

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

Дополнительные источники 

Подробнее о CI-сборках рассказывается в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

Настройка    

Использование специального этапа после сборки для сборки проекта создания пакета установки приложения. Использование дополнений MS Build Toolkit Extras для сборки приложений Microsoft .NET 1.1. Использование TFSBuild.proj для изменения сценария сборки. Использование специального этапа перед сборкой для сборки проекта, имеющего связи с другим групповым проектом.

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

Дополнительные источники 

Подробнее смотрите в статье «Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project» (По шагам: Конфигурирование Team Foundation Build для сборки проекта создания пакета установки приложения Visual Studio) по адресу http://msdn2.microsoft.com/enus/library/ms404859(VS.80).aspx.

Использование дополнений MS Build Toolkit Extras для сборки приложений Microsoft .NET 1.1 Team Build не поддерживает по умолчанию приложения .NET 1.1. MSBuild Extras – комплект инструментов для .NET 1.1 (MSBee), обеспечивающий возможность сборки приложений .NET 1.1. Для этого требуется, чтобы проекты и решения были обновлены до Visual Studio 2005. Если такое обновление невозможно, для компиляции приложений .NET 1.1 можно использовать специальный этап после сборки.

Дополнительные источники  

Скачать MSBee можно по адресу http://www.codeplex.com/MSBee. Подробнее о создании специального этапа после сборки для компиляции приложения .NET 1.1 application рассказывается в блоге Нагараджу по адресу http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx.

Использование TFSBuild.proj для изменения сценария сборки Чтобы изменить данные сборки – например, сервер сборки, место публикации результатов сборки или каталог сборки – необходимо редактировать файл TFSBuild.proj.

Файл TFSBuild.proj содержит большую часть информации, необходимой для выполнения Team Build. Сюда относятся места публикации результатов сборки и данные о том, должны ли проводиться для сборки статический анализ кода и

модульное тестирование. Сценарий сборки изменяется путем редактирования файла TFSBuild.proj.

Чтобы редактировать файл TFSBuild.proj

1. Версия файла изымается из системы контроля версий. 2. В нем обновляются данные сборки. 3. Файл возвращается в систему контроля версий, внесенные в него изменения регистрируются.

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

Дополнительные источники 

Подробнее о настройке Team Foundation Build рассказывает статья «Customizing Team Foundation Build» (Настройка Team Foundation Build) по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

Использование специального этапа перед сборкой для сборки проекта, имеющего связи с другим групповым проектом Team Build не поддерживает сборку решений, объединяющих несколько групповых проектов. Чтобы реализовать такой сценарий, нужно соответствующим образом настроить файл TFSBuild.proj, чтобы необходимый код других проектов изымался из системы контроля версий.

Дополнительные источники  

Подробнее об этом рассказывает статья «Working with multiple team projects in Team Build» по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx. Более подробную информацию о настройке Team Foundation Build можно найти в статье «Customizing Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

Развертывание 

Установка сервисов сборки на отдельном сервере для больших групп.

Установка сервисов сборки на отдельном сервере для больших групп Team Build больших проектов может занимать много времени и существенно загружать ресурсы сервера. Если сборки выполняются на TFS вашей группы, страдают надежность, производительность и масштабируемость сервера.

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

Дополнительные источники 

Скачать «Team Foundation Installation Guide» и получить более подробную информацию об установке TFS и Team Build можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilyId=E54BF6FF-026B-43A4ADE4-A690388F310E&displaylang=en.

Производительность    

Использование инкрементных сборок для повышения производительности. Как избежать синхронизации ненужных папок при сборке. Использование рабочих пространств во избежание извлечения ненужных папок и проектов при выполнении Team Build. Использование нескольких серверов сборки для повышения производительности сборки.

Использование инкрементных сборок для повышения производительности По умолчанию Team Build, прежде чем изъять из системы контроля версий все дерево исходного кода для сборки, очищает каталог, который он использует для выполнения сборки. Team Build также удаляет со сборочного компьютера и приводит в исходное состояние рабочее пространство, в котором происходило редактирование участвующего в сборке исходного кода. Для повышения производительности можно настроить Team Build так, чтобы передавались только ресурсы, подвергшиеся изменениям с момента последнего выполнения Team Build.

Если в сборке участвует большой объем исходного кода и используется удаленный сервер сборки, получение исходного кода из системы контроля версий может быть довольно длительным процессом. В таком случае следует рассмотреть возможность использования инкрементной сборки. Для выполнения инкрементной сборки требуется задать несколько значений в файле TFSBuild.proj. Необходимо:   

Запретить Team Build очищать локальную папку сборки и папку исходного кода. Запретить Team Build повторное создание рабочего пространства, используемого для сборки. Конфигурировать Team Build так, чтобы для сборки из системы контроля версий извлекались только измененные файлы.

Для выполнения инкрементной сборки

1. Создается новый тип сценария сборки, представляющий инкрементную сборку.

2. Из системы контроля версий для редактирования изымается файл TFSBuild.proj, ассоциированный с только что созданным типом инкрементной сборки. 3. В файле TFSBuild.proj непосредственно перед закрывающим элементом добавляется следующий раздел : true true false

Эти настройки обеспечивают следующее:   

SkipClean. Значение true для SkipClean (Пропустить очистку) гарантирует, что при сборке не будут вычищаться локальная папка сборки и папка исходного кода. SkipInitializeWorkspace. Значение true для SkipInitializeWorkspace (Пропустить возвращение рабочего пространства в исходное состояние) гарантирует, что при сборке существующее рабочее пространство останется неизменным. ForceGet. Значение false для ForceGet (Принудительное получение) гарантирует, что в сборке будет участвовать только обновленный исходный код, а не весь исходный код рабочего пространства.

Дополнительные источники  

Более подробную информацию по этому вопросу можно найти в разделе «Краткие практические рекомендации – Team Build» данного руководства. Подробнее о конфигурировании инкрементной сборки рассказывает статья «How to: Configure Team Foundation Build for an Incremental Build» (Как: конфигурировать Team Foundation Build для выполнения инкрементной сборки) по адресу http://msdn2.microsoft.com/en-us/library/aa833876(VS.80).aspx.

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

При выполнении Team Build сервер извлекает из системы контроля версий все необходимые файлы. То, какие файлы будут извлечены, определяет рабочее пространство, используемое для создания Team Build Type. Не все файлы, отображаемые в рабочем пространстве, необходимы при сборке. Чтобы не извлекать не участвующие в сборке файлы, можно изменить описание рабочего пространства или скрыть ненужные файлы.

Например, отображение по умолчанию для нового проекта – $/TeamProject. Если все исходные файлы находятся в каталоге $/TeamProject/foo/bar/foobar/sources, следует отображать только этот каталог.

Скрыть файлы в отображении рабочего пространства можно путем редактирования файла WorkspaceMapping.xml. Этот файл создается при создании Team Build Type и в нем определяется, какие папки извлекаются при выполнении сборки. Файлы и папки, не используемые в сборке, можно скрыть. Предпочтительнее скрывать папки, потому что сокрытие отдельных файлов может привести к лишним издержкам на обслуживание.

Для сокрытия папок

1. Версия файла WorkspaceMapping.xml изымается из системы контроля версий. 2. В этот файл добавляются соответствующие записи для сокрытия. 3. Файл WorkspaceMapping.xml возвращается в систему контроля версий и внесенные в него изменения регистрируются.

Следующий фрагмент кода обеспечивает, что при выполнении Team Build папка документации не будет извлекаться из системы контроля версий: