Использование процесса сборки с условным возвратом для проверки изменений
Ситуация, когда разработчик возвращает изменения, делающие построение недопустимым, может привести к существенным проблемам даже в небольших командах. В более крупных командах такие изменения могут привести к существенным убыткам, поскольку могут вызвать снижение производительности и сбой графика. Чтобы частично или полностью предотвратить подобные проблемы с базой кода, можно создать определение сборки с условным возвратом.
Примечание
Сборки с условным возвратом доступны только в командных проектах TFVC .Они не доступны в командных проектах Git .
Выберите действие.
Сборки с условным возвратом и работа в команде
Определение процесса сборки с условным возвратом
Как повысить функциональность и производительность процесса сборки
Как не создавать препятствий работе команды
Ручной запуск закрытых сборок и сборок с условным возвратом
Сборки с условным возвратом и работа в команде
Если команда вводит в действие сборку с условным возвратом, то вносимые разработчиками изменения помещаются в наборы отложенных изменений, автоматически собираются и, возможно, тестируются системой сборки.
Для завершения возврата построение должно пройти успешно. Дополнительные сведения см. в разделе Возврат ожидающих изменений под управлением построения с условным возвратом.
Если некоторые пользователи должны обходить условный возврат, можно задать разрешению Переопределение проверки возврата по сборке для группы пользователей значение Разрешить. Дополнительные сведения см. в разделе Справочник по разрешениям Team Foundation Server.
Определение процесса сборки с условным возвратом
Проверьте в Team Explorer, что вы подключены к командному проекту (нажмите клавиши CTRL+0, C), а затем откройте страницу Сборки (нажмите клавиши CTRL+0, B).
Нажмите на ссылку Создать определение сборки или выделите сборку, откройте ее контекстное меню и выберите команду Редактировать определение сборки.
Совет
Если появляется сообщение об ошибке TF225001, настройте контроллер сборок.
На вкладке Триггер:
Выберите Условный возврат.
(Необязательно) Для повышения эффективности процесса сборки установите флажок Выполнить слияние и сборку не более n материалов. Дополнительные сведения см. в разделе Как не создавать препятствий работе команды.
На вкладке Параметры исходного кода в таблице Рабочие папки сопоставьте папки управления версиями, которые будет контролировать данное определение сборки, с локальными папками на агенте сборки.
Совет
Соблюдайте следующие правила.
-
Чтобы процесс сборки выполнялся правильно и более эффективно, добавьте все и только те папки, которые содержат необходимые процессу сборки файлы.
-
Убедитесь, что не выбраны папки системы управления версиями другого определения сборки с условным возвратом, которые также указаны на вкладке Рабочая область.В противном случае при возврате файлов в эти папки система сборки предложит выбрать, какое определение сборки следует поставить в очередь.
-
Дополнительные сведения о задании сопоставлений см. в разделе Работа с рабочими областями сборок.
-
Для повышения производительности на вкладке Параметры сборки по умолчанию выберите Эта сборка не копирует выходные файлы в папку для размещения.
На вкладке Процесс в разделе Сборка в параметре Проекты укажите решения или проекты кода, сборку которых требуется выполнить.
На вкладке Процесс задайте параметры, которые позволят обеспечить соответствие определенным стандартам качества кода команды и не будут безосновательно задерживать разработку.
Дополнительные сведения см. в подразделе Как повысить функциональность и производительность процесса сборки.
Укажите параметры процесса сборки на других вкладках. Дополнительные сведения см. в разделе Создание или изменение определения сборки.
Повышение функциональности и производительности процесса сборки
Чтобы сократить время обработки построения, учтите следующие рекомендации при установке значений параметров обработки построения на вкладке Процесс.
Управление версиями TF или Git
- Очистка рабочей области или Очистка репозитория. Для повышения производительности задайте этому параметру значение False. При этом значении ваша команда может пропустить некоторые виды дефектов, например, появляющиеся во время рефакторинга.
Сборка
Конфигурации. Если оставить этот параметр пустым, для всех решений и проектов будут использоваться платформа и конфигурация по умолчанию. Для оптимизации производительности придерживайтесь следующих рекомендаций:
если пара платформа-конфигурация строится быстрее, чем другие пары, следует указать ее в значении данного параметра;
укажите как можно меньше пар платформа-значение.
Очистка сборки. Для повышения производительности задайте этому параметру значение False. При этом значении ваша команда может пропустить некоторые виды дефектов, например, появляющиеся во время рефакторинга.
Сборка, Дополнительно
- Выполнить анализ кода. Для повышения производительности установите здесь значение Никогда.
Тест, Дополнительно
Отключение тестов.
Для повышения производительности выберите значение True.
Если код должен проходить определенные тесты, выберите False, а затем определите набор запускаемых в сборке тестов. Можно повысить производительность, запуская только необходимые тесты. Чтобы назначить эти тесты, отфильтруйте их по категориям или приоритетам. Дополнительные сведения см. в разделе Выполнение тестов в процессе сборки.
Публикация символов
- Путь для публикации символов. Для повышения производительности оставьте это значение пустым.
Дополнительно
Параметры агента
Фильтр имен или Фильтр тегов. Используйте имя или тег агента построения для привязки этого определения построения к агенту построения, специально предназначенному для запуска этого построения. Агент сборки должен запускаться на компьютере, мощности оборудования которого достаточно для оперативной обработки сборки в соответствии с ожидаемой производительностью команды.
Например, 15 минут — это нормальная продолжительность выполнения сборки. Напротив, неприемлемо ждать 8 часов, чтобы определить, был ли код успешно возвращен.
Максимальное время выполнения. Задайте этому параметру разумно малое значение. К примеру, 15 минут могут не представлять для команды никакой проблемы, а восемь часов — уже слишком много.
Дополнительные сведения о параметрах процесса сборки шаблона по умолчанию см. в разделе Использование шаблона по умолчанию для процесса сборки.
Как не создавать препятствий работе команды
Для каждого определения построения с условным возвратом возможно одновременно только одно запущенное построение. Следовательно, в больших активных командах возникает значительная очередь построений с условным возвратом. Следующие рекомендации могут помочь избежать задержек в работе команды.
Для повышения эффективности процесса сборки на вкладке Триггер установите флажок Выполнить слияние и сборку не более n материалов и задайте максимальное количество возвратов, которые вы хотите собрать вместе в любом пакете. Как правило, этот параметр не вызывает серьезных сбоев в работе. Каждый возврат фиксируется или отклоняется отдельно.
Например, если три возврата собраны в пакете вместе и сборка не завершилась успешно, система ставит в очередь отдельные сборки этих трех возвратов.
Однако при выборе этого параметра существует вероятность, что один возврат будет мешать другому. Это может произойти, например если несколько возвратов изменяют один и тот же файл и происходит конфликт управления версиями. В этом случае фиксируется наиболее ранний возврат, а наиболее последний возврат отклоняется.
Определите построение так, чтобы агент построения выполнял только работу, необходимую для проверки качества возвращаемого кода. Дополнительные сведения см. ранее в этом разделе в подразделе Рекомендации по настройке параметров на вкладке "Процесс".
Выделите отдельный мощный компьютер (например, с быстрым процессором и жестким диском) для агента сборки, который используется определением сборки с условным возвратом.
Ручной запуск закрытых сборок и сборок с условным возвратом
Если разработчик хочет большей уверенности относительно возвращаемых им изменений, он может вручную поставить в очередь построение набора отложенных изменений. При использовании этого подхода, если построение пройдет успешно, система будет действовать различным образом в зависимости от того, какой из двух параметров выбран.
Система возвращает изменения (ручная сборка с условным возвратом). Этот параметр может быть полезен для команд, которые не хотят делать условный возврат обязательным, но хотят предоставить разработчикам возможность проверять код перед возвратом.
Система не возвращает изменения (закрытое построение). Разработчик может использовать этот параметр, если необходимо проверить некоторые изменения в наборе отложенных изменений, но не возвращать их код.
Дополнительные сведения см. в разделе Помещение сборки в очередь.