Использование процесса сборки с условным возвратом для проверки изменений

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

Выберите действие.

• Сборки с условным возвратом и работа в команде

• Определение процесса сборки с условным возвратом

• Как повысить функциональность и производительность процесса сборки

• Как не создавать препятствий работе команды

• Ручной запуск закрытых сборок и сборок с условным возвратом

Сборки с условным возвратом и работа в команде

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

Для завершения возврата построение должно пройти успешно. Дополнительные сведения см. в разделе Возврат ожидающих изменений под управлением построения с условным возвратом.

Если некоторые пользователи должны обходить условный возврат, можно задать разрешению Переопределение проверки возврата по сборке для группы пользователей значение Разрешить. Дополнительные сведения см. в разделе Справочник по разрешениям Team Foundation Server.

Определение процесса сборки с условным возвратом

1. Проверьте в Team Explorer, что вы подключены к командному проекту (нажмите клавиши CTRL+0, C), а затем откройте страницу Сборки (нажмите клавиши CTRL+0, B).

2. Нажмите на ссылку Создать определение сборки или выделите сборку, откройте ее контекстное меню и выберите команду Редактировать определение сборки.

   Совет

   Если появляется сообщение об ошибке TF225001, настройте контроллер сборок.

3. На вкладке Триггер:

   • Выберите Условный возврат.

   • (Необязательно) Для повышения эффективности процесса сборки установите флажок Выполнить слияние и сборку не более n материалов. Дополнительные сведения см. в разделе Как не создавать препятствий работе команды.

4. На вкладке Параметры исходного кода в таблице Рабочие папки сопоставьте папки управления версиями, которые будет контролировать данное определение сборки, с локальными папками на агенте сборки.

   Совет

   Соблюдайте следующие правила.

   • Чтобы процесс сборки выполнялся правильно и более эффективно, добавьте все и только те папки, которые содержат необходимые процессу сборки файлы.

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

   • Дополнительные сведения о задании сопоставлений см. в разделе Работа с рабочими областями сборок.

5. Для повышения производительности на вкладке Параметры сборки по умолчанию выберите Эта сборка не копирует выходные файлы в папку для размещения.

6. На вкладке Процесс в разделе Сборка в параметре Проекты укажите решения или проекты кода, сборку которых требуется выполнить.

7. На вкладке Процесс задайте параметры, которые позволят обеспечить соответствие определенным стандартам качества кода команды и не будут безосновательно задерживать разработку.

   Дополнительные сведения см. в подразделе Как повысить функциональность и производительность процесса сборки.

8. Укажите параметры процесса сборки на других вкладках. Дополнительные сведения см. в разделе Создание или изменение определения сборки.

Повышение функциональности и производительности процесса сборки

Чтобы сократить время обработки построения, учтите следующие рекомендации при установке значений параметров обработки построения на вкладке Процесс.

Управление версиями TF или Git

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

Сборка

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

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

  • укажите как можно меньше пар платформа-значение.

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

Сборка, Дополнительно

• Выполнить анализ кода. Для повышения производительности установите здесь значение Никогда.

Тест, Дополнительно

• Отключение тестов.

  • Для повышения производительности выберите значение True.

  • Если код должен проходить определенные тесты, выберите False, а затем определите набор запускаемых в сборке тестов. Можно повысить производительность, запуская только необходимые тесты. Чтобы назначить эти тесты, отфильтруйте их по категориям или приоритетам. Дополнительные сведения см. в разделе Выполнение тестов в процессе сборки.

Публикация символов

• Путь для публикации символов. Для повышения производительности оставьте это значение пустым.

Дополнительно

• Параметры агента

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

    Например, 15 минут — это нормальная продолжительность выполнения сборки. Напротив, неприемлемо ждать 8 часов, чтобы определить, был ли код успешно возвращен.

  • Максимальное время выполнения. Задайте этому параметру разумно малое значение. К примеру, 15 минут могут не представлять для команды никакой проблемы, а восемь часов — уже слишком много.

Дополнительные сведения о параметрах процесса сборки шаблона по умолчанию см. в разделе Использование шаблона по умолчанию для процесса сборки.

Как не создавать препятствий работе команды

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

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

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

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

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

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

Ручной запуск закрытых сборок и сборок с условным возвратом

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

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

• Система не возвращает изменения (закрытое построение). Разработчик может использовать этот параметр, если необходимо проверить некоторые изменения в наборе отложенных изменений, но не возвращать их код.

Дополнительные сведения см. в разделе Помещение сборки в очередь.