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

Question

目前,我们的组织不实行持续集成.

为了让我们启动并运行CI服务器,我需要生成一个证明投资回报的文档.

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

Answer 1

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

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

因此,在我看来,避免这些情况中的单一情况将使这种努力的投资回报很快得到回报.

Answer 2

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

以下是我学会解释它的方法:"持续集成消除了项目中的各类风险."

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

以下是我在这些对话中提出的一些风险.请注意,有了明智的项目经理,我已经在第一点之后赢得了争论:

1. 集成风险:在基于持续集成的构建系统中,诸如"他在回家度过长周末之前忘记检入文件"之类的集成问题不太可能导致整个开发团队失去整个星期五的工作量.节省一个这样的事件的项目节省=团队中的人数(减去一个由于坏人忘记登记)*每个工作日8小时*每个工程师的小时费率.在这附近,这笔费用将达到数千美元,不会向项目收取费用.投资回报率赢!
2. 回归风险:使用在每次构建之后运行的单元测试/自动测试套件,可以降低代码更改破坏用于工作的内容的风险.这更模糊,更不放心.但是,您至少提供了一个框架,其中一些最无聊和耗时(即昂贵)的人体测试被自动化取代.
3. 技术风险:持续集成还为您提供了尝试新技术组件的机会.例如,我们最近发现Java 1.6更新18在部署到远程站点期间在垃圾收集算法中崩溃.由于持续集成,我们很有信心,更新17的备份很可能在更新18没有的情况下工作.就现金价值来说,这类事情要难得多,但你仍然可以使用风险论证:项目的某些失败=糟糕.优雅的降级=好多了.

Answer 3

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

这是你的号码.