持续集成的投资回报率是多少？答案

【问题标题】：What’s the ROI of Continuous Integration?持续集成的投资回报率是多少？
【发布时间】：2010-03-26 14:11:02
【问题描述】：

目前，我们的组织没有实施持续集成。

为了让我们启动并运行 CI 服务器，我需要制作一份说明投资回报的文档。

除了通过及早发现和修复错误来节省成本之外，我很好奇我可以在本文档中坚持的其他好处/节省。

【问题讨论】：

【解决方案1】：

我喜欢 CI 的第一个原因是它有助于防止开发人员检查有时会削弱整个团队的损坏代码。想象一下，如果我在去度假之前进行了涉及一些数据库架构更改的重要签到。当然，在我的开发箱上一切正常，但我忘记签入可能是也可能不是微不足道的 db 架构更改脚本。好吧，现在有一些复杂的更改涉及数据库中的新/更改字段，但是第二天在办公室的人实际上没有那个新模式，所以现在整个团队都倒下了，而有人正在研究复制你已经做过的工作并且只是忘记签到了。

是的，我使用了一个特别讨厌的 db 更改示例，但它可以是任何东西，真的。也许部分签入带有一些电子邮件代码，然后导致您的所有开发人员向您的实际最终用户发送垃圾邮件？你给它起名字...

因此，在我看来，避免其中一种情况将使这种努力的投资回报率很快得到回报。

【讨论】：

很好的例子。谢谢！我预计，这些场景会真正“推销”这项工作。
刚刚在我们的应用程序中使用了一个自定义模块。开发人员签入了所有新的代码文件，但没有签入包含引用的.csproj。我构建了模块并立即让我办公桌前的人告诉我构建错误......幸运的是，跟踪/修复很简单，但很多都不是。
@DaveE，是的，修复通常并不容易，但至少您很快就知道：如果让它们冷却，这些问题不会变得更容易解决。没有持续集成的开发总是让我想起老式的卡通炸弹，它的引信慢慢烧掉了......
@Bob - 多么棒的心理形象！我可能永远无法再次打开 VS 而不会在我的脑海中看到它......

【解决方案2】：

如果您与标准项目经理交谈，他们可能会发现持续集成在简单的投资回报率方面有点难以理解：他们将获得什么样的实物产品来换取给定的美元并不是很明显投资。

我是这样解释它的：“持续集成可以消除项目中的所有风险。”

Risk management 是一个真正的问题，对于那些在软件工程类型的正常范围之外的项目经理来说，他们花更多的时间编写代码而不是担心如何花钱。与这类人有效合作的一部分是学习用他们可以理解的方式表达我们所知道的好事。

以下是我在此类对话中提到的一些风险。请注意，对于明智的项目经理，我已经赢得了第一点之后的争论：

集成风险：在基于持续集成的构建系统中，诸如“他在长周末回家之前忘记签入文件”之类的集成问题不太可能导致整个开发团队失去整个周五值得的工作。避免发生此类事件的项目节省 = 团队人数（由于忘记签到的恶棍而减去 1）* 每个工作日 8 小时 * 每个工程师的小时费率。在这里，这相当于数千美元，不会向该项目收取费用。 ROI 获胜！
回归的风险：通过在每次构建后运行的单元测试/自动测试套件，您可以降低代码更改破坏某些正常工作的风险。这更加模糊和不确定。但是，您至少提供了一个框架，其中一些最无聊和最耗时（即昂贵）的人工测试被自动化取代。
技术风险：持续集成也让您有机会尝试新的技术组件。例如，我们最近发现 Java 1.6 update 18 在部署到远程站点期间在垃圾收集算法中崩溃。由于持续集成，我们非常有信心退回到更新 17 很有可能在更新 18 没有的情况下工作。这种事情很难用现金价值来表述，但您仍然可以使用风险论点：项目的某些失败 = 糟糕。优雅降级 = 好很多。

【讨论】：

你是对的。投资回报率最终会出现在标准项目经理面前。您的第一点也很准确（并且经常发生）。谢谢！
@Liggy，很高兴为您提供帮助。我将在 Wiki 上添加指向风险管理方法摘要的链接——我建议你用他们在那里使用的语言来表达你的 ROI 论点。您可能会赢得争论，并成为经理的有效沟通者。祝你好运！

【解决方案3】：

CI 协助发现问题。测量当前发现代码中损坏的构建或主要错误所需的时间。将其乘以在该时间范围内使用该代码的每个开发人员的公司成本。将其乘以一年中发生破损的次数。

这是你的电话号码。

【讨论】：

【解决方案4】：

每个成功的构建都是一个候选版本 - 因此您可以更快地交付更新和错误修复。

如果您的构建过程的一部分生成安装程序，这也可以加快部署周期。

【讨论】：

那是敏捷，而不是持续集成。 CI 只是意味着您知道构建是好的，而不是它随时可以发布......功能工作通常不完整。

【解决方案5】：

来自Wikipedia：

当单元测试失败或出现错误时，开发人员可以将代码库恢复到无错误状态，而不会浪费时间调试
开发人员不断检测和修复集成问题 - 避免在发布日期的最后一分钟混乱，（当每个人都试图签入他们稍微不兼容的版本）。
损坏/不兼容代码的早期警告
冲突更改的早期警告
立即对所有更改进行单元测试
“当前”构建的持续可用性，用于测试、演示或发布目的
立即向开发人员反馈质量、功能或系统范围的影响他们正在编写的代码
频繁的代码签入促使开发人员创建模块化、更少复杂的代码
从自动化测试和 CI 生成的指标（例如代码覆盖率指标、代码复杂性和功能完整）让开发人员专注于开发功能性、高质量的代码，并帮助在团队中发展动力
最佳实用程序需要完善的测试套件

我们使用 CI（一天两次构建），它为我们节省了大量时间，让工作代码可用于测试和发布。

从开发人员的角度来看，当自动构建结果通过电子邮件发送给全世界（开发人员、项目经理等）时，CI 可能会令人生畏： “加载 'XYZ.dll' 的 DLL 构建失败。” 你是 XYZ 先生，他们知道你是谁 :)！

【讨论】：

最后一点。公开羞辱是非常适得其反的。仅在此构建周期内通过签入向开发人员发送失败的构建电子邮件。
是的，这可能会很痛苦，尤其是如果您的同事在办公室 IM 上是 ..ehm..inopportune。

【解决方案6】：

这是我亲身经历的例子...

我们的系统有多个平台和配置，超过 70 名工程师在同一个代码库上工作。对于不太常用的配置，我们遭受了大约 60% 的构建成功，而对于最常用的配置，我们遭受了大约 85% 的构建成功。每天都有大量关于编译错误或其他失败的电子邮件。

我做了一些粗略的计算，估计每个程序员平均每天会因糟糕的构建而损失一个小时，这总计每天将近 10 个工作日。当程序员因为不知道最新代码是否稳定而拒绝同步到最新代码时，这还不包括迭代时间所产生的成本，这让我们的成本更高。

在部署了由 Team City 管理的构建服务器机架后，我们现在看到所有配置的平均成功率为 98%，平均编译错误会在系统中停留几分钟而不是几小时，而且我们的大多数工程师现在都可以轻松地停留在代码的最新版本。

一般而言，我会说，与部署 CI 之前的三个月相比，在项目的最后三个月中，我们总体节省的时间约为 6 个人月。这一论点帮助我们获得了资源来扩展我们的构建服务器并将更多的工程师时间集中在额外的自动化测试上。

【讨论】：

【解决方案7】：

我们最大的收获是始终为 QA 进行夜间构建。在我们的旧系统下，每个产品至少每周一次，会在凌晨 2 点发现有人签入了错误代码。这导致 QA 无法在夜间构建进行测试，解决方法是向发布工程发送电子邮件。他们会诊断问题并联系开发人员。有时要等到中午 QA 才能真正开始工作。现在，除了每晚都有一个好的安装程序之外，我们实际上每晚都将它安装在所有不同支持配置的 VM 上。所以现在当 QA 进来时，他们可以在几分钟内开始测试。现在，当您想到旧方法时，QA 进来抓起安装程序，启动所有虚拟机，安装它，然后开始测试。我们为每个 QA 人员的每个配置节省了大约 15 分钟的 QA 测试时间。

【讨论】：

【解决方案8】：

有可用的免费 CI 服务器和免费的构建工具，如 NAnt。您可以在您的开发盒上实施它以发现好处。

如果您使用源代码控制和错误跟踪系统，我想始终第一个报告错误（每次签入后几分钟内）将非常引人注目。再加上你自己的错误率下降，你可能会有一笔交易。

【讨论】：

【解决方案9】：

投资回报率实际上是一种满足客户需求的能力。这当然是非常主观的，但是当最终客户参与实施时，您会看到客户开始欣赏他们得到的东西，因此您在用户接受期间往往会看到更少的问题。

会节省成本吗？可能不是，
在 UAT 期间项目会失败吗？绝对没有，
项目是否会在两者之间关闭？ - 当客户发现这不会交付时，可能性很高预期结果。
您能否获得有关该项目的实时和真实数据 - 是的

因此它有助于更快地失败，从而有助于及早降低风险。

【讨论】：