下载掌阅APP，畅读海量书库
立即打开
随着信息技术的不断发展和迭代，越来越多的企业陆续将新一代信息技术应用于自身业务处理过程中，进行数字化转型，进而持续提升企业效能和核心竞争力。然而，新兴信息技术的广泛应用、持续更新，以及与用户需求的相互促进，使得用户对软件产品和信息技术服务的需求越来越多。因此，在保证软件产品和相关服务高质量交付的前提下，快速响应市场变化、满足用户需求无疑是飞速发展和变化的市场对软件开发提出的新要求。
在“快鱼吃慢鱼”的互联网时代，诸如上线时间等已经成为衡量快速响应市场能力的重要指标之一。然而，传统瀑布式开发的周期动辄以年计，越来越不能满足当下的市场需求。为了快速响应市场变化，敏捷思想被引入软件开发领域，之后以业务需求进化为核心、以版本迭代为典型特征的各种敏捷开发模式被陆续提出，其中就包括敏捷开发和DevOps。
1970年，Winston Royce在Proceedings of IEEE WESCON（8月刊）发表的“Managing the Development of Large Software Systems”一文中正式提出对软件开发管理产生重要影响的瀑布模型。传统的瀑布式开发就是基于瀑布模型提出的，核心思想就是将软件开发过程中的问题简单化，按照软件开发流程将业务功能的编码实现与设计分离，以便开发团队各个角色协作。
在瀑布模型中，软件生命周期被划分为6个基本阶段，分别为制订需求收集计划、需求分析、设计、开发、测试和部署阶段；每一个阶段自上而下地按顺序完成，不能跳跃，如图3-1所示。
图3-1 瀑布模型示意图
在传统瀑布式开发过程中，软件开发各个阶段的活动同样严格按照线性顺序进行，要求每个阶段的活动必须为下一阶段活动的执行提供保障，否则流程不得进入下一阶段。也就是说，当前阶段的活动是在上一阶段活动结果的基础上实施的。
因此，为了确保一次性交付软件开发成果，传统瀑布式开发仅适用于需求已知和业务明确的场景。此外，文档是传统瀑布式开发过程管理的主要通信机制。传统瀑布式开发尤其注重文档的撰写，要求在每个阶段仔细验证对应的文档。
但是，由于瀑布模型的线性执行风格过于理想化，且传统瀑布式开发过于强调文档在开发过程中的作用，故而对于当下更要求快速迭代、快速交付的应用场景来说，传统瀑布式开发变得越来越难以适应。导致这一现象出现的主要原因如下。
1）每个阶段的划分不变，阶段与阶段之间的信息需要通过文档传递，大大增加了开发团队的工作量。
2）瀑布模型的线性执行风格使得在传统瀑布式开发过程中只能到了末期才能看到开发成果，如果开发成果不能令人满意就要返回到最初的阶段重新进行开发，增加了开发的风险以及时间成本。
正因为这些不利因素的存在，越来越多的开发者已经开始转向更为灵活的敏捷开发，甚至直接实践DevOps。然而，尽管传统瀑布式开发在应用于一些场景（例如复杂的、大规模的、长期的软件开发项目）时存在着诸如不能很快获得可用的软件版本、识别问题滞后、开发始终处于高风险和不确定中以及开发进度难以从全局进行预估等问题，更有一部分开发者认为传统瀑布式开发已经过时，敏捷开发才是未来的趋势，但是，对于软件开发来说，开发模式的选择主要是看其与应用场景的贴合程度。对于业务需求并不复杂的场景（例如需求明确的中小型项目），瀑布式开发仍不失为一种不错的开发模式。其具有容易上手、过程管理简单、可视化程度高等优势，若能被合理应用仍能大大提高软件开发效率。
敏捷开发（又称敏捷软件开发）是从1990年开始被逐渐引起广泛关注的一系列具有某些相同特点的新型软件开发方法的总称。虽然这些新型软件开发方法的具体名称、流程、术语等不尽相同，但是相较于非敏捷方法（又称前敏捷方法，例如瀑布式开发），敏捷开发方法能够应对快速变化的需求。
在实践中，敏捷开发尤其强调开发团队与业务专家之间的紧密协作，强调高效的沟通，强调尽早交付一个可用的软件版本和渐进式开发、持续迭代、增量交付新的软件版本，强调持续改进和较短的反馈回路以快速且灵活响应，强调紧凑的自组织型团队和能够适应需求变化的软件编码和项目管理方法，以便通过自组织和跨职能团队与用户协作努力在软件开发过程中发现需求和改进解决方案。
总体来说，敏捷开发主要以用户需求为核心，以迭代更新、循序渐进的方式推进软件开发。然而，敏捷开发并没有针对软件开发过程规定一套确定的和普遍适用的具体流程。事实上，敏捷开发只是描述了一系列与之配套的软件开发价值和原则。正因为如此，敏捷开发才具有极大的灵活度。在为软件开发提供巨大灵活性的前提下，敏捷开发范畴下的各种软件开发方法遵循一套共同的迭代开发基本流程。而敏捷开发模型提供这样一个基本流程。在敏捷开发模型中，从明确需求到架构设计，从架构设计到开发，从开发到测试反馈，再在测试反馈基础上进一步明确需求，周期性循环执行，构成一套闭环的敏捷开发基本流程，如图3-2所示。
图3-2 敏捷开发模型示意图
具体来说，当敏捷开发应用于软件开发项目时，开发者通常会在项目初期就将整个项目分成若干个子项目，并且对每个子项目的开发成果进行严格测试，使之达到可视的、可集成的和可独立运行的，以及确保在第一次交付后就始终处于可运行状态。
此外，在敏捷开发过程中，开发者通常不会在前期就奢望完美无缺的设计，更多是在较短的时间内开发出产品的核心功能，并快速推出可以上线使用的版本（即最小可用产品（Minimum Viable Product,MVP）），以便及时响应市场需求和尽早完成市场验证。至于因强调早交付而出现开发设计缺陷和相关功能缺失的问题，开发者可以在后续开发过程中结合持续反馈，通过快速迭代进一步完善和优化软件产品。
相较于传统瀑布式开发，敏捷开发不会囿于线性执行而陷于某个阶段的任务。敏捷开发主张尽早交付最小可用产品和以快速迭代的方式推进软件项目，如此不仅大大压缩了软件开发和发布周期，更给整个软件开发过程带来灵活性，进而可以满足随时变化的业务需求，及时处理发现的问题，将风险最小化。
敏捷开发虽然实现了开发侧的敏捷，为软件开发带来了灵活性和速度，促进了软件产品的快速交付，但是对于用户来说，其业务价值的变现依赖于运营侧的部署和稳定运营。作为敏捷开发的一种新模式，DevOps重构了软件开发和运营团队间的协作和软件交付方式，通过“研运一体化融合流程”和“自动化软件交付”，从根本上促成了业务价值的快速实现。
DevOps实质上是融合了软件开发（Development,Dev）和运营（Operations,Ops）实践的集合。需要强调的是，DevOps摆脱了敏捷开发的局限性，将敏捷思想贯穿于包括软件开发和运营在内的整个软件生命周期。需要说明的是：不仅DevOps的要素（例如敏捷开发管理等）来自敏捷开发，而且一些重要的DevOps实践动机也源于敏捷开发。
DevOps的实践往往受到了精益等经典思想的影响。因此，DevOps的目标并不只是实现运营阶段的敏捷，更要实现与开发阶段的融合和有效管理，尤其是通过运营阶段不断的问题反馈，形成“反馈—改进”循环，实现整个软件开发体系的持续改进和主动进化。
要实现上述目标，就要求DevOps在实践中能够提供一条跨职能的工作流，通过敏捷管理和持续集成、持续交付、持续部署不断应对需求变化来驱动软件的开发和上线运行。这种不断拥抱变化、持续改进的思想，无疑将会使软件开发与上线运行过程更加高效和敏捷。而在实践中，一般通过DevOps模型来描述上述跨职能工作流，以揭示DevOps驱动软件开发—运营的全过程。如图3-3所示，整个过程是从计划（需求分析和设计）、编码开始，然后持续集成（构建）、测试，再到软件发布和部署，并延伸到运营和监控，呈现“莫比乌斯环”形态，周而复始。
图3-3 DevOps模型示意图
相较于传统瀑布式开发和敏捷开发，DevOps真正意义上实现了可扩展软件的加速交付、部署、运营、及时反馈和持续优化，进而实现软件产品的进化。不同于前面两种软件开发模式以及其他软件运营管理方法，DevOps不仅改变了软件开发过程，提高了软件开发和运营效率，更深入组织内部，重塑组织，包括：促进了开发、运营部门的协作，实现了更好和更快地交付、部署产品及产品升级；提高了沟通效率，革除旧式工作方式，实现快速响应；提高了自动化水平，减少了人为失误和降低了人工成本；提供了良好的扩展性，支持弹性部署以解决资源受限和业务冲突等问题。