目前，我们的组织没有实施持续集成。
为了让我们启动并运行 CI 服务器，我需要制作一份文件来展示投资回报。
除了通过及早发现和修复错误来节省成本外，我很好奇我可以坚持到本文档中的其他好处/节省。
问问题
3542 次
9 回答
15
我喜欢 CI 的第一个原因是它有助于防止开发人员检查有时会削弱整个团队的损坏代码。想象一下，如果我在去度假之前进行了涉及一些数据库模式更改的重要签到。当然，在我的开发箱上一切正常，但我忘记签入可能是也可能不是微不足道的 db 架构更改脚本。好吧，现在有一些复杂的更改涉及数据库中的新/更改字段，但是第二天在办公室的人实际上没有那个新模式，所以现在整个团队都倒下了，而有人正在研究复制你已经做过的工作并且只是忘了签到。
是的，我用了一个特别讨厌的例子来改变数据库，但它可以是任何东西，真的。也许部分签入带有一些电子邮件代码，然后导致您的所有开发人员向您的实际最终用户发送垃圾邮件？你给它起名字...
因此，在我看来，避免其中一种情况将使这种努力的投资回报率很快得到回报。
于 2010-03-26T14:17:30.513 回答
10
如果您与标准项目经理交谈，他们可能会发现持续集成在简单的投资回报率方面有点难以理解：他们将获得什么样的实物产品来换取给定的美元投资并不是很明显。
这是我学会的解释它的方法：“持续集成消除了项目中的所有风险。”
风险管理对于软件工程类型之外的项目经理来说是一个真正的问题，他们花更多的时间编写代码而不是担心资金如何花费。与这类人有效合作的一部分是学习用他们可以理解的方式表达我们所知道的好事。
以下是我在此类对话中提到的一些风险。请注意，对于明智的项目经理，我已经在第一点之后赢得了争论：
- 集成风险：在基于持续集成的构建系统中，诸如“他在长周末回家之前忘记签入文件”之类的集成问题不太可能导致整个开发团队失去整个周五的工作价值. 避免发生此类事件的项目节省 = 团队人数（由于忘记签到的恶棍而减去 1）* 每个工作日 8 小时 * 每个工程师的小时费率。在这里，这相当于数千美元，不会向该项目收取费用。投资回报率赢！
- 回归风险：通过在每次构建后运行的单元测试/自动测试套件，您可以降低代码更改破坏某些用于工作的东西的风险。这更加模糊和不确定。但是，您至少提供了一个框架，其中一些最无聊和最耗时（即昂贵）的人工测试被自动化所取代。
- 技术风险：持续集成也让你有机会尝试新的技术组件。例如，我们最近发现 Java 1.6 update 18 在部署到远程站点期间在垃圾收集算法中崩溃。由于持续集成，我们非常有信心退回到更新 17 很有可能在更新 18 没有的情况下工作。这种事情很难用现金价值来表述，但您仍然可以使用风险论点：项目的某些失败 = 糟糕。优雅降级 = 好多了。
于 2010-03-26T15:21:48.497 回答
5
CI 协助发现问题。测量当前发现代码中损坏的构建或主要错误所需的时间。将其乘以在该时间范围内使用该代码的每个开发人员的公司成本。将其乘以一年中发生破损的次数。
有你的号码。
于 2010-03-26T15:08:36.200 回答
4
每个成功的构建都是一个候选版本——因此您可以更快地交付更新和错误修复。
如果您的构建过程的一部分生成安装程序，这也允许快速部署周期。
于 2010-03-26T14:15:22.483 回答
3
来自维基百科：
- 当单元测试失败或出现错误时，开发人员可以将代码库恢复到无错误状态，而不会浪费时间调试
- 开发人员不断检测和修复集成问题——避免在发布日期最后一刻出现混乱（当每个人都试图签入他们稍微不兼容的版本时）。
- 损坏/不兼容代码的早期警告
- 冲突变化的早期预警
- 立即对所有更改进行单元测试
- 用于测试、演示或发布目的的“当前”构建的持续可用性
- 立即向开发人员反馈他们正在编写的代码的质量、功能或系统范围的影响
- 频繁的代码签入促使开发人员创建模块化的、不太复杂的代码
- 自动化测试和 CI 生成的指标（例如代码覆盖率、代码复杂性和功能完整的指标）让开发人员专注于开发功能性、质量代码，并帮助开发团队的动力
- 最佳实用程序所需的完善的测试套件
我们使用 CI（一天两次构建），它为我们节省了大量时间，让工作代码可用于测试和发布。
从开发人员的角度来看，当自动构建结果通过电子邮件发送给全世界（开发人员、项目经理等）时，CI 可能会令人生畏： “加载‘XYZ.dll’的 DLL 构建失败时出错。 " 你是 XYZ 先生，他们知道你是谁 :)！
于 2010-03-26T14:15:17.447 回答
3
以下是我亲身经历的例子...
我们的系统有多个平台和配置，超过 70 名工程师在同一个代码库上工作。对于不太常用的配置，我们遇到了大约 60% 的构建成功率和最常用的 85% 的构建成功率。每天都有大量关于编译错误或其他故障的电子邮件。
我做了一些粗略的计算，估计我们每个程序员平均每天会因糟糕的构建而损失一个小时，这总计每天将近 10 个工作日。当程序员因为不知道最新代码是否稳定而拒绝同步到最新代码时，这还没有考虑到迭代时间所产生的成本，这让我们付出的代价更大。
在部署了由 Team City 管理的构建服务器机架后，我们现在看到所有配置的平均成功率为 98%，平均编译错误会在系统中停留几分钟而不是几小时，而且我们的大多数工程师现在都可以放心地使用最新版本的代码。
总的来说，我会说，与部署 CI 之前的三个月相比，在项目的最后三个月中，我们整体节省的时间保守估计约为 6 个人月。这个论点帮助我们获得了资源来扩展我们的构建服务器并将更多的工程师时间集中在额外的自动化测试上。
于 2010-03-26T17:08:15.950 回答
1
我们最大的收获是始终为 QA 进行夜间构建。在我们的旧系统下，每个产品至少每周一次，会在凌晨 2 点发现有人签入了错误代码。这导致 QA 无法在夜间构建进行测试，解决方法是向发布工程发送电子邮件。他们会诊断问题并联系开发人员。有时要等到中午 QA 才能真正开始工作。现在，除了每晚都有一个好的安装程序之外，我们实际上每晚都将它安装在所有不同支持配置的 VM 上。所以现在当 QA 进来时，他们可以在几分钟内开始测试。现在，当您想到旧方法时，QA 进来抓起安装程序，启动所有虚拟机，安装它，然后开始测试。我们为每个 QA 人员的每个配置节省了大约 15 分钟的 QA 时间来进行测试。
于 2010-03-26T15:17:57.913 回答
0
有可用的免费 CI 服务器和免费的构建工具，如 NAnt。您可以在您的开发盒上实施它以发现好处。
如果您使用源代码控制和错误跟踪系统，我想始终第一个报告错误（每次签入后几分钟内）将非常引人注目。再加上你自己的错误率下降，你可能会有一笔交易。
于 2010-03-26T15:44:06.270 回答
0
投资回报率实际上是提供客户想要的东西的能力。这当然是非常主观的，但是当最终客户参与实施时，您会看到客户开始欣赏他们得到的东西，因此您在用户接受期间往往会看到更少的问题。
- 会不会节省成本？也许不吧，
- 项目在 UAT 期间会失败吗？绝对不，
- 该项目会在两者之间关闭吗？- 当客户发现这不会产生预期的结果时，可能性很大。
- 您能获得有关该项目的实时和真实数据吗 - 是的
因此，它有助于更快地失败，这有助于更早地降低风险。
于 2014-04-16T11:10:57.927 回答