什么是正确的持续集成？

持续集成（CI）令人困惑。就像所有概念一样，每个人在实践中都有自己的一套实现方式。

持续集成（CI）旨在解决我们在编写、测试和交付软件给最终用户过程中遇到的问题。其核心优势在于可靠性。

持续集成的前提条件是拥有自动化测试套件。这并非易事。学习编写自动化测试并掌握测试驱动开发需要多年的实践。然而，在不断增长的应用程序中，我们开发的测试反而可能成为生产力的绊脚石。

我们是否在做持续集成？

我们以两个都在编写测试的开发团队为例。第一个团队的持续集成构建运行时间约为 3 分钟，而第二个团队则需要 45 分钟。他们都使用持续集成服务器或基于云的持续集成服务，在特性分支上运行测试。他们都以可预测的周期发布可靠的软件。但是，他们都在进行正确的持续集成吗？

Martin Fowler 最近分享了Jez Humble 执行的非正式 CI 认证流程的描述：

他通常会在认证过程开始时，询问与会者中是否有人进行持续集成，如果有，请举手。通常情况下，大多数与会者都会举手。

然后他要求他们，如果团队中的每个人至少每天都向共享主线（通常是 git 中的共享 master）提交和推送代码，就请举手。

超过一半的手都倒下了。

然后他问他们，如果每次提交都会触发自动构建和测试，就举手。剩下的人中有一半放下了手。

最后他问，当构建失败时，通常会在十分钟内恢复正常吗？

最后一个问题问完后，只剩下寥寥几只手举着。这些人通过了他的认证考试。

软件开发还是剑术对决？

如果持续集成构建耗时过长，以至于我们有时间在等待期间练习
剑术，我们就会采取防御性的工作方式。我们倾向于将分支长时间保留在本地计算机上，因此每个开发人员的代码状态都存在显著差异。合并操作变得更加罕见，而且每次合并都可能规模庞大且风险极高。要大规模地进行重构以维持系统的健康运行，将变得异常困难。

构建速度慢的时候，每次“git push”都会让我们陷入困境。我们要么等待，要么找点别的事情做，以免完全无所事事。如果我们切换到其他任务，也知道构建完成后还得再切换回来。问题在于，编程中的每一次任务切换都很费力，而且会消耗我们的精力。

持续集成中的“持续”二字，关键在于速度。速度是提高生产力的关键：我们希望尽快获得反馈。快速的反馈循环能让我们保持心流状态，而心流正是我们工作幸福感的源泉。

因此，有必要制定标准来明确什么是真正的持续集成以及如何进行持续集成。

十分钟测试

很简单：从提交新代码到 获得结果，你的时间是否少于 10 分钟
？如果是，恭喜你，你的团队已经具备了高效工作的条件。如果不是，那么你的工作流程充其量只能算是持续集成流程的雏形。然而，这种缓慢的效率会养成不良习惯，损害团队中所有开发人员的生产力，最终影响整个公司的业绩。

没有人会故意构建一个低效的交付流程。然而，我们却忙于编写代码，直到感觉自己像温水煮青蛙——直到我们接受了现状，才意识到变化。当然，我们的构建过程耗时很长，毕竟我们有超过 10,000 行代码！

隧道尽头的曙光

但事情并非必须如此。无论您的测试套件规模有多大，并行测试都能将等待时间缩短至几分钟甚至更短。一个快速的托管式 CI 服务，能够让您轻松并行测试并根据需要进行扩展，这将带来巨大的改变。正因如此，对于Semaphore而言，提供最快的 CI/CD 性能是我们的核心产品原则之一。通过并行测试，您可以减少等待期间用于决策的时间，让您的团队保持高效工作状态。

本文最初发表于 Semaphore 博客。很高兴分享到 dev.to——请在评论区留下您的反馈。✌️