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