持续集成的7项核心原则

正确进行持续集成的组织都遵循一些基本规则。在本文中提出了持续集成的7个核心原则。

许多组织致力于DevOps，他们认识到持续集成（CI）和持续交付（CD）的好处。然而，令人惊讶的是，很少有人真正理解持续集成的核心原理。

很大一部分人认为他们正在进行持续集成，但实际上并非如此。难道你真的做持续集成？这是一个重要的问题。知道您的组织是否正在进行持续集成的关键问题包括：

1. 您是否定期将内部版本的内容输入组织的主要渠道？

2. 您可以在10分钟内解决软件问题吗？

毕竟，持续交付（CD）和DevOps正在扰乱市场并为企业提供巨大的竞争优势。持续交付基于持续集成的可靠实践。试图认识到持续交付的好处的组织通常无法完全理解持续集成的概念。

正确进行持续集成的组织都遵循一些基本规则。开发人员的工作副本至少每天一次（最好每天几次）与共享主线同步。每个集成都通过自动构建进行验证，以尽快检测到错误。持续集成本身就是一个旨在包含失败的过程，在该过程中，开发人员可能经常失败并迅速失败，因此他们可以及早发现并修复错误。不遵循这些步骤的组织实际上并没有正确地进行持续集成。

持续集成和您的DevOps团队

持续集成是一种开发团队实践，可为整个组织带来真正的利益。负责实施持续集成实践的工程师希望获得这些好处，并遵循同行所遵循的现代实践。通常，组织会听到其他团队如何实施持续集成，然后根据此做出决策。但是，一个基本问题是每个组织都是不同的。一些DevOps团队可能对他们的组织中的持续集成有一个愿景，但它可能不完全符合通常公认的定义。

不遵循持续集成核心原则的组织可能会遇到问题，无法定期提供清晰，有效的版本。随着时间的流逝，该计划将失去动力，团队成员将变得虚脱。抵制变革的人们（这是我们大多数人），如果他们看不到变革带来的好处的证据，他们将恢复到过去的做法。在这种情况下，您会遇到多个问题：您的构建仍然充满错误，您的团队对实现失去信心，失去了关键时间，现在您需要重新启动项目。

实现持续融合所需的文化转变

错误实施持续集成的组织通常会面临文化障碍。工程师擅长解决技术问题，但是CI要求文化上的转变，而且文化很难改变。您可以引入一个持续集成工具，并选中适用于CI应该代表的大多数框，但是要成功实现CI，则需要更改工作方式和协作方式。 如果团队的文化没有改变，他们将很难实施持续集成。

持续整合的原则

马丁·福勒（Martin Fowler）制定了持续集成的核心原则和实践至少15年，并且一直没有改变。这是组织正确执行CI所必须遵循的实践。

1. 提交主线：这是用于持续集成的赌注。开发人员可以设置一个自动构建，并在每次提交时都运行该构建。但是，如果文化不经常投入，那就没关系了。如果开发人员等待三周提交或分支三周，则他将延迟集成并破坏原则。如果构建失败，团队必须整理三周的工作来弄清楚它在哪里破裂。

2. 维护单一源存储库：在复杂的应用程序中，开发人员通常分支并维护主干（分支）或主干的更改。分支会增加复杂性，并阻止每个人使用单一的事实来源。团队每天至少需要一次提交/合并到主干或主干，或者对于每次更改甚至更好。

3. 自动化构建：大多数组织倾向于这样做。但是，有些声称练习CI的人只是在按计划进行构建（即每晚构建），或者是连续构建，但实际上并没有测试或验证每个构建。未经构建验证，您将无法进行持续集成。

4. 使构建进行自我测试：验证过程的第一步是知道有问题的构建实际上失败了。下一步是确定构建产品是否可运行以及构建是否按我们预期的那样执行。此测试应作为构建过程的一部分包括在内。这包括快速功能测试和非功能测试。

5. 快速构建：如果构建应用程序花费的时间太长，则开发人员将不愿意定期提交更改，否则会有更大的更改集。在任何一种情况下，没人会迅速发现故障。通过快速构建和快速集成，您可以快速隔离变更。如果需要几个小时才能运行，那么在此期间您可能还要进行20到30个更改，因此很难快速发现问题。

6. 在克隆中进行测试：验证过程可验证软件在其预期的环境中是否按预期运行。如果您在其他类型的环境中进行测试，则可能会得出错误的结果。

7. 立即修复已损坏的构建：对于开发团队来说，快速发现问题并立即修复它们至关重要，因此它们不会向下游移动。几年前，丰田公司制定了“停产线”方法，如果工人发现问题，他们可以拉绳子并停止制造过程。CI建立了一个持续验证和提交构建的过程，因此，如果出现问题，将很容易修复。

尽管组织在实现真正的持续集成方面面临着所有挑战，但重要的是要注意软件开发社区在遵循为自己的运营创造真正价值的现代流程方面走了多远。许多人都在努力进行更改并改善其DevOps实践。组织面临的最大障碍是员工对传统技术的文化，情感和技术依恋。只有克服了“不能做到的文化”，我们才能提供原始的持续集成。