“持续集成” - 我应该采用它吗？

暂时别管“**怎么做**”；想想**你为什么要采用持续集成**。

首先让我们设定一下文章的背景。很多人可以按照指示做事，但只有极少数人是决策者。是什么让后者如此特别？是他们思考周围事物的方式。他们根据自己的能力提出问题并进行自我研究，他们从不盲目依赖伟人们所说的话，他们挑战这些说法，并通过这样做来掌握它们，并将自己塑造成决策者。

与上述理念一致，本文将重点关注“**我为什么要采用它**”而不是“怎么做”。这里的“它”指的是“**持续集成-构建与部署**”。我在广泛使用的术语中明确添加了*部署*，因为我觉得它是一个非常相关的术语。

我不会过多地深入枯燥的理论，但我会用简单的语言来概括它。它是一个自动化的过程，可以持续构建您的项目并部署它。

让我们试着回答我们应该关心的问题，即“我为什么要采用它”。

采用持续集成、构建和部署有很多驱动因素 - 我将逐一讨论它们。阅读本文时，不要考虑“如何”。有很多在线资源可用，我们大多数人都足够聪明可以利用它们。很少有人会向你提供知识来判断它是否适合你的情况。在本文的最后，我确信你们中的许多人将能够更好地做出这方面的决定。

我将从现在开始将**持续集成 - 构建和部署称为 CIBD**（是的，我很懒 :））

驱动因素 1：最大限度地减少花费的精力

想想我们可怜的集成者和部署团队所花费的精力。每当需要发布版本/补丁时，我们可怜的人们都必须在办公室里熬夜才能获得可怜的成功。真正的痛苦是构建时间、查找和协调错误修复、单元测试、冒烟测试、测试团队协调、创建和部署部署包以及通知利益相关者等等。很长的一个清单。一个中等规模（1 万行代码）的基于 Web 的应用程序对于列出的所有活动，一次迭代至少需要花费 2-3 人天的时间，而且这种情况非常频繁。迫切需要自动化，答案是采用 CIBD。

驱动因素 2：监控故障并在发现时进行纠正

故障指的是构建错误、链接断裂或任何其他可怕的错误。故障会带来非常困难的时期，第一个挑战是找到它们，更大的挑战是解决它们。尤其是在构建需求不太频繁的情况下。在这种情况下，过了一段时间后，当集成者开始集成所有模块时，他/她会发现其中存在许多致命问题，然后一切都会堆积到一定程度，从而导致交付推迟。有时，它会为最终客户带来关键的业务风险。为了纠正这一点，CIBD 是解决方案。 CIBD 将持续构建您的代码块，最好是在源代码控制服务器中每次提交代码时构建，如果出现任何故障，则会抛出错误。罪魁祸首（我们中的一员）将被迫修复它。使用 CIBD，您肯定会纠正第 11 小时的恐怖发现，并帮助我们顺利交付。

驱动因素 3：所有权意识和对不当行为的恐惧

有了 CIBD，使用源代码控制提交日志可以很容易地抓到罪魁祸首，例如导致构建失败的实例。这将在团队成员的思想中嵌入一种积极的恐惧 - 没有人希望因为不当行为而被突出显示并面临夸大的指责，这使得他们在服务器上提交任何内容之前对代码和单元测试格外谨慎。这纠正了很多返工。

驱动因素 4：辅助增加范围

为了实现广泛的自动化，我们可以加入一些辅助的东西，例如静态代码分析工具、自动化单元测试工具、代码覆盖率工具、自动化系统测试工具、健康监视器、配置管理实用程序。添加这些将使您的整个过程更具弹性，并进一步节省时间-精力-成本。

驱动因素 5：统计数据

这是一个分析的时代 - 预测性的、描述性的，不管是什么 *tive。 CIBD 将为您提供构建的统计数据，包括成功率、失败率和基于团队的细分等等，都可以在非常漂亮的图表中显示。这在向管理层炫耀报告时非常有用。

驱动因素 6：古老的因素 - 代码覆盖率、单元测试，等等等等...

还有更多要添加的内容，您可以在任何 CIBD 文章中找到。这里列举一些 - 代码覆盖率、单元测试等。我认为它们是不言自明的 - 无需解释。

**最后**，有了这六个驱动因素，针对您的特定情况对所有六个因素进行断言，看看其中有多少个是“是”，如果大多数是，那么 CIBD 就是您应该选择的方式。