翻译自 A Brief DevOps History: The Road to CI/CD。
CI/CD 的发展给我们带来的不仅仅是更快的软件更新。新型工具提供了更好的可观测性、安全性等。
我们的行业充满了流行语、行话和缩写。 DevOps 本身是 2008 年才被创造出来的一个术语，因此其中一些概念相对较新，但有些实际上已经很老了，它们的定义或用途随着时间的推移而发生了变化。
持续集成和持续交付 (CI/CD) 就是一个例子。它是 DevOps 的一个核心方面，但它比 DevOps 早了几十年，彻底改变了我们构建和发布软件的方式。
在 CI/CD 流行之前，发布软件是一项艰巨的任务。更新发布的并不频繁，有时一年一次，或更少。结果，更新量很大，网速也很慢，总是很费时间。
在软盘、CD 或优盘上提供软件的新版本并不少见。人们普遍认为更新会带来问题，而我们当时的做事方式意味着可能不会很快发布补丁。
这个问题不仅影响了其他企业和开发商，也影响了消费者。普通的非技术用户不得不关心更新软件的困难。
您可能知道特定应用程序运行的是哪个版本，并且更新始终是一项必须手动计划和处理的大任务。今天，我们大多数人根本不关心它，我们几乎没有注意到软件更新。
持续集成首先出现。这是定期将所有开发人员的工作代码库与主分支合并的实践，每天可能合并多次，Grady Booch 于 1991 年在他的“ Object-Oriented Analysis and Design with Applications ”一书中首次提出。他对持续集成的愿景并不建议每天发布多次，但这是第一步。
1997 年，基于 Booch 的方法建立的极限编程，提倡每天多次发布。回想起来这个名字听起来很荒谬，让人联想到前卫的 90 年代产品营销，但它意味着采用已经在编写和发布软件中被接受的概念和范例，然后将它们的实践夸大到极致。例如，代码审查这个概念被夸大为结对编程。 SCRUM 和 Kanban 等方法紧随其后，它们中的每一个都建立在之前的基础上，目标是更频繁地发布更多软件。
在早期，虽然我们认识到我们需要更频繁地发布，但我们并没有真正的工具来使它变得更容易。软件仍然主要由手工测试和交付。直到 2001 年，随着 CruiseControl 的发布，我们才获得第一个使持续交付更容易实现的开源工具。第一次，我们有了一个可以自己安装和运行的系统来自动管理构建，这让我们可以更频繁地发布。如果您使用的是 Eclipse，它甚至可以与您的集成开发环境 (IDE) 集成。 CruiseControl 是特定于 Java 的——例如，如果您正在编写 Ruby，则必须使用 CruiseControl 的 Ruby 变种。
十年后的 2011 年，Jenkins 发布了。它迅速超越了 CruiseControl，并且至今仍在广泛使用；它支持多种语言，几乎可以做任何你想做的事情，并且有一个庞大的社区，所以当你遇到困难时，其他人很可能遇到了同样的问题并记录了解决方案。 Jenkins 的成功导致了许多其他类似工具的发布，例如 Team City 和 Bamboo。
然而，Jenkins 这类工具开始显示出它的时代。你得自己架起基础设施，自己安装，还得有人负责维护。
缓慢但肯定的是，这些自托管、自管理的 CI 工具（如 Jenkins 或现已停产的 CruiseControl）正在被维护成本较低的云原生或托管服务（如 CircleCI、TravisCI 甚至 GitHub 自己的 GitHub Actions）所取代。
大多数主要的云提供商都提供自己的原生 CI/CD 工具。他们支持数十种语言和构建环境，知道如何处理 Docker 和 Kubernetes 等云原生技术，并直接与大量其他服务集成以处理部署、分析或可观测性。现在几乎任何事情都可以在您的流水线内实现自动化。
三十年前，更新一个软件需要几个月的时间进行大量重复的手动工作，最终导致下载速度很慢的新版本（如果不是很大，则必须在物理媒体上提供） ) 并可能引入比功能更多的问题。
今天，我们几乎没有注意到它们。软件更新可用时自动进行，消费者不再有理由知道或关心特定应用程序运行的版本。
CI/CD 的发展给我们带来的不仅仅是更快的软件更新。这种更频繁地发布的能力，加上 CI/CD 工具在流水线内部提供的强大环境，已经产生了我们认为对 DevOps 至关重要的新工具类别，我们将很难想象如果没有更好的 metrics、可观测性工具、tracing、基础设施即代码和整套安全工具等工具会怎么样。
这无异就是革命性的，我甚至无法想象再过 30 年我们会变成什么样子。
