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

Question

目前，我们的组织不会实施持续集成。

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

除了通过早期发现和修复错误来节省成本之外，我对我可以在本文档中提到的其他好处/节省感到好奇。

Answer 1

我喜欢CI的第一个原因是它有助于防止开发人员检查破坏的代码，这有时会削弱整个团队。想象一下，如果我在去度假之前进行了一些涉及一些数据库模式更改的重要检查。当然，我的开发盒上的一切工作正常，但我忘了签入db schema的变更内容，这可能是也可能不是微不足道的。好吧，现在有一些复杂的变化涉及数据库中新的/已更改的字段，但是第二天在办公室的任何人实际上都没有新的模式，所以现在整个团队都在关闭，而有人正在尝试复制你已经完成的工作，只是忘了办理登机手续。

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

所以在我看来，避免这些情况中的任何一种都会使这种努力的投资回报很快得到回报。

Answer 2

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

以下是我学会解释的方法：“持续集成可以消除项目中的各类风险。”

Risk management对于程序管理员来说是一个真正的问题，他们在软件工程类型的正常范围之外，他们花费更多时间编写代码，而不是担心如何花费美元。有效地与这些人合作的一部分就是学会用他们能理解的术语来表达我们所知道的好事。

以下是我在这些对话中提出的一些风险。请注意，有了合理的项目经理，我已经在第一点之后赢得了论证：

1. 集成风险：在基于持续集成的构建系统中，诸如“他在回家度过长周末之前忘记检入文件”之类的集成问题不太可能导致整个开发团队失去整个星期五值得的工作。节省一个这样的事件的项目节省=团队中的人数（减去一个由于坏人忘记登记）*每个工作日8小时*每个工程师的小时费率。在这附近，这笔费用将达到数千美元，不会向项目收取费用。 ROI Win！
2. 回归风险：使用在每次构建之后运行的单元测试/自动测试套件，可以降低代码更改破坏用于工作的内容的风险。这更模糊，更不放心。但是，您至少提供了一个框架，其中一些最无聊和最耗时（即昂贵）的人体测试被自动化取代。
3. 技术风险：持续集成还为您提供了尝试新技术组件的机会。例如，我们最近发现Java 1.6更新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实际上有一些工作之前的中午。现在，除了每晚都有一个好的安装程序，我们实际上每晚都会安装在所有不同支持配置的VM上。所以现在当QA进来时，他们可以在几分钟内开始测试。现在，当你想到旧的方式时，QA抓住安装程序，启动所有vms，安装它，然后开始测试。对于每个QA人员，我们可以为每个配置节省QA大约15分钟。

Answer 8

有免费的CI服务器，以及像NAnt这样的免费构建工具。您可以在开发箱上实现它以发现好处。

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

Answer 9

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

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

因此，它有助于更​​快地失败，这有助于提前降低风险。