我正在做一个关于持续集成的概念验证，以及我们的开发团队是否会从自动化构建和自动化部署中受益，以减少人为错误。我已经在这个过程中走了很远，但是对于如何配置我们的增量构建以避免重建没有代码更改的依赖项有一些问题。此外，我希望我们的部署工具能够仅识别和部署由于代码更改而重建的程序集。
我们已经使用 TFS 等 Microsoft 产品进行源代码控制，使用 Visual Studio 进行开发，使用 Team Foundation Build 进行持续集成构建。我们目前倾向于使用 InRelease 进行部署，因为它似乎与 Team Foundation Build 很好地集成。
但首先，这是我们当前的设置......
有 200 多个 C# 解决方案文件，每个文件包含一个或多个项目。在环境中将这些项目组合成较少的解决方案（即通过设计）是不切实际的。解决方案中的项目使用项目引用来解决对其他解决方案中项目的依赖关系和文件引用。据我所知，这是微软在处理大量项目时推荐的方法。
我们使用“按功能分支”策略，例如在并发功能分支上进行隔离开发，完成后合并到一个稳定的主分支。当需要发布时，发布会从主发布分支并隔离用于修补程序和部署。功能分支和主分支具有由代码签入触发的 CI 构建。发布主要是从 InRelease 对选定的发布分支手动执行。一个版本将通过各种环境部署，包括集成/测试、UAT，并最终部署到我们所有的客户。我们仍在充实分支策略的细节，但这是另一个问题。
目前要解决的问题：
1.避免重建没有代码更改的依赖项...
当我们向客户端部署新功能或补丁时，我们希望将文件中的绝对最小化。我们公司拥有庞大的客户群（数千名客户），有时互联网连接速度很慢，因此无法为每个客户全面部署所有组件（200 多个）。我通过设置增量构建部分解决了这个问题，该构建只正确重建了预期的更改项目，但也重建了所有依赖项目，即使没有对它们进行任何代码更改。这导致更改的程序集和依赖项都具有新的时间戳。如果我们使用时间戳的更改来识别要部署哪些程序集，那么这将导致部署功能未更改的程序集。
例如：
解决方案 B，有一个名为 Project B 的项目 解决方案 A，有一个名为 Project A 的项目
项目 B -> 项目 A（其中项目 A 对项目 B 有文件依赖关系）
当在项目 A 中进行非破坏性更改时，例如对方法的内部进行更改，那么预期的结果是：只构建了 A，因此是部署的候选者。当在项目 A 中进行重大更改时，这将破坏项目 B，预期结果是：A 和 B 都已构建，因此是部署的候选者。目前 MSBuild 无论如何都会重建所有依赖项，这不是我们想要的。
2.自动识别应该部署哪些程序集...
我对这个问题有部分解决方案。执行构建时，我的构建过程模板被配置为运行 MSBuild 脚本，其中包含以特定顺序构建的解决方案列表。此操作在构建代理的工作区中执行。每次执行新构建时，构建过程模板都会创建一个唯一的放置文件夹，格式为并将二进制文件从构建代理工作区复制到放置文件夹。这是标准构建过程模板处理的开箱即用功能。构建已配置为不清除构建代理工作区，因此它第一次运行时将构建解决方案中的所有项目，但后续构建将仅构建具有代码更改或依赖于其他项目的项目（增量构建？）。因此，未更改的程序集将具有原始时间戳，而更改的程序集将具有新的时间戳。我们有一个工具可以在放置文件夹之间进行文件夹比较并将结果输出到 txt 文件。这使我们能够识别自上次部署以来添加/更改/删除了哪些二进制文件。它还为我们提供了额外的好处，即将实际人工制品列表与开发人员定义的预期人工制品清单进行比较。这将确保不会部署尚未指定和证明经过单元测试的程序集。
问题是我们如何利用 InRelease 仅根据上面的示例部署所需的文件，而不是放置文件夹中的所有文件？