与持续集成相关的开销包括设置，重新培训，意识活动，停止修复最终导致数据问题的“错误”，强制分离关注点编程样式等。
持续集成在什么时候可以收回成本？
编辑：这些是我的发现
设置是带有Nant的CruiseControl.Net，从VSS或TFS读取。
以下是失败的一些原因，这些原因与设置无关：
调查成本：调查红灯是否是由于代码，数据质量或诸如基础结构问题（例如，网络问题，从源代码管理，第三方服务器读取的超时）之类的其他来源上的真正逻辑不一致所花费的时间掉了，等等，等等）
基础设施方面的政治成本：我考虑过在测试运行中对每种方法执行“基础设施”检查。除了更换构建服务器之外，我没有解决超时的方法。繁文tape节阻碍了系统，没有更换服务器。
修复单元测试的成本：数据质量问题引起的红灯可能表明单元测试写得不好。因此，重写了与数据相关的单元测试，以减少由于不良数据而导致出现红灯的可能性。在许多情况下，必要的数据被插入到测试环境中，以便能够准确地运行其单元测试。可以说，通过使数据更加健壮，然后依赖于该数据的测试就变得更加健壮。当然，这很好！
覆盖成本，即为现有代码编写单元测试：存在单元测试覆盖率的问题。有成千上万种没有单元测试的方法。因此，将需要大量的工作日来创建这些工作日。由于这很难提供业务案例，因此决定将单元测试用于以后的任何新公共方法。那些没有进行单元测试的人被称为“潜在的红外线”。此处的一个令人感兴趣的观点是，静态方法是如何唯一确定特定静态方法如何失败的争议点。
定制发布的成本：仅Nant脚本到目前为止。例如，它们对于EPiServer，CMS或任何面向UI的数据库部署的CMS依赖版本不是很有用。
这些是每小时进行一次测试运行和过夜进行QA生成时在生成服务器上发生的问题的类型。我认为这些是不必要的，因为构建大师可以在发布时手动执行这些任务，尤其是一个人的团队和一个小的构建。因此，以我的经验，单步构建并不能证明使用CI是合理的。那么更复杂的多步骤构建又如何呢？这些可能很难构建，尤其是在没有Nant脚本的情况下。因此，即使创建了一个，也不再成功。解决红灯问题的成本超过了收益。最终，开发人员失去了兴趣并质疑红灯的有效性。
经过一番尝试，我相信CI的成本很高，并且有很多工作要做，而不仅仅是完成工作。雇用经验丰富的开发人员，而不是搞乱大型项目，比引入和维护警报系统更具成本效益。
即使这些开发人员离开也是如此。优秀的开发人员是否离开并不重要，因为他遵循的流程将确保他编写需求规范，设计规范，遵守编码准则并注释其代码以使其可读。所有这一切都进行了审查。如果这没有发生，那么他的团队负责人就没有做好他的工作，这应该由他的经理接任，依此类推。
要使CI正常工作，仅编写单元测试，尝试保持完整的覆盖范围并确保可运行的系统的基础架构还不够。
最重要的是：人们可能会质疑，从业务角度来看，是否甚至需要在发布之前修复尽可能多的错误。CI涉及许多工作，以捕获少量错误，客户可以在UAT中识别出这些错误，或者无论如何在保修期到期时，作为客户服务协议的一部分，公司都可以获得酬劳。