通过共享工具和实践，包括小而频繁的更新，软件开发变得更加高效、快速和可靠。
根据定义，DevOps，即开发运维，概述了软件开发过程和组织文化的转变，这种转变促进了开发和
IT 运营
团队之间的协调与协作；这两个团队传统上是分开作业，或者各自为战的。
在实践中，最好的 DevOps 开发运维流程和文化超越了开发实践和运营，将所有应用程序利益相关者的意见纳入
软件开发生命周期
。这包括平台和基础架构工程师、安全、合规、治理、风险管理和业务线团队、用户和客户。
DevOps 开发运维原则代表了过去 20 多年来软件交付流程发展的现状。交付过程已从每隔几个月甚至几年发布一次大型应用程序范围的代码，发展到每天或每天数次发布迭代式较小特性或功能更新。
归根结底，DevOps 开发运维旨在满足软件用户对频繁创新的新功能以及不间断的性能和可用性不断增长的需求。
2000 年之前，大多数软件均使用瀑布法进行开发和更新，这是一种用于大型开发项目的线性方法。软件开发团队花费数月时间开发大量新代码，这影响了大部分或全部应用程序生命周期。由于更改范围十分广泛，他们又花了几个月的时间将新代码集成到代码库中。
接下来，
质量保证 (QA)
、安全与运营团队依然花费了数月时间来测试代码。而结果则是各软件发布之间需间隔数月甚至数年，且各发布之间通常还会出现若干重大补丁或错误修复。此大爆炸式功能交付方法通常具有以下特点：部署计划复杂且风险较高，面向上下游系统的联锁操作难以安排，同时 IT 部门非常希望在生产上线或正式发布 (GA) 版本之前的几个月内业务需求不会出现重大变化。
为了加快开发速度和提高质量，开发团队在本世纪初开始采用
敏捷软件开发
方法。这些是迭代方法而非线性方法，且专注于对应用程序代码库进行更小型、更频繁的更新。在这些 DevOps 方法中，最重要的是
持续集成
和
持续交付
(CI/CD)。
在
CI/CD
中，一小部分新代码会频繁地合并到代码库中，然后自动集成、测试和准备部署到生产环境。敏捷开发将大爆炸方法改为一系列更小的拼合动作，这也将风险分隔开来。
这些
敏捷开发
实践对软件开发和交付的加速效用越明显，就越清晰地暴露出 IT 运营、系统预置、配置、验收测试、管理和监控方面依然孤立的现状，而成为软件交付生命周期中的下一个瓶颈是此现状的影响之一。
因此，DevOps 源于敏捷。它增加了新的流程和工具，将 CI/CD 的持续迭代和
自动化
扩展到软件交付生命周期的剩余部分。整个过程的每一步，开发部门和运营部门都进行了密切协作。
团队使用测试（通常是自动化测试）来确保应用程序符合标准和要求。经典的 DevOps 方法包含在构建和发布之间发生的独立测试阶段。
不过，随着 DevOps 的发展，某些测试元素可以在规划（行为驱动开发）、开发（单元测试、合约测试）、集成（静态代码扫描、CVE 扫描、检查代码潜在问题）、部署（烟雾测试、渗透测试、配置测试）、运营（混乱测试、合规性测试）和学习（A/B 测试）过程中出现。
持续测试
是一种强大的风险和漏洞识别形式，为 IT 提供了直面、缓解或补救风险的机会。此外，
左移测试
是软件开发中的一种方法，强调在开发过程的早期移动测试活动。这种方法可以提高产品质量、扩大测试覆盖范围、提高反馈循环并加快上市时间。
发布阶段是运行诸阶段的第一个阶段，也是用户访问应用程序之前的最后一个阶段。
在此工作流中，运行时生成输出（来自集成）被部署到运行时环境，通常是执行运行时测试以确保质量、合规和
安全
的开发环境。
如果发现错误或缺陷，开发人员有机会在任何用户看到任何问题之前拦截和修复问题。通常有用于开发、测试和生产的环境，每个环境都需要越来越严格的质量管控。当开发人员修复了所有已识别的问题，并且应用程序满足所有要求后，运营团队确认其已准备好进行部署，并将其构建到生产环境中。
最好在早期和整个开发生命周期中解决监管
治理、风险和合规性 (GRC)
事项。受监管的行业通常被要求提供一定程度的
可观察
性、可追溯性，以及访问其运行时操作环境中功能交付和管理方式的权限。
这需要在
持续交付
管道和运行时环境中规划、开发、测试和执行策略。合规措施的可审计性对于通过第三方审计师证明合规性非常重要。
企业领导者普遍认为，如果没有对 DevOps 开发运维文化的投入，即采行软件开发的不同组织和技术方法，DevOps 开发运维方法就无法生效。
在组织层面，DevOps 需要所有软件交付利益相关者之间持续沟通、协作和分担责任。当然，这包括软件开发和 IT 运营团队，还有安全、合规、治理、风险和业务线团队，以便快速、持续地创新，并从一开始就注重质量。
通常，实现此目标的最佳方法是打破孤岛，并将人员重组为跨职能、自主的 DevOps 开发运维团队，这些团队可以从头到尾（从计划到反馈）处理项目，而无需跨团队交接工作或等待其他团队的批准。在敏捷开发的背景下，共同的责任和协作是共同
以产品为导向
并取得有价值成果的基石。
在技术层面，DevOps 开发运维要求致力于自动化
，以保持项目在工作流内和工作流间的运动。它还需要反馈和
衡量
，这使得团队能够不断加速周期并提高软件质量和性能。
云原生
是一种使用基础
云计算
技术构建应用程序的方法。云平台有助于在公共、私有和多云环境中实现一致且最佳的应用程序开发、部署、管理和性能。
如今，云原生应用程序的典型特征是：
-
使用
微服务
构建
：
松散耦合、可独立部署的组件，具有自己的独立堆栈，并通过 REST API、事件流或消息代理相互通信。
-
在
容器
中部署
：包含运行应用程序所需的所有代码、运行时和操作系统项的可执行代码单元。对于许多组织来说，容器是
Docker
容器的同义词，但还有其他容器可用。
-
使用
Kubernetes
执行（大规模）操作
：
一个开源
容器编排
平台，用于调度和自动执行容器化应用程序的部署、管理和扩展。
在许多方面，云原生开发和 DevOps 开发运维是天生一对。例如开发和更新微服务，即将小型代码单元迭代交付到小型代码库，非常适合 DevOps 开发运维的快速发布和管理周期。如果没有 DevOps 开发运维的部署和运营，就很难处理微服务架构的复杂性。
IBM 最近对开发人员和 IT 高管进行的一项调查
发现，78% 的当前微服务用户希望增加他们在架构上投入的时间、金钱和精力，56% 的非用户可能会在未来两年内采用微服务。
通过打包和永久修复所有操作系统依赖关系，容器可实现快速 CI/CD 和部署周期，因为所有集成、测试和部署都发生在同一环境中。Kubernetes 编排为容器化应用程序执行的连续配置任务与 Ansible、Puppet 和 Chef 对非容器化应用程序执行的连续配置任务相同。
大多数领先的云计算提供商，包括
AWS
、Google、Microsoft Azure 和
IBM® Cloud
，均提供某种托管的 DevOps 管道解决方案。
DevSecOps
是在整个 DevOps 生命周期内持续集成和自动化安全功能的 DevOps，从规划到反馈，再回到规划。
换言之，DevSecOps 就是 DevOps 从一开始
就应
有的样子。但是，采用 DevOps 所面临的两项早期重大（同时也是暂时无法克服的）挑战分别是：将安全专业知识集成到跨职能团队（文化问题），以及将安全自动化实施到 DevOps 生命周期中（技术问题）。在很多 DevOps 实践中，安全性均被视为一项无法实现的任务以及一个代价高昂的瓶颈。
DevSecOps 的出现是为了按照最初的预期来集成并自动实现安全性而做出的具体努力。在 DevSecOps 中，安全性是与开发和运营同等重要的“一等公民”和利益相关者，同时它还注重将安全性引入以产品为中心的开发流程中。
站点可靠性工程 (SRE)
使用软件工程技术来自动执行 IT 运营任务，例如生产系统管理、
变更管理
、
事件响应
甚至应急响应，否则系统管理员可能要手动执行这些任务。SRE 致力于将传统的系统管理员转变为工程师。
SRE 的目标类似于 DevOps 开发运维的目标，但更具体：SRE 旨在于组织对
快速应用程序开发
的需求，和满足与客户的
服务级别协议 (SLA)
中指定的性能和可用性级别的需求之间取得平衡。
站点可靠性工程师通过确定应用程序引起的操作风险的可接受水平（称为错误预算），并通过实现操作自动化来满足该水平，最终获得这种平衡。
在跨职能 DevOps 开发运维团队中，SRE 可以充当开发和运营之间的桥梁。SRE 提供团队所需的指标和自动化工具，以尽快通过 DevOps 开发运维管道推送代码更改和新功能，且不会违反组织的 SLA 要求。
随着可自动化任务范围的扩大，DevOps 中增加了更多功能，从而产生了 DevOps 的多种版本。随着 DevOps 证明了其自身的诸多好处，商业投资也随之增加。
据
Verified Market Research
称，2023 年 DevOps 的市场价值为 109.6 亿美元，预计 2031 年将达到 211.3 亿美元，2024 年至 2031 年的复合年增长率为 21.23%。
为了帮助确保 DevOps 开发运维的成功，企业越来越多地采用：
