持续集成只是个脚本运行器
我们对持续集成的依赖已经远远超出了它最初的范围，这使它成为真正的开发团队提升速度的瓶颈。
译自 Continuous Integration Is Just a Script Runner 。
接收 GitHub 事件 → 克隆仓库 → 运行测试 → 报告结果，这就是持续集成(CI)的初衷，一个简单的服务就彻底改变了开发团队交付软件的方式。
它帮我们更快编写更可靠的测试，更早发现 bug，所以交付到生产的 bug 更少。“CI” 这个术语变得流行，这个实践像野火蔓延，帮助团队交付软件的速度更快、频率更高。
但随着云原生系统日益复杂，我们对 CI 的依赖已经远超其最初的范围。调整 CI 角色的第一步是接受：CI 只是个脚本运行器。
CI 已经演变成什么
这些年应用开发变化巨大。我们过去编译不同应用，在多个虚拟机中运行，现在把它们打包成不同的容器，部署在 Kubernetes 上。它们互相依赖，需要不同的存储，这些存储都需提前配置。然后，Kubernetes、Terraform、Serverless、端到端测试、云提供商认证等进入牌桌。
每次代码变更，你都需要确保这些不同组件能正常协同工作。你不想手动把二进制文件加载到 VM，或者手工在生产环境执行 Kubernetes 清单。你想要持续交付。这是业内真正的需求，最有可能帮你解决这个问题的，是 CircleCI、Travis、Jenkins 等 CI 服务商。
所以他们开始转型，从 CI 到完整的软件交付平台，提供复杂流水线、多种运行器、可组合配置、对各平台的集成。他们置身软件交付生命周期的中心，成功实现自动化交付。
但在此过程中，他们也成为更快交付的最大障碍。
CI 如何成为您的绊脚石
理论上，拥有一个工具来自动化构建、测试和部署流程，可以带来巨大的竞争优势，也可以节省大量手动运行和管理这些操作的时间。
但在实践中，这些平台最初仅仅作为任务执行器存在：它们起初是泛用型和与技术无关的。它们从未理解运行一个测试意味着什么，更不用说区分集成测试和端到端测试的不同之处，以及它们如何影响 CI 运行，也没有任何机制来定义这些差异。
这在您的应用复杂度增加时就成为一个问题了。CI 服务提供商试图通过多种方式解决这个问题 —— 提供定制的灵活配置选项，这反倒使得切换到其他提供商变得不可能。当您需要运行重负载时，它们提供了托管的运行器，但基础设施您仍需自己提供。它们提供了密码和配置功能，但配置工具非常糟糕，会把您锁定在它们的生态系统中。
这些工具对您的技术栈是如何构建的，您的服务依赖于什么，拉取请求之间代码变更了什么以及需要重新构建什么完全没有洞察。当然，它们允许您声明步骤之间的依赖关系，但维护实际的应用程序级依赖关系的认知负载仍然留给了最终用户。
原本应该是一个简单的任务调度和运行工具，却变成了一个难以调试的复杂单体，对系统几乎毫无描述，拖累您的团队。
CI 的未来
我相信团队开始意识到这些系统已经变得非常复杂和臃肿。我们现在确实需要 CI 系统当前拥有的自动化功能，但我们需要将其从 CI 服务提供商中解耦出来。
CI 的未来需要我们暂停一下，从一开始我们被承诺的重新开始：简单的版本控制集成、任务调度和运行。我们需要认真考虑 CI 应该做什么，相对于我们给它控制了哪些它不该控制的东西。
我期待看到成熟的平台和 DevOps 团队开发以下功能。
可移植的流水线
您应该能够在任何 CI/CD 提供商之间运行流水线。您的流水线应该能表达应用的复杂性，对依赖性敏感，随着应用或技术栈的增长而易于配置和编辑。它应存在于您的代码仓库中，完全独立且与平台无关。
如果我们当前的提供商提价了？我希望能够毫不费力地收拾包袱，在另一个平台上快速重建。或者我可以建一个内部平台，把我的流水线搬过去。
我想因为应用或技术栈更改而修改流水线，而不是因为提供商价格上涨或不再支持某些平台。
可调试的流水线
您应该能够轻松调试流水线。我们不应该认为 CI 提供商是不可访问的黑盒子，我们应该让流水线可以从任何地方运行：您的部署依赖中断了？我不想在我的机器上访问日志；我想在我的笔记本上运行流水线，实时查看执行日志。
我希望在将更改推送到代码库之前就可以调试新的测试设置。
提交、推送后等待 CI 反馈更改是否有效的时代已经过去了。
可组合的构建块
微服务架构教会我们，在某些场景下，将复杂领域分解成更小的子域可以是有益的。为什么我们不对交付过程做同样的事情呢？我们为什么更倾向于“智能”的全能解决方案而不是可组合性？我们应该努力用可组合的构建块来描述我们的系统及其之间的依赖关系。
让 CI 专注于它最擅长的：版本控制集成、任务调度和执行，以及报告错误。