Проблема дополнительных сборок в Team Foundation Server - PullRequest
0 голосов
/ 05 января 2019

Когда мы выполняем сборку TFS, можем ли мы изменить выходные данные сборки, чтобы выходные данные были ограничены только изменениями, чтобы уменьшить полезную нагрузку развертывания? Пример:

  • Когда я создаю решение, я должен получить только измененные библиотеки DLL не все (включая Microsoft и другие библиотеки сторонних производителей, которые никогда не менялись.

Настройка решения CI в TFS 2015 и непроверенные чистые параметры, так как TFS 2015/2017 всегда доставлял все файлы - измененные и неизменные, но мне нужно только изменить. Этот трюк не решает проблему:

Сборка (сборка TFS), только то, что изменено

Подписан на пару других источников.

enter image description here

Применяли эти приемы для обновления проекта с несколькими настройками (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) в определении PropertyGroup до конца файла TFSBuild.proj.

Но проблема все еще сохраняется, мы не можем создать только измененные двоичные файлы в папке сборки, всегда есть все файлы.

Пожалуйста, помогите мне достичь желаемого результата сборки.

1 Ответ

0 голосов
/ 05 января 2019

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

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

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

PS: сборки типа TFSBuild.proj очень устарели. Они превзошли сборки XAML в TFS 2010 и с тех пор считаются «устаревшими». Впоследствии они были превзойдены новой системой сборки VSTS / Azure DevOps, которая отказалась от сборок XAML. Большинство свойств, которые взаимодействуют с Source Control, игнорируются, когда проект TFSBuild.proj выполняется в рабочем процессе Legacy XAML. Вместо этого агент XAML заботится о получении источников до передачи управления MsBuild. Эти новые задачи сборки VSTS / Azure Devops теперь также получают поддержку YAML для репозиториев управления исходным кодом на основе Git.

...