Msbuild 如何避免构建和部署没有代码更改的依赖项

我正在做一个关于持续集成的概念验证，以及我们的开发团队是否会从自动化构建和自动化部署中受益，以减少人为错误。 在这个过程中，我已经走了相当远，但是对于如何配置增量构建以避免重建没有代码更改的依赖项，我有一些问题。 此外，我希望我们的部署工具只识别和部署因代码更改而重建的程序集

我们已经使用微软产品，如TFS用于源代码管理，VisualStudio用于开发和Team Foundation Budio用于持续集成构建。我们目前倾向于部署的发布，因为它似乎与Team Foundation Bug很好地结合在一起。 但首先，这是我们目前的设置

有200多个C#解决方案文件，每个文件包含一个或多个项目。在环境中，通过设计将这些项目组合成较少的解决方案是不现实的。解决方案中的项目使用项目引用来解析对其他解决方案中项目的依赖关系和文件引用。据我所知，这是微软在处理大量项目时推荐的方法

我们使用“按功能分支”策略，例如，在并发功能分支上进行独立开发，完成后合并为一个稳定的主分支。当发布时间到了，一个发布会从main分支出来，并隔离用于热修复和部署。功能分支和主分支具有由代码签入触发的CI生成。发布通常类似于从InRelease针对所选发布分支手动执行。一个版本将通过各种环境部署，包括集成/测试、UAT，并最终部署到我们的所有客户。我们仍在充实分支策略的细节，但这是另一个时间的问题

当前需要解决的问题：

1。避免重建没有代码更改的依赖项…

当我们向客户机部署新功能或补丁时，我们希望将文件中的绝对最小值推到最小。我们公司拥有非常庞大的客户群（数千名客户），有时互联网连接速度很慢，因此无法向每个客户全面部署所有组件（200+）。通过设置增量构建，我已经部分地解决了这个问题。增量构建只按照预期正确地重建已更改的项目，而且还重建所有相关项目，即使没有对它们进行代码更改。这将导致更改的程序集和依赖项都具有新的时间戳。如果我们使用时间戳的更改来标识要部署的程序集，那么这将导致部署功能不变的程序集。这里的目标是只部署代码已更改的程序集和发生重大更改的程序集

例如：

解决方案B有一个名为project B的项目 解决方案A有一个名为项目A的项目

项目B->项目A（其中项目A对项目B具有文件依赖关系）

当在项目a中进行非破坏性的更改时，比如对方法的内部进行更改，那么预期的结果是：只生成了一个，因此是部署的候选对象。 当在项目a中进行了一个中断的更改，然后该更改将中断项目B，预期结果是：a和B都已构建，因此是部署的候选对象。 目前，MSBuild将重建所有依赖项，这不是我们想要的

2。自动识别应部署哪些程序集…

我对这个问题有一个局部的解决办法。 执行生成时，我的生成过程模板配置为运行MSBuild脚本，该脚本包含要按特定顺序生成的解决方案列表。 此操作在生成代理的工作区中执行。每次执行新生成时，生成过程模板都会以该格式创建一个唯一的放置文件夹，并将二进制文件从生成代理工作区复制到放置文件夹。这是由标准构建过程模板负责的现成功能。生成已配置为不清除生成代理工作区，因此第一次运行时，它将生成解决方案中的所有项目，但后续生成将仅生成具有代码更改或依赖于其他项目的项目（增量生成？）。因此，未更改的程序集将具有原始时间戳，而更改的程序集将具有新的时间戳。 我们有一个工具，可以在拖放文件夹之间进行文件夹比较，并将结果输出到txt文件。这使我们能够识别自上次部署以来添加/更改/删除了哪些二进制文件。它还为我们提供了额外的好处，可以将实际的人工制品列表与开发人员定义的预期人工制品清单进行比较。这将确保不会部署未指定并经单元测试验证的程序集

问题是我们如何利用InRelease只部署上面示例中所需的文件，而不是部署drop文件夹中的所有文件

在生成计算机之前在中安装TFS代理，这将减少网络流量

您将从像Service Pack这样的分支策略开始，您可以阅读ALM Rangers指南中有关的文档。。。并调整您的流程模板，以仅构建更改的代码部分。我认为在BRD Lite，ALM Rangers的另一个指南中，您会发现更多信息