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

Материал из Wiki Test Lab
Версия от 09:11, 28 февраля 2014; Viktorr (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Назад    Главная
 

Источник

Дальше »


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

Система контроля версий. Отслеживание изменений отдельных файлов. Правила внесения изменений. Управление ветками. Сохранение без внесения. Автоматические сборки.


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

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


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

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

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

Отслеживание изменений отдельных файлов. Основным отличительным свойством системы контроля версий в TFS является интеграция его с другими подсистемами TFS, а также более тесная интеграция с Visual Studio, чем во многих других системах контроля версий. Большая часть этих возможностей наглядно демонстрируется самим внешнем вида check-in диалога, представленным на рис. 14.1.

14-01.jpg


Рис. 14.1. Check-in диалог


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

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


14-02.jpg


Рис. 14.2. Закладка Work Items

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

14-03.jpg


Рис. 14.3. Закладка Check-in Notes

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


14-04.jpg


Рис. 14.4. Закладка Policy Warnings

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

14-05.jpg


Рис. 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-06.jpg


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

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


14-07.jpg


Рис. 14.7. Диалог Policy Failure

Управление ветками. Для поддержки конфигурационного управления в системе контроля версий TFS реализовано две команды: создание ветви (Branch) и интеграция ветвей (Merge). Эти команды доступны на файлах и папках в системе контроля версий. При выборе команды создания ветви открывается диалог (рис. 14.8), позволяющий выбрать путь, куда следует скопировать (ответвить) выбранные файлы. После выполнение этой команды в системе контроля версий по указанному пути создастся полная копия выбранных файлов.


14-08.jpg


Рис. 14.8. Создание новой ветви


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


14-09.jpg


Рис. 14.9. Внесение изменений ответвления

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

14-10.jpg


Рис. 14.10. Область интеграции

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


14-11.jpg


Рис. 14.11. Версия для интеграции

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


14-12.jpg

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

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


14-13.jpg

Рис. 14.13. Список конфликтов

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

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


14-14.jpg

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

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


14-15.jpg

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

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

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

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


14-16.jpg

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

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

14-17.jpg

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


14-18.jpg

Рис. 14.18. Диалог восстановления изменений

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

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

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

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

Создание описания сборки. Для создания описания новой сборки проекта необходимо выбрать команду New Build Definition в соответствующем узле Team Explorer, и после этого откроется окно с несколькими закладками (рис. 14.19).


14-19.jpg

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


14-20.jpg

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


14-21.jpg

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


14-22.jpg

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

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

14-23.jpg

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

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

14-24.jpg

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

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

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


'Создание проекта MsBuild. Проект MsBuild, не смотря ни на что, все-таки составляет основу системы автоматических сборок TFS. Однако специалистами Майкрософт потрачено немало усилий на то, чтобы мы могли забыть о необходимости поддерживать большие и сложные XML-файлы с описанием сборок. В TFS для создания проектов MsBuild реализован достаточно удобный мастер (рис. 14.25 – 14.27).


14-25.jpg

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


14-26.jpg

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


14-27.jpg

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

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

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

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


14-28.jpg

Рис. 14.28. Свойства сборочного агента Запуск процесса сборки и анализ результатов. Итак, после того как описание сборки создано и инфраструктура выполнения настроена, мы можем запустить процесс сборки с помощью команды Queue New Build, вызывающей окно, показанное на рис. 14.29.

14-29.jpg

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

14-30.jpg

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

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


14-31.jpg

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

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

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


14-32.jpg

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







Дальше »

Личные инструменты