Programmnaya_inzheneria

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

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

111

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

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

112

Рис. 13.12. Выбор пакетов для интеграции.

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

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

113

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

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

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

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

114

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

Рис. 13.15. Разрешение внутренних конфликтов.

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

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

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

115

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

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

Рис. 13.16. Сохранение без внесения.

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

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

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

116

Рис. 13.17. Список текущих изменений.

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

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

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

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

117

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

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

•сборка проекта (при этом исходные тексты программ автоматически берутся из системы контроля версий),

•автоматический запуск тестовых пакетов (как созданных в ручную, так и идентифицированных автоматически),

•применение статического анализ кода,

•размещение результатов сборки в сетевой папке,

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

•выявление присоединенных элементов работы и т.д.

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

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

Визуальное представление хода процесса сборки, результатов, а также истории более ранее отработавших сборок.

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

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

118

Рис. 13.19. Общие настройки описания сборки.

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

Рис. 13.20. Настройка рабочего пространства.

119

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

Рис. 13.21. Выбор или создание MsBuild-проекта.

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

120