Программная инженерия

VSTS: конфигурационное управление

Разбить на страницы
Показывать лекцию целиком

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

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

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

    Функциональность ею предоставляемая в большинстве своем является стандартной, поэтому более подробно мы остановимся на следующих ее особенностях:

  • отслеживание изменений отдельных файлов и их "провязка" с элементами работы;
  • правила внесения изменений (check-in policies);
  • средства управления "ветками";
  • сохранение изменений без внесения.
    •

    .

    (рис 14.1) Check-in диалог

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

    Наиболее востребованной является поддержка в TFS возможности связи вносимых изменений с элементами работы, которую можно выполнить на закладке Work Items, показанной на рис 14.2.

    (рис 14.2) Закладка Work Items

    Разработчик, который вносит изменения в файлы с исходными текстами, может найти соответствующие этим изменениям элементы работы (ведь он либо исправлял какую-нибудь ошибку, либо выполнял задачу и т.п.), используя любой из доступных запросов, а также текстовый поиск. Запрос задается в секции Query – см. рис 14.2. Результат его выполнения отобразится в главном окне диалога на этом рисунке. Для того, чтобы связать конкретный элемент работы из этого запросы с данным изменением исходников, надо выбрать галочку в первом столбце. На рис 14.2 она выбрана для последнего элемента в списке – элемента работы Task 107. Далее, бывает так, что это изменение исходников "закрывает" данный элемент работ. Тогда в столбце Check-in Action нужно выбрать действие Resolve – это действие, на равне с другими, определяется в шаблоне процесса для всех элементов работы данного типа. Если же данное изменение не "закрывает" данный элемент работы, то в этом столбце нужно проставить действие Associate, и оно просто установит связь этого изменения с данным элементом работы.

    (рис 14.3) Закладка Check-in Notes

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

    (рис 14.4) Закладка Policy Warnings

    Интересным нововведение TFS как системы контроля версий является гибкая система задания правил внесения изменений (check-in policies), о которой будет подробнее рассказано позже. На закладке Policy Warnings (рис 14.4) разработчику показывается список правил, с которыми вошло в конфликт его изменение (или процедура внесения изменений).

    (рис 14.5) Свойства набора изменений

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

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

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

    В стандартную поставку TFS входят следующие правила:

  • Work Items – предполагает, что каждый пакет изменений кроме файлов должен иметь ассоциацию с элементом работы;
  • Builds – проверяет, что перед внесением изменений разработчик убедился в собираемости проекта;
  • Testing – проверяет, что перед внесением изменений разработчиком были исполнены тесты. К сожалению, правило не может определить какие именно тесты надо запускать для проверки данного изменения, поэтому данное правило не всегда эффективно;
  • Code Analysis – выполняет статический анализ кода перед внесением изменений.
    •

    В пакете Team Foundation Power Tools имеются следующие дополнительные правила:

  • Правило Forbidden Patterns позволяет запретить добавление файлов с определёнными шаблонами в именах, например, Form1.cs.
  • Правило Custom Path позволяет увеличить гранулярность применения правил в проекте сконфигурировав правила только для определённых частей структуры папок системы контроля версий.
  • Правило Changeset Comments проверяет, что изменения сопровождаются комментариями.
  • Правило Work Item Query проверяет, что все элементы работы, возвращаемые в результате определённого запроса, ассоциированы с файлами (более продвинутый вариант правила Work Items).
    •

    Среди правил, доступных в открытом доступе можно выделить:

  • Правило Code Comment Checking проверяет код на наличие комментариев перед внесением изменений (работает для кода на C#/VB.NET).
  • Правило Code Review Workflow проверяет, что каждый пакет изменений ассоциирован с элементом работы, являющимся заданием на инспекцию кода в состоянии "Выполнено". Это правило позволяет проводить процесс инспекции вносимых изменений в более формальном виде.
  • Правило Merge/Branch Only удостоверяет, что все изменения происходят в результате объединения с другой веткой либо ответвления. Представляет особый интерес с точки зрения процесса конфигурационного управления. Позволяет, например, запретить вносить изменения напрямую в одну из ветвей (например, ветвь релиза). Вносить изменения в ветвь, защищенную таким правилом, можно только через интеграцию изменений из других ветвей.
    •

    Выбрать список правил, применяемых для командного проекта можно с помощью окна настройки системы контроля версий (рис 14.6).

    (рис 14.6) Редактирование правил вноса изменений

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

    (рис 14.7) Диалог Policy Failure

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

    (рис 14.8) Создание новой ветви

    Заметим, что после создания ветви она не попадает автоматически на сервер. Чтобы ветвь попала на сервер и стала доступна всем, необходимо выполнить операцию внесения изменений (рис 14.9).

    (рис 14.9) Внесение изменений ответвления

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

    (рис 14.10) Область интеграции

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

    (рис 14.11) Версия для интеграции

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

    (рис 14.12) Выбор пакетов для интеграции

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

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

    (рис 14.13) Список конфликтов

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

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

    (рис 14.14) Разрешение конфликта

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

    (рис 14.15) Разрешение внутренних конфликтов

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

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

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

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

    (рис 14.16) Сохранение без внесения

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

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

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

    (рис 14.18) Диалог восстановления изменений

    Автоматические сборки

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

  • TFS поставляется вместе с набором MsBuild-задач, позволяющих значительно упростить и ускорить настройку процесса сборки. Среди наиболее важных задач следует отметить следующие:
  • сборка проекта (при этом исходные тексты программ автоматически берутся из системы контроля версий),
  • автоматический запуск тестовых пакетов (как созданных в ручную, так и идентифицированных автоматически),
  • применение статического анализ кода,
  • размещение результатов сборки в сетевой папке,
  • автоматическое поддержание уникального идентификатора сборки и его регистрация,
  • выявление присоединенных элементов работы и т.д.
    •
  • TFS предоставляет серверную среду, позволяющую запускать процесс сборки в "чистом" окружении, в отличии от обычных MsBuild-сборок, где организация соответствующей инфраструктуры требует значительных усилий.
  • Возможность автоматического запуска процесса сборки как в режиме непрерывной интеграции, так и по расписанию.
  • Визуальное представление хода процесса сборки, результатов, а также истории более ранее отработавших сборок.

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

    ).

    (рис 14.19) Общие настройки описания сборки

    На первой закладке ( General ) находится общая информация – название и описание назначения этого сценария сборки.

    (рис 14.20) Настройка рабочего пространства

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

    (рис 14.21) Выбор или создание MsBuild-проекта

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

    (рис 14.22) Правила сохранения

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

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

    (рис 14.23) Выбор агента

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

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

    (рис 14.24) Задание триггера

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

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

    – 14.27).

    (рис 14.25) Выбор решений

    На первом шаге (рис 14.25) мы выбираем в системе контроля версий те решения, которые должны собираться в данной сборке.

    (рис 14.26) Выбор конфигураций

    На втором шаге (см. рис 14.26) мы выбираем те конфигурации в этих решениях, которые нужно собирать.

    (рис 14.27) Выбор тестов и правил анализа

    И, наконец, на третьем шаге (рис 14.27) мы выбираем те тесты, которые мы хотим запустить и отмечаем, хотим ли мы проводить статический анализ кода. В отличии от TFS 2005, где при выборе тестов можно было использовать только заранее подготовленные тестовые пакеты, в TFS 2008 появилась такая востребованная возможность как автоматическое подключение пакетов тестов по метке имени (обычно сборки начинающиеся или заканчивающиеся на Test). Эта возможность позволяет без дополнительных затрат включить выполнение модульных тестов в автоматическую сборку.

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

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

    Несмотря на сложность описанного процесса, настройка его достаточно проста и производится, в основном, с помощью окна свойств агента (см. рис 14.28).

    (рис 14.28) Свойства сборочного агента

    .

    (рис 14.29) Запуск новой сборки

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

    (рис 14.30) Список описаний сборок

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

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

    (рис 14.31) Результаты сборки

    Управление процессом сборки. Все продемонстрированные нами средства визуального описания сборок доступны не только при создании такого описания, но и для любого из существующих описаний сборок (команда Edit Build Definition ). Единственным исключением является файл MsBuild, который, будучи однажды сгенерирован с помощью мастера, далее поддерживается вручную.

    Этот файл можно найти в системе контроля версий (рис 14.32) в той папке, которая была выбрана при его создании. Эта папка содержит два файла:

  • PROJ-файл – основной файл, описывающий задачи MsBuild. Этот файл содержит достаточное количество сгенерированных комментариев, позволяющих производить простую настройку (добавить или удалить решение, включить или отключить статический анализ и т.д.) достаточно легко, однако для более сложных изменений необходимо знакомство как с принципами работы MsBuild, так и со спецификой MsBuild-задач, используемых в TFS.
  • RSP-файл, который содержит параметры командной строки для передачи при запуске MsBuild.
    •  (рис 14.32) Файл определения проекта

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

    Страницы:

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

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

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

    Функциональность ею предоставляемая в большинстве своем является стандартной, поэтому более подробно мы остановимся на следующих ее особенностях:

  • отслеживание изменений отдельных файлов и их "провязка" с элементами работы;
  • правила внесения изменений (check-in policies);
  • средства управления "ветками";
  • сохранение изменений без внесения.
    •

    .

    (рис 14.1) Check-in диалог

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

    Наиболее востребованной является поддержка в TFS возможности связи вносимых изменений с элементами работы, которую можно выполнить на закладке Work Items, показанной на рис 14.2.

    (рис 14.2) Закладка Work Items

    Разработчик, который вносит изменения в файлы с исходными текстами, может найти соответствующие этим изменениям элементы работы (ведь он либо исправлял какую-нибудь ошибку, либо выполнял задачу и т.п.), используя любой из доступных запросов, а также текстовый поиск. Запрос задается в секции Query – см. рис 14.2. Результат его выполнения отобразится в главном окне диалога на этом рисунке. Для того, чтобы связать конкретный элемент работы из этого запросы с данным изменением исходников, надо выбрать галочку в первом столбце. На рис 14.2 она выбрана для последнего элемента в списке – элемента работы Task 107. Далее, бывает так, что это изменение исходников "закрывает" данный элемент работ. Тогда в столбце Check-in Action нужно выбрать действие Resolve – это действие, на равне с другими, определяется в шаблоне процесса для всех элементов работы данного типа. Если же данное изменение не "закрывает" данный элемент работы, то в этом столбце нужно проставить действие Associate, и оно просто установит связь этого изменения с данным элементом работы.

    (рис 14.3) Закладка Check-in Notes

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

    (рис 14.4) Закладка Policy Warnings

    Интересным нововведение TFS как системы контроля версий является гибкая система задания правил внесения изменений (check-in policies), о которой будет подробнее рассказано позже. На закладке Policy Warnings (рис 14.4) разработчику показывается список правил, с которыми вошло в конфликт его изменение (или процедура внесения изменений).

    (рис 14.5) Свойства набора изменений

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

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

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

    В стандартную поставку TFS входят следующие правила:

  • Work Items – предполагает, что каждый пакет изменений кроме файлов должен иметь ассоциацию с элементом работы;
  • Builds – проверяет, что перед внесением изменений разработчик убедился в собираемости проекта;
  • Testing – проверяет, что перед внесением изменений разработчиком были исполнены тесты. К сожалению, правило не может определить какие именно тесты надо запускать для проверки данного изменения, поэтому данное правило не всегда эффективно;
  • Code Analysis – выполняет статический анализ кода перед внесением изменений.
    •

    В пакете Team Foundation Power Tools имеются следующие дополнительные правила:

  • Правило Forbidden Patterns позволяет запретить добавление файлов с определёнными шаблонами в именах, например, Form1.cs.
  • Правило Custom Path позволяет увеличить гранулярность применения правил в проекте сконфигурировав правила только для определённых частей структуры папок системы контроля версий.
  • Правило Changeset Comments проверяет, что изменения сопровождаются комментариями.
  • Правило Work Item Query проверяет, что все элементы работы, возвращаемые в результате определённого запроса, ассоциированы с файлами (более продвинутый вариант правила Work Items).
    •

    Среди правил, доступных в открытом доступе можно выделить:

  • Правило Code Comment Checking проверяет код на наличие комментариев перед внесением изменений (работает для кода на C#/VB.NET).
  • Правило Code Review Workflow проверяет, что каждый пакет изменений ассоциирован с элементом работы, являющимся заданием на инспекцию кода в состоянии "Выполнено". Это правило позволяет проводить процесс инспекции вносимых изменений в более формальном виде.
  • Правило Merge/Branch Only удостоверяет, что все изменения происходят в результате объединения с другой веткой либо ответвления. Представляет особый интерес с точки зрения процесса конфигурационного управления. Позволяет, например, запретить вносить изменения напрямую в одну из ветвей (например, ветвь релиза). Вносить изменения в ветвь, защищенную таким правилом, можно только через интеграцию изменений из других ветвей.
    •

    Выбрать список правил, применяемых для командного проекта можно с помощью окна настройки системы контроля версий (рис 14.6).

    (рис 14.6) Редактирование правил вноса изменений

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

    (рис 14.7) Диалог Policy Failure

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

    (рис 14.8) Создание новой ветви

    Заметим, что после создания ветви она не попадает автоматически на сервер. Чтобы ветвь попала на сервер и стала доступна всем, необходимо выполнить операцию внесения изменений (рис 14.9).

    (рис 14.9) Внесение изменений ответвления

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

    (рис 14.10) Область интеграции

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

    (рис 14.11) Версия для интеграции

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

    (рис 14.12) Выбор пакетов для интеграции

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

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

    (рис 14.13) Список конфликтов

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

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

    (рис 14.14) Разрешение конфликта

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

    (рис 14.15) Разрешение внутренних конфликтов

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

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

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

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

    (рис 14.16) Сохранение без внесения

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

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

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

    (рис 14.18) Диалог восстановления изменений

    Автоматические сборки

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

  • TFS поставляется вместе с набором MsBuild-задач, позволяющих значительно упростить и ускорить настройку процесса сборки. Среди наиболее важных задач следует отметить следующие:
  • сборка проекта (при этом исходные тексты программ автоматически берутся из системы контроля версий),
  • автоматический запуск тестовых пакетов (как созданных в ручную, так и идентифицированных автоматически),
  • применение статического анализ кода,
  • размещение результатов сборки в сетевой папке,
  • автоматическое поддержание уникального идентификатора сборки и его регистрация,
  • выявление присоединенных элементов работы и т.д.
    •
  • TFS предоставляет серверную среду, позволяющую запускать процесс сборки в "чистом" окружении, в отличии от обычных MsBuild-сборок, где организация соответствующей инфраструктуры требует значительных усилий.
  • Возможность автоматического запуска процесса сборки как в режиме непрерывной интеграции, так и по расписанию.
  • Визуальное представление хода процесса сборки, результатов, а также истории более ранее отработавших сборок.

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

    ).

    (рис 14.19) Общие настройки описания сборки

    На первой закладке ( General ) находится общая информация – название и описание назначения этого сценария сборки.

    (рис 14.20) Настройка рабочего пространства

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

    (рис 14.21) Выбор или создание MsBuild-проекта

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

    (рис 14.22) Правила сохранения

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

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

    (рис 14.23) Выбор агента

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

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

    (рис 14.24) Задание триггера

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

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

    – 14.27).

    (рис 14.25) Выбор решений

    На первом шаге (рис 14.25) мы выбираем в системе контроля версий те решения, которые должны собираться в данной сборке.

    (рис 14.26) Выбор конфигураций

    На втором шаге (см. рис 14.26) мы выбираем те конфигурации в этих решениях, которые нужно собирать.

    (рис 14.27) Выбор тестов и правил анализа

    И, наконец, на третьем шаге (рис 14.27) мы выбираем те тесты, которые мы хотим запустить и отмечаем, хотим ли мы проводить статический анализ кода. В отличии от TFS 2005, где при выборе тестов можно было использовать только заранее подготовленные тестовые пакеты, в TFS 2008 появилась такая востребованная возможность как автоматическое подключение пакетов тестов по метке имени (обычно сборки начинающиеся или заканчивающиеся на Test). Эта возможность позволяет без дополнительных затрат включить выполнение модульных тестов в автоматическую сборку.

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

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

    Несмотря на сложность описанного процесса, настройка его достаточно проста и производится, в основном, с помощью окна свойств агента (см. рис 14.28).

    (рис 14.28) Свойства сборочного агента

    .

    (рис 14.29) Запуск новой сборки

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

    (рис 14.30) Список описаний сборок

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

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

    (рис 14.31) Результаты сборки

    Управление процессом сборки. Все продемонстрированные нами средства визуального описания сборок доступны не только при создании такого описания, но и для любого из существующих описаний сборок (команда Edit Build Definition ). Единственным исключением является файл MsBuild, который, будучи однажды сгенерирован с помощью мастера, далее поддерживается вручную.

    Этот файл можно найти в системе контроля версий (рис 14.32) в той папке, которая была выбрана при его создании. Эта папка содержит два файла:

  • PROJ-файл – основной файл, описывающий задачи MsBuild. Этот файл содержит достаточное количество сгенерированных комментариев, позволяющих производить простую настройку (добавить или удалить решение, включить или отключить статический анализ и т.д.) достаточно легко, однако для более сложных изменений необходимо знакомство как с принципами работы MsBuild, так и со спецификой MsBuild-задач, используемых в TFS.
  • RSP-файл, который содержит параметры командной строки для передачи при запуске MsBuild.
    •  (рис 14.32) Файл определения проекта

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^