所以，我有一个有趣的情况。我有一个小组有兴趣使用CI来帮助捕获开发人员错误。太棒了 - 我们都是为了那个。我围绕着事物的问题是他们想要建立彼此隔离的相互依赖的项目。
例如，我们有一个包含多个项目的公共/共享库的解决方案，其中一些项目依赖于解决方案中的其他项目。我希望如果有人向解决方案中的某个项目提交更改，CI服务器将尝试构建解决方案。毕竟，解决方案知道依赖关系并将以正确的顺序构建优化的东西。
相反，他们已经打破了每个项目，并试图独立构建它们，而不考虑依赖性。这会导致其他错误，因为依赖的DLL可能尚不存在（！），并且如果在两个或更多项目中进行了相关更改，则可能存在鸡与蛋问题。
这导致大量关于破坏版本的电子邮件（每个项目一个），即使最后一组更改没有真正破坏任何东西！当我提出这个问题时，我被告知这是一个已知问题，CI服务器会“重建几次以解决依赖问题！”
这听起来像是做构建CI的低音方式。但也许这是因为我年纪大了，对新趋势一无所知 - 所以，正如任何人都知道CI设置独立建立相互依存的项目一样？有什么好的理由？
哦，他们希望我们使用CI流程的构建输出，并且每个构建的DLL都可能获得不同的版本号。因此，我们不再为所有相关DLL的输出提供单个版本号。我们可以确定的最好的东西是在特定的日历日建立的。
我似乎无法让他们相信这是 A Bad Thing 。 那么，我在这里错过了什么？
谢谢！
和平！
答案 0 :(得分：1)
我赞同你的意见。
与实际问题相比，您可能会花费更多时间处理不必要的噪音。重复部分CI验证管道只会延长整个CI执行时间，这违背了减少反馈循环的CI目标。
如果有的话，你应该尝试在同一个CI保护伞下尽可能多地提供相关项目（理想情况下都是这些项目），以最大限度地发挥整个系统任何部分的破损/回归快速反馈的好处。 / p>
就我个人而言，我还提倡使用门控CI系统（基于预先提交验证）来防止回归，而不仅仅是检测它们，并依靠人为干预进行修复。