我的团队构建了一个基于 .NET 的软件和其他几个组件。目前使用 TeamCity 进行持续集成，MSBuild 用于简单编译 .sln 文件（以及其他一些小任务，例如单元测试）。
我们的源代码控制结构是这样的，即 repo 包含许多小型“插件”项目，这些项目在一次提交后被编译。
这使得仅仅构建已更改的组件以及仅交付稍后作为构建工件的组件变得困难。
将构建目标设置为“构建”而不是“重建”等解决方案在这里可能会有所帮助，但它似乎有点过于脆弱，尤其是在处理可以在任意数量的构建上进行构建的分布式构建环境时“代理”，即使是没有之前编译输出的代理。
我想知道解决这种情况的正确方法是什么？显然，这是一个已知问题，可能已经被许多人处理过。
我们希望构建和交付（每个构建）一组由当前构建（通过代码签入）修改的 DLL/组件。
我们可以实施哪些技术来实现这一目标？
【问题讨论】：
标签： build msbuild continuous-integration teamcity
这被称为增量构建，长期以来一直是 SCM 流程的一部分。 您的 Nant/msbuild 脚本应该能够从 CLI 进行增量构建和完整构建，否则它不被称为您的发布过程的完整独立构建设置。
将这些脚本连接到 CIE，例如 buildforge、jenkins、cnuisecontrol 等。
实现这一点的最好方法是在 Nant/Ant/msbuild 中使用一个开关，这样当您运行增量构建时，它不会删除旧的二进制文件，而是只编译最新的更改以创建与代码更改相关的二进制文件.
RTC Enterprise 构建确实有一个功能，它会在成功编译后构建本地工作区之后，将交付到您的流/分支，包括增量构建和完整构建。
但我建议我们使用构建脚本来实现这一点，而不是尝试通过 CIE 工具来实现，以便开发利益相关者可以完全控制他们的构建和打包逻辑，并消除对构建工程师（第三方独立实体）的依赖不了解应用程序编译逻辑的人，可以从大多数固有问题（如错误构建、人为错误等）中节省大量时间。
【讨论】：
一种解决方案是“构建”而不是“重建”。 如果构建在多个代理上运行，则在构建过程结束时将构建工件存档在共享位置，并在下一次构建开始时将这些工件复制到构建工作区（即，在他结束时自动归档工件）在构建开始时构建并复制它）。第一个构建将失败，因为将没有要复制的工件......因此保持该步骤在失败时继续或之前手动创建。运行他首先构建。 这肯定会使他的构建时间增加一到两分钟....因此请确保共享位置与您的构建代理位于同一网络中...
【讨论】：
您可能需要重新构建源代码控制，以便每个插件都位于自己的小项目中。它们都引用的共享代码将在它自己的项目中生成通用 DLL。
Liora 提到了一个资产存储库。这很重要，因为它将为您提供一个存储所有这些小库的地方。在 .Net 领域，我听到越来越多关于 NuGet 的消息。
这个想法是，当插件发生更改时，您的 CI 系统将接受该更改，拉入任何公共/共享库，然后执行构建，发布该插件的新版本。当共享代码更改时会发生什么更有趣。您可能只是构建它，或者您可能触发其所有依赖项的构建。
几年前我在一篇关于减少构建管理痛苦的文章中谈到了这一点：http://www.urbancode.com/html/resources/articles/build-pain-relief/components.html
【讨论】：
我不确定我遇到了正确的问题。但是，据我所知，您需要使用某种资产库来管理您的构建结果工件。资产更新后可以配置后续操作。
如果这能解决您的问题，请告诉我。
莉奥拉
【讨论】：