2009 年 6 月份，John Allspaw 及 Paul Hammond 在速度大会 (Velocity) 上分享了在 Flickr 中如何通过加强 Dev(开发团队)和 Ops(运维团队)之间的协作，从而加快应用部署频率的演讲 [2]。随后，关于 Dev 和 Ops 之间协作的讨论一直在 Twitter 上持续进行，当年的 10 月份，在 Twitter 上首次出现了 DevOps( 开发运维一体化 ) 一词 [1]。在随后的几年里，DevOps 不仅引起了工程界的大量关注和实践，同时，也吸引了大量学术界人士的兴趣。Gartner 2015 年所做的调查结果表明，目前已有 29% 的企业在使用 DevOps。图一所示为 Gartner 对各 IT 技术发展热度预测的研究，根据其研究，目前 DevOps 正处于其发展阶段的高潮期。
图 1. Gartner 关于各 IT 技术发展热度的预测
DevOps，其主要目的就是通过消除开发部门与运维部门之间的壁垒，从而使得一个企业的 IT 组织能够在敏捷地适应市场变化的同时，将一个企业的业务能力通过创新性的解决方案快速地从 IT 部门的开发过程推向用户。它主要利用了精益的思想 [4]，通过消除 IT 部门整个产品交付流中所存在的浪费及障碍，从而达到快速交付的目的。
对于一个较大的组织或者企业来说，其 IT 部门有其多年形成的固有组织结构、文化氛围、开发及发布流程、基础架构及产品体系等，在这种情况下，试图像新创的公司一样，很快就将整个企业的 IT 组织转型到 DevOps 上，显然是不现实的，也是不可行的。在这个过程中，必定会面临一定的困难与挑战。
大型金融企业在软件交付上通常面临的挑战
国内金融企业主要的开发发布模式
对于国内主要的金融企业，虽然有部分企业已经或者正在推行敏捷的开发方法，但是目前普遍采用的仍然是瀑布的开发方法(从立项、开发、测试到发布几个阶段顺次执行)，并且主要是以项目为单位进行人力资源的组织和开发过程管理。
一个项目主要是实现一个或者若干个需求，由项目经理主导，组织若干开发人员进行开发(对于大的项目，则可能还会跨越多个大的开发部门，包含多个小的开发小组)。需求主要是由业务单位提出的。在具体执行时，不同的业务单位都会提出不同的业务需求(不同的业务需求会成立不同的项目)，而且从每个业务单位的角度来说，都会要求其所提出的需求具有绝对的优先级，因此，在开发阶段，就不可避免地需要并行进行多个项目的开发。项目虽然是多个，但是其背后所修改到的代码及产品则可能是同一个，故而整个产品的交付过程自然而然就被分裂成了两个阶段：开发测试阶段和投产阶段。在开发测试阶段，最主要的是以项目为单位进行开发测试以及部署(每个项目的代码独立部署)，而在投产阶段，虽然也是以项目为单位进行相关的流程管理，但是在具体发布时，则是以产品为单位进行部署安装(不同项目中涉及到同一个产品的代码合并到一起发布)。由于项目与产品两个管理维度的切换，在实际的开发发布模式上，就主要演变出了如下三种模式：
按固定版本排期的开发模式
这是模式是按照一定的固定时间周期，统一将在此期间开发的所有项目代码合并到一个版本中进行测试并集中发布到生产环境，按照时间周期的不同，有的称为月度版本(即一个月度一个版本)，有的称为季度版本(即一个季度一个版本)。在这种模式之下，虽然开发过程是以项目为单位进行，但在真正的投产阶段却是以集中方式进行的，对于需要快速反馈响应的需求，也必须等到整个版本发布的时候才能统一发布。
按项目排期的开发模式
在这种模式中，每个项目都会安排好自己的测试和发布到生产环境的日期，然后按照自己的开发计划进行开发并发布。但是为了避免多个同时发布的项目重复执行多次发布，并且为了合并对于同一个产品在不同项目上所被修改的代码，对于在同一时间发布的项目，在发布前，会将多个项目的代码或者二进制码进行合并，然后一起发布。这种开发方式下，可以解决固定版本排期中，紧急需求无法快速发布的问题，但是同时所带来的则是频繁的生产环境发布，以及多个项目间的代码冲突合并。