DevOps (Development和Operations的组合词) 是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps 的起源可以追溯到 20 世纪 10 年代的精益运动。随着亨特·福特在 T 型车生产线中应用了精益流程管理，精益运动开始在制造业兴起。
自 20 世纪 30 年代起，丰田的丰田喜一郎(Kiichiro Toyoda)与大野耐一(Taiichi Ohno)将这项工作进一步扩展、细化及整理，二战后得以真正迅速发展起来。
20 世纪 50 年代，这项工作受到了戴明博士(Dr. William E. Deming) 提出的计划-执行-检查-处理(Plan-Do-Check-Act，PDCA) 循环理论的影响不断改进，以持续提高生产质量。基于其最为核心的方法，精益生产运动旨在持续改进产品质量的同时减少生产过程当中的浪费。
在詹姆斯·P·沃麦克(Jame P. Womack)和丹尼尔·T.琼斯(Daniel T. Jones) 1990 年出版的《改变世界的机器》以及1996年出版的《精益思想》这两本著作中，精益得到进一步的诠释。
2001年，敏捷出现了。包括阿利斯泰尔·库克伯恩(Alistair Cockburn)和马丁·福勒(Martin Fowler)在内的17个思想领袖发表了敏捷宣言。宣言的核心是摆脱僵化、瀑布式的、文档化的软件开发世界，这是大多少数软件开发项目延期、超预算或是惨痛失败的原因。他们的目标是找到一种迭代的方法，实现与客户、终端用户或代理人的持续互动。他们不想再通过诸如需求文档之类的主要硬性指标来衡量进度，因为这类指标不会提升代码的交付速度。另一目标是利用实际运行的代码(运行的软件) 作为衡量进度的真正标准；审视计划与实际进展的匹配程度；创建不需要预先编写，但会随着应用的开发而改进与完善的需求。
随着极限编程(Extreme Programming，XP)、敏捷软件开发(Scrum)以及近期出现的规模化敏捷框架或是 SAFe 这些方法论的发展，敏捷得到进一步提升。今天，无论大型还是小型的组织都在利用敏捷方法交付各种规模与技术的项目。敏捷是 DevOps 需求的前驱，并已成为核心的驱动力。随着开发人员加快代码交付速度，代码需要更快速地测试；还需要更加频繁地部署到开发及测试服务器，并最终部署到生产环境。但是运维团队并没有为此做好准备，这导致了开发到测试的交接过程中出现了瓶颈，因为测试无法根据需要按时创建适当的测试环境，更为重要的是发布时的生产环境。产品发布仍然是一个重大的任务，“发布周末”通常都会持续到周末以后。代码的短迭代快速开发，增强了开发与运维团队之间更好沟通与协作的需求。生产环境发布频频失败，反映出开发人员对类生产环境的访问需求。仅仅提高流程中的一个部分，即开发代码的效率，使整个流程的低效暴露无遗，这就导致测试与运维成为主要瓶颈。如果把应用开发及交付流程比作工厂里的生产线，在下游的工序仍然低效工作的情况下，仅仅加快其中某一道工序的工作速度来增加零部件的数量，对提高整条生产线的交付速度没有任何帮助，只会制造更多的积压而已。这不仅是运维的挑战，也是交付生命周期中所有利益相关者的挑战。
如今的焦点转向了周期时间最小化。周期时间指的是从需求或者用户故事开始到把功能交付到客户手中，或者至少是完成集成、测试并已为部署到客户机做好准备的时间。这导致了 DevOps 两项核心能力的发展：持续集成(已经是敏捷的核心竞争力)与持续交付。将运维团队纳入交付生命周期中，作为流程的一个部分，而非在代码发布前都不参与进来的独立仓筒，这种超越开发-测试周期的敏捷扩展已成为 DevOps 的核心原则。
DevOps 运动始于约翰·阿尔斯帕瓦(John Allspaw)和保罗·哈蒙德(Paul Hammond)【当时他们都服务于 Flickr/Yahoo】在 2009 O’Reilly 敏捷大会上的一次具有开创性意义的演讲。演讲的题目是《每天10+部署：开发与运维在Flickr的协作》。每天10次部署被认为是史无前例的。同年，帕特里克·德布瓦(Patrick Debois)在比利时根特组织第一次DevOpsDays活动时，最终将他们的方法称为 DevOps。这个名称由此开始流行起来并引发极大关注，但最初仅限于初创公司，更具体地说，是那些提供Web应用的组织。这些应用由开发人员(Dev)创建，他们通常以非常迅速的方式向其Web应用提交变更。他们所面临的主要障碍来自于运维(Ops)团队，由于变更管理流程僵化而且苛刻，以致运维团队在部署变更时速度非常慢。DevOps 运动的目标就是要解决开发与运维团队之间的阻抗失衡；弥合彼此之间的鸿沟；促进更多沟通、合作与信任。从本质上讲，这是一次文化运动，致力于改变开发与运维团队之间的文化差异，通过自动化使应用交付更快速、更高效并最终做到持续交付 。
2010年，当时在 ThoughtWorks 公司工作的杰兹·汉姆(Jez Humble)，在他的著作《持续交付》中编写了一些 DevOps 的核心实践，使得 DevOps 的实施变得切实可行，由此，将 DevOps 介绍给全行业的从业人员。不过，DevOps 被看作是那些独角兽公司才做的事情，也就是那些处在创新前沿的，没有大型的、复杂的遗留系统需要维护的初创型组织才做的事情，还没有为大型企业所关注。然而，这些大型企业看到初创公司运用 DevOps 所取得的成功，并且试图实施 DevOps 以满足其自身需求。像 IBM 这样的组织开始涉足自动化部署以及虚拟化环境架构，甚至将两种能力相融合。与此同时，像 UrbanCode 这样在自动化构建领域信誉卓著的公司，随着uDeploy的发布，也开始转向 DevOps，由此创建了一类新的持续交付工具。自动化领域的其他公司，比如Nolio也加入行列之中并提供自己的竞争产品。同时，运维和基础设施即代码(infrastructure as code)方面的公司，如Opscode(现在称为Chef)和Puppet Labs也受到关注(Opscode的Chef和Puppet Labs的Puppet)。
2012年，IBM利用 SmartCloud Continuous Delivery 开始了其第一项短暂的持续交付实验，自此，DevOps开始真正走进了大型企业。一些咨询公司，比如 Thoughtworks 和 IBM，也开始为组织，尤其是想要实施 DevOps 的大型组织提供咨询服务，协助其将独角兽公司的成功经验转换成企业适用模式。通过分别收购(巧合的是在2013年4月的同一天) UrbanCode 与 Nolio，IBM和CA Technologies宣布正式进军 DevOps 领域。
然而，DevOps 运动有史以来最重要的转折点是发生在 2013 年基恩·金(Genne Kim)的著作《凤凰项目》(Phoenix Project)出版的时候。这本书的灵感来源于艾利·高德拉特(Eliyahu M.Goldratt)的著作《目标》，正如高德拉特的著作曾领先制造业几十年的时间，《凤凰项目》现已成为现代IT界贯彻执行精益实践以及高德拉特约束理论的必读书籍。利用这本书，还有后来每年与杰兹·汉姆和帕比特·莱博斯联合发布的《DevOps现状调查报告》，基恩·金使DevOps真正成为主流。
总结起来，DevOps 起源相关关键词：精益、敏捷、极限编程、开发加速、运维瓶颈、DevOps沟通/合作/信任、持续集成、持续交付、从初创组织、独角兽到大型企业。DevOps 曾是一场文化运动，在如今已成为了一套文化处方。
参考资料：《DevOps实施手册-在多级IT企业中使用DevOps》