Проблема дополнительных сборок в Team Foundation Server
Когда мы выполняем сборку TFS, можем ли мы изменить выходные данные сборки так, чтобы выходные данные были ограничены только изменениями, чтобы уменьшить полезную нагрузку развертывания? Пример:
- Когда я создаю решение, я должен получить не только все измененные библиотеки DLL (включая Microsoft и другие библиотеки сторонних производителей, которые никогда не меняются).
Сконфигурируйте решение CI в TFS 2015 и не проверяйте чистые параметры, поскольку TFS 2015/2017 всегда доставлял все файлы - измененные и неизмененные, но мне нужно только изменить. Этот трюк не решает проблему:
Сборка (TFS Build), только то, что изменилось
Последовала пара других источников.
Применили эти приемы для обновления проекта с несколькими настройками (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) под определением PropertyGroup до конца файла TFSBuild.proj.
Но проблема все еще сохраняется, мы не можем создавать только измененные двоичные файлы в папке сборки, всегда есть все файлы.
Пожалуйста, помогите мне достичь желаемого результата сборки.
1 ответ
Инкрементные сборки перестраивают только те сборки, которые не зависят от измененных файлов. Но он копирует все выходные данные проекта (последующие проекты, которые зависят от него, могут зависеть от этих сборок и файлов, находящихся там).
Это приводит к тому, что инкрементные сборки выполняются намного быстрее, но они " не только доставляют измененные файлы". Он всегда доставляет все файлы независимо от того, изменены они или нет. Кроме того, у вас может быть несколько агентов, и у каждого агента может быть несколько рабочих папок, инкрементная сборка может использовать любой из них в качестве базы для инкрементных сборок, нет гарантии, что измененные файлы находятся между вашей предыдущей сборкой и текущей один.
Вам придется реализовать эту функцию самостоятельно, она никогда не была частью 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.