WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 |

Курс "Обзор перспективных технологий Microsoft.NET"

Лекция 2. Team System и Team Foundation Server

На прошлой лекции мы обсуждали новую версию флагманского IDE от Microsoft – Microsoft Visual Studio 2005. Это семейство продуктов имеет различные версии. Мы рассмотрим различия этих версий (в основном с точки зрения командной разработки), также обсудим их серверную поддержку в виде Team Foundation Server.

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

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

Замечание. Вообщето к 4му курсу, на который рассчитаны данные лекции, студенты уже не должны сомневаться в необходимости средств поддержки разработки ПО. Но если по результатам опроса аудитории это окажется не так, краткий перечень мотиваций, на который можно ориентироваться при обосновании опровержения, вы сможете найти в статье Visual Studio 2005 Team System: Software Project Management (http://msdn.microsoft.com/vstudio/teamsystem/project/default.aspx?pull=/library/enus/dnvsent/html/vstspm.asp).

Естественно, сразу же возникают вопросы интеграции. Среди них такие:

Как средство контроля версий сочетается с IDE? Есть ли связь между версией исходного текста и ошибкой в базе данных ошибок? Кто из разработчиков должен исправлять ошибку номер N из базы данных ошибок? Каким образом учесть время на исправление этой ошибки в плане разработки? Если вы пользуетесь инструментами моделирования архитектуры, как связаны диаграмма архитектуры системы и код? Как их синхронизовывать? Чем больше ассортимент авторов используемых вами продуктов поддержки разработки, тем больше интеграционной работы вам нужно делать руками (или прилагать осознанные усилия вроде написания интеграционных скриптов, скачивания готовых интеграционных решений и т.п.).

Безусловно, было бы удобно, если бы существовала единая среда разработки, в которой «жили» бы все ее участники. Однако в проектах существует множество совершенно различных ролей, с весьма разными задачами, которые существующим средствам поддержки разработки довольно тяжело охватить. Как сделать единую среду для, скажем, ролей программиста и руководителя? Первому надо писать и отлаживать код, второму – отслеживать состояние проекта и принимать корректирующие действия.

Microsoft подошла к этому вопросу фундаментально. В компании подумали обо всех ролях обычного проекта по разработке ПО и проинтегрировали средства, требуемые этим ролям, в едином окружении. Вряд ли вас удивит, что это окружение – Visual Studio. Да, это Visual Studio в ее версии Team Edition с серверной поддержкой в лице Team Foundation Server. Есть и аналогичная (но несколько урезанная) поддержка групповой разработки и для Professional и даже для Standard версий.

Небольшое терминологическое замечание: весь комплект средств называется Team System, как мы и будем далее его называть.

Роли, поддерживаемые Team System Team System выделяет четыре проектных роли (а вовсе не шесть, как можно было бы подумать, глядя на модель команды MSF J):

Разработчик Архитектор Тестер Менеджер проекта Для каждой из этих ролей, кроме менеджеров, существует своя версия Visual Studio: Visual Studio Team Edition for Developers, Visual Studio Team Edition for Testers, Visual Studio Team Edition for Architects. Для менеджеров предназначены специальные средства Team Foundation Server.



Есть также редакция Visual Studio, которая объединяет в себе все три версии студии, она называется Team Suite. Отдельным пунктом идет редакция VS для разработчиков баз данных (Database Professional Team Center), выпущенная немного позже остальных упомянутых версий VSTS.

Во всем этом многообразии сложно разобраться, особенно принимая решение о покупке, – много версий, немалое количество возможных конфигураций, различные ценовые категории, различные мотивации к приобретению для разных проектов и команд, особенно если учесть существование клиентских лицензий (CAL), возможности покупать или не покупать Visual SourceSafe 2005 вместо TFS, покупаемую версию MSDN, с поддержкой или без; но, к счастью, в рамках этого курса мы рассматриваем семейство продуктов Visual Studio исключительно с точки зрения его пользователя, поэтому основная часть подобных деталей нам неинтересна.

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

Для разработчика В Teamверсию студии для разработчика включены инструменты анализа и профилирования кода. Анализ приложений на C# осуществляется с помощью утилиты FxCop (есть аналогичные инструменты для других языков, например PREFast для С++). Для профилирования есть утилиты под общим названием Enterprise Performance Tools.

FxCop FxCop существовал еще до 2005й студии, но сейчас он встроен в продукт. FxCop позволяет вам статически проверять ваш код на соответствие некоторым правилам (по умолчанию.NET Framework Design Guidelines). В стандартные правила входят правила:

безопасности разработки библиотек глобализации функциональной совместимости сопровождения именования производительности надежности и прочие. FxCop включается в настройках студии на закладке Code Analysis. Можно включать целые секции правил, или же настраивать их с гранулярностью до одного правила. Заглянем в одно из них. Например, узел Naming Rules, правило CA1707 «Идентификатор не должен содержать символов подчеркивания». Здесь собраны довольно понятные и очевидные правила. Сложнее, например, узел Security Rules, правило CA2121, «Статический конструктор должен быть скрытым (private)». За объяснениями обратимся в MSDN:

A static constructor, also called a class constructor, is used to initialize a type. The system calls the static constructor before the first instance of the type is created or any static members are referenced. The user has no control over when the static constructor is called. If a static constructor is not private, it can be called by code other than the system. Depending on the operations performed in the constructor, this can cause unexpected behavior.

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

Как и почти всё в.NET, набор правил для FxCop можно расширять. Для этого вам надо сделать собственную сборку, использующую соответствующие механизмы интроспекции (FxCop Introspection SDK). Кроме того, проверку с помощью FxCop можно сделать одним из шагов сборки с помощью MSBuild и даже сделать частью политики занесения изменений (checkin) в Team Foundation Server, таким образом, ваши изменения попадут в хранилище, только успешно пройдя требуемые семантические проверки.

Полезной возможностью FxCop является возможность создать стартовую точку (baseline) при его внедрении. Когда вы обнаруживаете, что в вашем существующем проекте есть несколько сотен нарушений и хватаетесь за голову, т.к. никто не даст вам неделю времени исключительно на исправление этих нарушений, у вас есть отличная возможность сказать: «Окей, найденные нарушения пока разрешены, но с этого момента новые нарушения не допускаются».

Enterprise Performance Tools Средства профилирования Visual Studio поддерживают два вида профилирования – с помощью контрольных замеров (sampling) и с помощью встраивания в код (instrumentation). Разницу между этими понятиями описывают сами разработчики в своем блоге (см. http://blogs.msdn.com/profiler/). Тем, кто пользуется Rational Quantify, способ с instrumentation хорошо знаком.





На момент написания курса ни FxCop, ни профилятор не поддерживают 64битные приложения.

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

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

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

Диаграмма классов (Class diagram) Диаграмма приложений (Application Designer) Диаграмма информационного центра (Logical Datacenter Designer) Диаграмма систем (System Designer) Диаграмма развертывания (Deployment Designer) Диаграмма классов напоминает UMLную, но с некоторой спецификой.NET (например, соответствующие модификаторы членов, наличие свойств). По диаграмме сразу генерируется код, изменения в диаграмме тотчас же отражаются в коде. Без какойлибо спецразметки ручные изменения в коде отражаются на диаграмме, что делает весь процесс проектирования классов жизнеспособным и итеративным.

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

Чуть подробнее об остальных типах диаграмм.

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

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

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

и т.п.

Pages:     || 2 | 3 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.