Java 开发人员的 DevOps 工具

第 5 章 持续集成 持续集成

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

梅丽莎-麦凯

经常犯新错误

埃斯特-戴森

在第 2 章中，你了解了源代码控制和通用代码库的价值。在组织并确定了源代码控制解决方案后，您还需要采取几个步骤才能实现最终结果，让您的用户享受到已交付软件的完美用户体验。

想一想，作为一名开发人员，您在整个软件开发生命周期中推进软件开发的过程是怎样的。在确定了软件特定功能或错误修复的验收标准后，您将着手在代码库中添加实际代码行和相关的单元测试。然后，编译并运行所有单元测试，以确保新代码能按照您的预期（或至少按照单元测试的定义）运行，并且不会破坏已知的现有功能。发现所有测试都通过后，您将构建和打包应用程序，并在质量保证（QA）环境中以集成测试的形式验证功能。最后，当您从维护良好的测试套件中获得满意的结果后，您就可以将软件交付和/或部署到生产环境中。

如果你有任何开发经验，你就会和我一样清楚，软件很少会如此整齐划一。当你开始与一个开发团队一起开发一个更大的项目时，严格执行所述的理想工作流程就显得过于简单了。这就会引入多种复杂因素，使软件交付生命周期中的齿轮运转不畅，导致进度安排失调。本章将讨论持续集成以及相关的最佳实践和工具集将如何帮助你避开或减轻软件开发项目在交付过程中经常遇到的最常见的障碍和麻烦。

采用持续集成

持续集成（CI）最常见的 ，即经常将多个贡献者的代码变更集成到项目的主源代码库中。实际上，这个定义本身有点模糊。到底多频繁？在这种情况下，集成究竟意味着什么？仅仅协调将代码变更推送到源代码库中就足够了吗？最重要的是，这个过程能解决什么问题？

CI 的概念已经存在了很长时间。 根据 Martin Fowler 的说法，持续集成一词起源于 Kent Beck 的极限编程开发流程，是其最初的 12 项实践之一。在 DevOps 社区，这个术语本身现在就像吐司上的黄油一样常见。但不同团队和项目的实施方式可能各不相同。如果没有透彻理解其初衷，或者放弃了最佳实践，那么所带来的好处也是可有可无的。

有趣的是，我们对 CI 的理解随着时间的推移发生了变化。我们现在谈论它的方式与 Beck 最初为解决并发开发问题而引入它时大不相同。我们今天面临的问题更多是如何保持定期和频繁构建的效率，同时最大限度地减少错误，而最初，CI 及其衍生出的大量构建工具更多是为了让项目在开发完成后进行构建。 CI 要求改变思维方式，在开发过程中定期进行构建，而不是在团队完成所有编码后才组装项目。

如今，CI 的目的是通过定期和频繁的构建，在开发周期中尽快发现错误和兼容性问题。CI 的基本前提是，如果开发人员经常集成变更，就能在开发过程中更快地发现错误，从而减少查找何时何地出现问题的时间。一个错误未被发现的时间越长，它在周围代码库中根深蒂固的可能性就越大。

从开发的角度来看，发现、捕捉和修复漏洞要比发现、捕捉和修复漏洞要容易得多，而不是从已经进入交付流程后期阶段的代码层中提取漏洞。在最新验收阶段才被发现的错误，尤其是那些一直到发布阶段才被发现的错误，会直接导致修复费用的增加和新功能开发时间的减少。就修复生产中的错误而言，在许多情况下，除了在新版本中包含和记录修复内容外，现在还需要对现有部署打补丁。这必然会减少团队用于开发新功能的时间。

重要的是要明白，实施 CI 解决方案并不等同于软件永远不会出现任何错误。用这样一个明确的衡量标准来判断是否值得实施 CI 是愚蠢的。更有价值的衡量标准可能是 ...