Build 持续构建和交付仅更改的组件

我的团队构建了一个基于.NET的软件和几个其他组件。目前正在使用TeamCity进行持续集成，MSBuild仅用于编译.sln文件（以及一些其他小任务，如单元测试）

我们的源代码管理是以某种方式构建的，因此repo包含许多小的“插件”项目，这些项目在一次提交后就可以编译

这使得很难只构建更改的组件，也很难只交付那些以后作为构建工件的组件

在这里，将构建目标设置为“build”而不是“Rebuild”这样的解决方案可能会有所帮助，但这似乎有点过于脆弱，尤其是在处理分布式构建环境时，其中构建可以在任意数量的构建“代理”上进行，即使这些代理上没有以前的编译输出

我想知道解决这种情况的正确方法是什么？显然，这是一个已知的问题，可能已经被处理过，并且被许多人处理过

我们希望构建并交付（每个构建）一组由当前构建（通过代码签入）修改的DLL/组件

---

我们可以采用什么技术来实现这一点？

我不确定我是否遇到了正确的问题。但是，据我所知，您需要使用某种资产库来管理构建结果工件。更新资产后，可以配置后续操作

如果这能解决您的问题，请告诉我

---

Liora

您可能需要重新构建源代码管理，使每个插件都位于自己的小项目中。他们都引用的共享代码将在它自己的项目中生成公共DLL

Liora提到了一个资产存储库。这很重要，因为它会给你一个地方来存放所有这些小图书馆。在.Net领域，我听到越来越多关于NuGet的报道

其思想是，当插件发生变化时，您的CI系统将接受该变化，引入任何公共/共享库，然后执行构建，发布该插件的新版本。共享代码更改时会发生什么更有趣。您可以直接构建它，或者触发所有依赖项的构建

---

几年前，我在一篇关于减少构建管理的痛苦的文章中提到了这一点：

这被称为增量构建，很长一段时间以来一直是SCM过程的一部分。 Nant/msbuild脚本应该能够从CLI执行增量生成和完整生成，否则它不能称为发布过程的完整独立生成设置

将这些脚本连接到CIE，如buildforge、jenkins、cnuisecontrol等

实现这一点的最佳方法是在Nant/Ant/msbuild中使用一个开关，这样当您运行增量构建时，它不会删除旧的二进制文件，而是只编译最新的更改以创建与代码更改相关的二进制文件

RTC Enterprise build确实有一个功能，在成功编译本地工作区后，无论是增量构建还是完整构建，都会将交付后发送到流/分支

但我建议我们使用构建脚本来实现这一点，而不是试图通过CIE工具来实现，这样开发利益相关者就可以完全控制他们的构建和打包逻辑，并消除对不理解应用程序编译逻辑的构建工程师（第三方独立实体）的依赖，并且将从大多数固有问题（如错误构建、人为错误等）中节省大量时间。

一种解决方案是“构建”而不是“重建”。 如果构建在多个代理上运行，则在构建过程结束时在共享位置归档构建工件，并在下一个构建开始时将这些工件复制到构建工作区（即，在构建结束时自动归档工件，并在构建开始时复制）。第一次构建将失败，因为将没有可复制的工件…因此请将该步骤保留为“失败时继续”或在之前手动创建该步骤。运行他第一次构建。

---

这肯定会使构建时间增加一两分钟……因此，请确保共享位置与构建代理位于同一网络中……

这如何解决分布式构建的问题？如果下一个生成将在不同的代理上运行，则将二进制文件保留在生成代理上将是无用的。更正，我指的是单个生成代理，而不是多个。生成二进制文件可以以多种方式存档，并且不会存储在生成代理计算机（包括SAN）上。有些公司使用基于svn/subversion的文件系统解决方案来解决企业范围内的构建二进制文件存储解决方案，有些公司使用nexus Pro，有些公司和我们一样，我们只存储UAT和生产的最后15个构建，其余的我们将其归档。您能提供更多信息吗？这个答案没有提供任何信息来解决我提出的特定问题。