Team Foundation Server 中的增量构建问题 [英] Incremental Builds issue in Team Foundation Server

查看:25
本文介绍了Team Foundation Server 中的增量构建问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我们进行 TFS 构建时,我们是否可以更改构建输出,以便输出仅限于更改,从而减少部署负载?示例:

When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:

  • 当我构建解决方案时,我应该只获取更改过的 dll,而不是全部(包括 Microsoft 和其他从未更改过的 3rd 方 dll.

在 TFS 2015 中配置 CI 解决方案,以及未选中的清理选项,由于 TFS 2015/2017 始终交付所有文件 - 更改和未更改,但我只需要更改.这个技巧不能解决问题:

Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:

Build (TFS Build),只改变了什么

关注了其他几个来源.

应用这些技巧以少量设置更新项目(IncrementalBuild =TrueForceGet=FalseSkipInitilizeWorksplace=TrueSkipClean=True) 在 PropertyGroup 定义下添加到 TFSBuild.proj 文件的末尾.

Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.

但问题依然存在,我们无法在 build 文件夹中只生成更改的二进制文件,总是有所有文件.

But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.

请帮助我实现所需的构建输出.

Please help me to achieve the desired build output.

推荐答案

增量构建仅重建不依赖于已更改文件的程序集.但它确实复制了所有项目输出(依赖于它的后续项目可能依赖于这些程序集和文件).

Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).

这会导致增量构建更快,但它不会仅交付更改的文件".它始终交付所有文件,无论它们是否更改.最重要的是,您可以有多个代理,每个代理可以有多个工作文件夹,增量构建可以使用其中任何一个作为增量构建的基础,不能保证更改的文件在您之前的构建和当前构建之间一个.

This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.

您必须自己实现此功能,它从未成为 MsBuild 或 TFS Build 的一部分.这将涉及查询最后一个放置文件夹的 TFS 并在运行增量构建后执行比较.然后只复制更改的文件和已删除文件的日志.

You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.

PS:TFSBuild.proj 类型构建非常被弃用.它们已被 TFS 2010 中的 XAML 构建超越,并从那时起被视为遗留".它们随后被新的 VSTS/Azure DevOps 构建系统超越,该系统已弃用 XAML 构建.在旧版 XAML 工作流中执行 TFSBuild.proj 项目时,大多数与源代码管理交互的属性都会被忽略.相反,XAML 代理负责在将控制权传递给 MsBuild 之前获取源.这些新的 VSTS/Azure Devops 构建任务现在也获得了对基于 Git 的源代码控制存储库的 YAML 支持.

PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.

这篇关于Team Foundation Server 中的增量构建问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆