DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
传统的软件组织将开发、IT运维和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。按照从前的工作方式，开发和部署，不需要IT支持或者QA深入的跨部门的支持；而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。 从2009年起，相关的工作组、专业组织和博客快速涌现。
DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入DevOps：
DevOps经常被描述为“开发团队与运维团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：
很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在开发与运维部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。
一般而言，当企业希望将原本笨重的开发与运维之间的工作移交过程变得流畅无碍，他们通常会遇到以下三类问题：
要开始优化发布流程，可以从问题识别开始：看看上面提到的哪种问题在你的团队中具有最高的优先级。
这是企业级IT组织中一个新出现的角色，其主要任务就是协调安排将企业级软件部署到预生产环境。对发布协调人的需求来自于以下几方面原因：
发布协调人的角色（也被称为部署协调人或集成协调人）源自发布管理或发布工程团队。这个角色与航空交通管制有些类似──实时协调不同团队的行动，有效使用共享的资源（空域、航道、跑道、航站门），达到组织的总体目标（安全起降）。
传统意义上的发布管理往往只关注软件变更的计划与管理，发布协调则需要控制“将特定软件变更发布至生产环境”的整个过程。这项工作需要系统地管理所有与“将代码构建并部署到生产环境”相关的技术任务，也被称为“发布工程”。
变更管理是跟踪企业IT环境中各种变化──不管是应用程序还是基础设施的变化──的基本原则。变更管理是ITIL v3的核心之一。
