写在前面

迎2022国庆节，写下我的第一篇文章，一直在思考该从什么方向下手。围绕团队离不开的一个方法？一种模式？一种工具？一种思想？一种哲学？突然想到公司经常发的DevOps的学习邮件，猛然发现，DevOps于各个团队，大小公司而言，不正是个方法，一种模式，一种工具，一种思想，一种哲学。那么，就随作者来一起探索DevOps。

什么是DevOps？

提到DevOps这个词，我相信很多人一定不会陌生。DevOps是Development（开发）和Operations（运维）的组合词，用于促进开发，运维，QA（质量保证），交付等部门的沟通，合作和整合。期望是打破传统的各个部门之间的壁垒和围墙。DevOps重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例，通过自动化软件交付和架构变更的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠；实质上就是在软件交付和部署过程中提高沟通与协作的效率，目的是更快、更可靠的发布更高质量的产品。

那么DevOps出现之前产品的开发交付流程是什么呢？

1.only one

only one是我自己对这种最初代流程的理解并命名，我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。在最初程序非常简单，工作量不大，程序员们甚至一个人可以完成所有阶段的工作。

当然，随着时代的进步，软件行业的飞速发展，复杂度的提高，规模的扩大。初代的模式已经完全不能支撑产品的开发交付，需要精细分工整个团队来共同协作完成。

2.传统瀑布模型

慢慢地，团队中不只需求软件开发工程师，还需要软件测试工程师，软件运维工程师等等等等。当然，我们目前暂未考虑到产品经理，项目经理。

那么，这些工程师该如何搭配合作呢。早期的瀑布模型中，需要等需求完全明确确定，甚至不允许后期修改后，交由软件开发工程师来对实现需求进行设计方案，确定开发流程，编写代码，打包构建，等全系列完成后，再交给测试进行测试，测试直到通过后，将最终的发布版本交给运维进行发布部署给用户。瀑布模型，简而言之，就是等一个阶段所有工作完成之后，再进入下一个阶段。这种模型适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，轮流执行自己的职责即可。但是，项目不可能是单向运作的。客户对于需求也不是永恒不变的。产品也是会发生各种问题问题的并且需要改进的，最关键的问题是，我们如何面对不断的迭代开发。在各种情况下，大家发现，笨重迟缓的瀑布式开发已经不合时宜了。

3.敏捷开发

软件开发团队引入了一个非常出名的概念，就是“敏捷开发（Agile Development）”，这张图能浅显易懂的让大家初步了解什么敏捷开发的含义，

敏捷开发更大的优势是让版本的更新速度变得更快，把需求拆分成各个小需求，每开发完成一个需求或者一个功能模块，就交由测试确定该功能模块的问题，当测试通过后，再继续开发下一个小需求。

这时候，我们不怕客户突然对需求的变更，也不怕交付延期，能把风险在第一时间暴漏出来。即使出现问题，修复起来也会相对容易一些。因为我们永远保证，开发过的各个需求是没有问题的，甚至可以直接交付部署给用户的。生动的总结一下，传统模式就犹如生产一辆汽车，我们一个阶段造轮子，一个阶段造方向盘，一个阶段造发动机，不到最后建成一个能启动跑起来的汽车阶段，我们完全不知道这中间漫长的阶段过程哪里出了问题，会出现多大的问题，甚至客户突然要提前使用，需求变更时，我们只能一味的和客户沟通。这，才是最严重的问题。敏捷开发模式，保证我们生产一辆汽车时，开始阶段我们生产独轮车，下一个阶段生产自行车，再下一个阶段我们生产电动三轮车，最后生产出汽车。虽然这中间阶段生产的车很简陋，但是客户能用，客户看的见他的需求的方向。当然比喻并不恰当，只是跟随我的思路。不过本质正是敏捷开发的意义。

4.DevOps

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈。运维工程师，和开发工程师有着完全不同的思维逻辑。运维团队的座右铭，很简单，就是“稳定压倒一切”。运维的核心诉求，就是不出问题。什么情况下最容易出问题？发生改变的时候最容易出问题。所以说，运维非常排斥“改变”。于是，开发和运维的隔阂和围墙就产生了，到这个时候，我们的主角DevOps就出场了。

后文待续。。。。。。。。