DevOps
开发模式演进
瀑布开发模式
-
-
过程
- 瀑布式开发模式将软件交付过程划分成几个阶段，从需求到开发、测试和运维，它的理念是软件开发的规模越来越大，必须以一种工程管理的方式来定义每个阶段，以及相应的交付产物和交付标准，以期通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。
-
问题
- 软件开发活动需要在项目一开始就确定项目目标、范围以及实现方式，而这个时间点往往是 我们对用户和市场环境信息了解最少的时候，这样做出来的决策往往带有很大的不确定性， 很容易导致项目范围不断变更，计划不断延期，交付上线时间不断推后，最后的结果是，即 便我们投入了大量资源，却难以达到预期的效果。
敏捷开发模式
-
-
核心理念
- 既然我们无法充分了解用户的真实 需求是怎样的，那么不如将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后 通过不断迭代，以小步快跑的方式持续开发。
-
过程
- 将测试工作从研发末端的一个独立环节注入整个开发活动中，对开发交付的内容进行持续验证，保证每次可交付的都是一个可用的功能集合，并且由于质量内建在研发环节中，交付功能的质量也是有保障的。
-
敏捷之所以更快，根本原因在于持续迭代和验证节省了大量不必要的浪费和返工。
-
问题
- 开发和测试团队发现，不管研发的速度变得多快，在软件交付的另一端，始终有一群人在冷 冰冰地看着他们，一句“现在没到发布窗口”让多少新开发的功能倒在了上线的门槛上。
DevOps开发模式
-
-
DevOps 最开始想要打破的就是开发和运维之间的对立和隔阂。
-
在传统模式下，度量开发团队效率的途径就是看开发完成了多少需求。于是，开发为了达成绩效目标，当然也是为了满足业务需求，不断地堆砌新功能，却很少有时间认真思考这些功能的可运维性和可测试性，只要需求状态流转到开发完成就万事大吉了。
-
而对于运维团队而言，他们的考核指标却是系统的稳定性、可用性和安全性。但现代 IT 系统是如此复杂，以至于每一次的上线发布都是一场战役，整个团队如临大敌，上线失败的焦虑始终如影随形。
-
另一方面，在无数次被开发不靠谱的功能缺陷蹂躏得体无完肤之后，运维团队意识到，变更才是影响他们绩效目标的最大敌人。于是，预先设立的上线窗口就成了运维团队的自留地，不断抬高的上线门槛也使得开发团队的交付变成了不可能完成的任务，最后，“互相伤害”就成了这个故事注定的结局。
