我们知道在互联网企业中往往会有三大技术职位：开发工程师、测试工程师和运维工程师。这三个职位的成员分别负责着一套软件产品从零开始到最终交付的几个阶段工作。
围绕着这些工作，也发展出了对应的软件开发模式，从最早的瀑布开发，到后来的敏捷开发，再到当前的DevOps。
这些模式分别具有什么样的特点与区别，本文将用最简单易懂的文字为你讲述。
一. 瀑布开发
在软件开发的早期阶段，行业内普遍采用“瀑布模型”的方式进行工作。整个软件开发流程严格遵循需求、设计、开发、测试和部署几个阶段。在这个流程中，需要等上 一个阶段工作完成后，才会进行下个阶段的工作。例如：开发工程师会把需求的代码全部开发好，才给到测试人员进行验证，最后交给运维工程师部署上线。在这种模式下，项目开发的进程由是从一个阶段“流动”到下一个阶段，如同瀑布流水一般，因此被称为瀑布模型（Waterfall Model）。
瀑布模型是在1970年由温斯顿·罗伊斯（Winston Royce）提出，作为最早出现的软件开发模型，它在软件工程中占有重要的地位。
瀑布模型基于工程学的理念将整个过程分成不同的阶段，提供了软件开发的基本框架，便于人员间的分工协作。同时，也可以对不同阶段的质量和成本进行严格把控。但在这种模式下也存在着一些缺陷，产品迭代的频率经常是以月为单位来进行，更甚者可达半年到一年时间，这导致的风险就是需求无法得到快速验证。
随着互联网行业的快速爆发，软件开发在企业中的地位变得越加重要，软件不再仅仅是为业务提供支持，而是成为业务本身不可或缺的组成部分。与此同时，针对市场的快速变化和响应成了新的目标。
在这种场景下，有可能团队花费数月开发的东西早已经不符合市场的需要，这不仅仅是对人力资源的浪费，也会严重影响企业的发展进程。渐渐地，大家开始发现这种笨重的模式难以适应业务的需要，我们得有一种新的模式来满足需求。
于是，敏捷开发（Agile）开始登上舞台。
二. 敏捷开发
“敏捷”一词来源于2001年在美国犹他州举行的雪鸟会议，在这次会议上，Martin Fowler，Jim Highsmith等17位著名的软件开发专家提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。
敏捷宣言的主要价值观如下：
- 个体和互动高于流程和工具。
- 工作的软件高于详尽的文档。
- 客户合作高于合同谈判。
- 响应变化高于遵循计划。
敏捷意味着效率的提升，相比于传统的瀑布开发，敏捷开发实行的是一种更加快捷的做法。当收集到足够一次迭代开发的需求时，即可以向下一个步骤前进，尽量缩短在每个阶段的停留时间。敏捷的目标在于快速地将需求上线，使其呈现到用户面前，并获取到来自用户的反馈进行功能的迭代。
如何理解“敏捷开发”？简单地说，“敏捷开发”是把原有模式下的大需求拆分成多个小需求，并采用小步快跑的方式进行开发与迭代，原来的一个大环改为一个个小的闭环。在新迭代开始前，产品经理会将需求拆分成具体的开发任务，研发人员进行任务认领，每日站会进行任务的review，直到开发完成，发布新的可用版本。
敏捷开发带来的最大效益在于能够更好地贴近市场环境，产品的功能得以根据市场变化快速反应。同时，在敏捷宣言的指引下，强调充分发挥每个人的主动性和创造力，追求有价值的产品结果，这也有利于提升团队的创造力。目前，已有多种基于敏捷开发的方法论，如Scrum、XP等。
虽然敏捷开发提升了开发的效率，但它的范围仅限于开发和测试阶段，并没有覆盖到部署端。很显然，运维部门并没有在这其中得到受益，甚至可以说“敏捷”加重了运维的负担。
因为运维追求的目标是稳定，而频繁的变更往往就是出现问题的根源，这与敏捷的理念产生了冲突。于是乎，矛盾就在两个团队之间集中爆发了。
当出现问题时，往往会出现运维与开发互相指责的情况，运维认为是开发的代码问题导致，而开发则认为是运维的部署有问题。随着问题的累加，最终的结果是两个部门之间的信任缺失，甚至到了相互防范的地步。很显然，这样的结果并不是我们希望看到的。
那么，要如何才能化解这个矛盾呢？现在，该到了我们Devops上场的时间了。
三. DevOps
DevOps这个词汇，应该算是目前各大技术社区最火的概念之一了。在网络上经常可以看到关于DevOps的讨论，也有不少公司开设了DevOps相关职位，这些都证明了当前的火热程度。
但是，对于DevOps的解释，却是众说纷纭。有人说它是一种方法论，也有人说它是工具平台，甚至有人说它是一种哲学思想。说得神乎其技，让人云里雾里的。
DevOps 运动始于 2007 年左右，当时技术社区对于开发与运维之间分开工作的方式，以及由此引发的冲突感到担忧。随着越来越多问题的出现，大家逐渐认识到，为了按时交付软件产品和服务，开发和运维必须紧密合作。2009年10月，在比利时根特市举办了首届DevOpsDays大会，这届会议出乎意料的成功，并引起了人们广泛的讨论。后面为了在Twitter上更好的传播，由DevOpsDays缩写为DevOps。
DevOps的英文发音是/ de'vops/，这个词是由Development和Operations两个词的简写组合而成。在*中对于DevOps的定义是：一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例， 通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
可以说，DevOps的出现正是为了打破开发和运维人员之间的壁垒，让两者得以更加通畅的沟通，以清除部门间存在的对立。
从存在意义上来说，DevOps完善了敏捷开发存在的短板，实现了真正的闭环。在 DevOps 的模式下，开发和运维都不再是“孤立”的团队，两者会在软件的整个生命周期内相互协作，并在工作中得到紧密地配合。而由此带来的效益，则是更加高效的服务交付和质量。
话虽如此，要实现这一点却不容易，因为这并非只是一次升级，而是需要在原有的文化和流程上进行大刀阔斧的变革。
首先是推行协作的文化，两者之间不再是对立的关系，而应该是互相协作、深度交流并且彼此体谅的状态。而在流程方面，以往开发和运维各搞各的模式也需要进行改变。运维会在项目开发阶段就介入，了解开发所使用的系统架构和技术路线，并制定好相关的运维方案。而开发人员也会参与到后期的系统部署和日常发布中，并提供优化建议，而不再是把代码甩给运维了事。
在这个过程中，不止是基层人员，管理层也需要具备清晰的目标，并且有足够的思想准备及认知。因为这个过程并不轻松，在整个落地过程中往往会面临重重阻力，这种变革需要自上而下的力量进行推动，否则到最后可能不了了之。
另外，DevOps的成功实现也离不开工具的支持。这其中就包括最重要的自动化CI/CD流水线，通过自动化的方式打通软件从构建、测试到部署发布的整个流程，还有包括实时监控、事件管理、配置管理、协作平台等一系统工具的的配合。
近些年的微服务架构理念、容器技术、云计算等使得DevOps的实施变得更加容易，快速开发的产品可以立刻获得更广泛的使用。这也是为什么DevOps早在十几年前就有人提出来,但是，直到这些年才开始受到越来越多的企业重视和实践的原因。
专注于Devops、SRE、运维开发等技术分享，扫码关注公众号，获取更多精彩内容！ 