devops handbook 读书笔记_【DevOps专刊】软件工程的三次进化——瀑布模型、敏捷开发与DevOps...

     软件工程这一学科出现于1968年，当时正值第一次软件危机。第一次软件危机是落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。人们试图借鉴建筑工程领域的工程方法来解决这一问题，以实现“按预算准时交付所需功能的软件项目”的愿望。

瀑布模型

     瀑布软件开发模型由W.Rovce在1970年发表的“Managing the development of large software systems”一文中首次提出，如图1所示。它将软件开发过程定义为多个阶段，每个阶段均有严格的输入和输出标准，项目管理者希望通过这种重计划、重流程、重文档的方式来解决软件危机。

     瀑布软件开发模型的每个阶段都需要花费数月的时间。在写出第一行产品代码之前，甲乙双方需要花费大量精力确定需求范围，审核比《新华字典》厚得多的软件需求规则说明书。即便如此，双方还是要为“是否发生了需求范围变更”“是否准时交付了需求”“交付的需求是否满足预先设定的业务要求”而纠缠不清。

敏捷开发方法

     Standish Group的Chaos Report 1994显示，软件交付项目的成功率只有16.2%。此时，很多优秀的软件工作者不满意瀑布软件开发方法的交付成果，并在各自工作实践中总结了新的软件开发方法，例如我们经常听说的Scrum和极限编程。

     2001年，17位软件大师总结了当时涌现出的轻量级软件开发方法具备的特点，共同发表了“敏捷宣言”，提出了敏捷开发应遵循的十二原则。并一致同意，凡符合这一宣言所倡导的价值观且遵循十二原则的方法均可被认为是“敏捷开发方法”。因此敏捷开发从其诞生起就是一簇软件开发方法的代名词，而不是特指某一种方法。

敏捷开发强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的产品。此时，很多团队已认识到，软件开发实际上是一个不断迭代学习的过程，即软件工程师需要快速学习并理解领域知识，并将其转化成数字世界的表达形式，通过与业务专家的交流讨论来学习并持续迭代这个过程。一个软件的交付计划被划分成多个迭代，强调每个迭代结束时应得到可运行的软件，如图

     与瀑布开发只在项目交付后期才能看到可运行的软件相比，敏捷开发在这方面有很大的进步。“持续集成”作为敏捷开发的一个工程实践，率先被更广泛的IT组织所接受，即便没有采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动构建和自动化测试减少了质量保障团队的重复工作量，也排除了开发团队与质量保障团队之间的沟通障碍。

DevOps运动

     DevOps的萌芽源于2008年敏捷大会的一个临时话题“敏捷基础设施”。当时独立IT咨询师Patrick Debois非常感兴趣，并分享了关于“将敏捷实践应用于运维领域”。2009年10月Patrick组织了一个“DevOpsDays”社区会议，并正式启用“DevOps”这个术语。

从时间几点上来看，DevOps源于敏捷思想和实践在运维领域的应用，但当时的实操指导性不足，而近乎同期出版的《持续交付》一书使其具体化，在企业实践方面更具有可操作性。书中给出了一系列的原则、方法和实践，使DevOps有章可循，例如持续交付中倡导的“一切皆代码、自动化一切，部署流水线尽早反馈”等。

      DevOps并非一个标准、一种模式或者一套固定方法，而是IT组织管理的发展趋势，通过多种打破IT职能部门之间的隔阂，改变IT组织内部的原因合作模式，使之更紧密，从而促进业务迭代速度更快。这种趋势将会改变IT组织内部原有角色和分工，甚至会影响到相关的业务组织。对于互联网公司，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强关联，因此顺应这一发展趋势的动力更加明显和迫切。既然DevOps是一种组织管理的发展趋势，那么它就是IT领域普适。对于不同行业，不同企业的IT组织，需根据其所在行业特点以及企业实际状况进行一系统的管理定制。