DevOps实施过程中的烟斗曲线

1 软件工程方法的三次进化 1、20世纪70年代的软件危机与瀑布模型 上个世纪60年代计算机技术的快速发展与广泛应用，软件交付能力无法满足业务需求。 1970年，Rayce博士发表的一篇论文正式指出了“瀑布开发模型”，如图所示。 文中指 出 ，同一软件项目使用这一模型，需要实施两次，才能取得项目的成功。

2、20世纪90年代的敏捷与迭代 并没有人真正想理解Rayce博士这篇论文的意思，大家只想降低成本并希望保证成功。然而，历年的ChaosReport都一再说明，瀑布模型很难取得成功。而90年代开始，各路软件工程师开始创建不同的“敏捷方法”，以希望能够快速交付可工作的软件。由于每个项目的周期较长，并且在周期结束才会将软件进行部署发布，软件运维工作并不繁重。因此，这些方法仍旧关注于“如何快速地交付可工作的软件”。瀑布模型并没有消失，而是进入到更细的一个粒度，即“迭代粒度”，如下图所示。

3、21世纪10年代的DevOps与持续交付 随着互联网技术的广泛应用，以及面向海量用户的大规模软件部署需求增强，软件开发与生产运维之间的矛盾凸显，从业人员不得不再次重新思考新的工作方式与方法。 此时，与敏捷一脉相承的 DevOps运动应运而生，持续交付方法体系为DevOps的发展提升了明确的落地指导。 而瀑布模型仍旧存在，只是下降到更细的粒度，即“需求粒度”，如图所示。

2 软件交付环与角色合作 上述的演变都围绕着软件本身的构建与交付展开。最开始是交付的半环，现在变成了全环。而参与深度合作的角色也扩大到了运维人员，如下图所示。

3 DevOps是什么 直到目前为止，DevOps这一术语在行业内也没有一个统一的定义，这与“敏捷”很类似。 这也说明，DevOps也在一直发展和延伸。 我认为，就目前而言，敏捷和DevOps都是一场运动，“旨在寻找一系列方法或实践，以提升不同角色在软件交付过程中的协作质量与效率，从而提高软件服务的交付速度。 ”
4 DevOps在企业中的实践历程 很多团队在过去一段时间（可能是几年的时间）里，已经实施了各种各样的实践方法，在实践初期，会收到一些满意的结果。但是，随着各种实践的深入，会有一个平台期，并且，很少有团队能够快速跨越这个平台期，进入到下一个阶段，甚至会有一些倒退，如下图所示。

5 为什么会有这样的历程，如何跨越鸿沟 从不同的角度看待问题与解决方案，才能发现新的着力点。我们要一起寻找第二序变化

乔梁老师开课啦~视频课程 《持续部署实战解析（Golang版）》 ， 限时特价！

（扫码订阅）