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

Question

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

为了让我们启动并运行 CI 服务器，我需要生成一份文档来证明投资回报。

除了通过尽早发现和修复错误来节省成本之外，我很好奇我可以将其写入本文档的其他好处/节省。

Answer 1

我喜欢 CI 的第一个原因是它有助于防止开发人员检查损坏的代码，这有时会削弱整个团队。想象一下，如果我在出发度假之前进行一次涉及某些数据库架构更改的重大签入。当然，在我的开发盒上一切正常，但我忘记签入数据库模式更改脚本，这可能很重要，也可能不那么简单。好吧，现在存在涉及数据库中新/更改字段的复杂更改，但第二天在办公室的人实际上没有人拥有该新架构，因此现在整个团队都陷入困境，而有人正在考虑重现您已经完成的工作，并且只是忘了签入。

是的，我使用了一个特别令人讨厌的数据库更改示例，但它实际上可以是任何东西。也许使用某些电子邮件代码进行部分签入会导致您的所有开发人员向您的实际最终用户发送垃圾邮件？你能想到的......

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

Answer 2

如果您与标准项目经理交谈，他们可能会发现从简单的投资回报率角度来看，持续集成有点难以理解：对于给定的美元投资，他们将获得什么物理产品并不是立即显而易见的。

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

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

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

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

Answer 3

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

这是你的电话号码。

Answer 4

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

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

Answer 5

来自 Wikipedia：

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

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

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

Answer 6

这是我自己经验中的例子...

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

我做了一些粗略的计算，估计我们每个程序员平均每天因糟糕的构建而损失一个小时，总共每天将近 10 个人日的工作时间。这还没有考虑到迭代时间内发生的成本，当程序员因为不知道它是否稳定而拒绝同步到最新代码时，这会让我们付出更多的代价。

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

所以它有助于更​​快地失败，这有助于更早地降低风险。