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

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

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

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

увеличить изображение
Рис. 14.16. Сохранение без внесения

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

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

увеличить изображение
Рис. 14.17. Список текущих изменений

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

увеличить изображение
Рис. 14.18. Диалог восстановления изменений

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

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

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

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

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

увеличить изображение
Рис. 14.19. Общие настройки описания сборки

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

увеличить изображение
Рис. 14.20. Настройка рабочего пространства

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

увеличить изображение
Рис. 14.21. Выбор или создание MsBuild-проекта

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

увеличить изображение
Рис. 14.22. Правила сохранения

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

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

увеличить изображение
Рис. 14.23. Выбор агента

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

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

увеличить изображение
Рис. 14.24. Задание триггера

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

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