【DevOps探索之旅】软件研发模式

从前有一家软件开发的公司，它一开始规模比较微小，而业务是软件开发，所以，我们不妨叫它“小开”。

和其他很多软件开发组织类似，小开的整体业务流程主要涉及到三个部门：

代表广大甲方爸爸根本利益的产品部门💁‍♂️

熬夜生产bug的开发部门🙇‍♂️

7*24小时待机的运维部门👨‍💻

产品部门兢兢业业，把用户的合理要求和无理取闹整理成一份完整详细的产品需求文档给到开发部门；开发部门励精图治，把产品部门的脑洞想法经过严格的设计、编码、测试后，转化成可执行程序给到运维部门；运维部门一丝不苟，把可执行程序给用户安装好，并开始接受用户的投诉……

这种按照顺序工作、一发不回头模式大家称为“瀑布”模式，这种模式的产生可能和当初软件工程领域借鉴实体工程的经验有关，就像盖一座楼，也是类似的步骤。

然而这种模式存在的问题也是显而易见的，软件的缺陷只有等软件基本完成后才能暴露。花了很长时间好大功夫做出来，发现致命问题又要从头去返工，或者用户想法又变了，甚至激发了内部产品部门和开发部门的矛盾。当然，这不能怪用户善变，也不能怪产品和开发的水平，只能怪世界变得太快……

为了适应变化，不能和以前一样花很长时间把所有东西都做出来再交付了。

小开决定让产品部门把需求拆分成一条一条的形式，开发部门每个月完成其中的几条需求并向用户发布一次，这样每个月都能获得用户的反馈，并根据反馈对产品进行调整。同时为了减少产品部门和开发部门的互相甩锅掐架，产品人员也参与到开发的活动中来。

这种模式就像摸着石头过河，不断地去摸石头，并根据摸到的石头随时调整前进的方向。在这条变幻莫测的河流里辗转腾挪，身手一定很敏捷吧？没错，这种快速交付快速响应的模式就是“敏捷”。

敏捷解决了很多问题，但又带来了一些问题。交付加快了，交付周期变短了，小开的开发部门要做的事情却依然有那么多：开发、代码评审、单元测试、集成、测试、配置管理……开发人员也经常吐槽，我只想静静地写个代码，却有那么多重复性事务性工作要做。

另一边的运维大哥一听也急了：想当初瀑布模式的时代多得劲儿，我一年也不用部署几次啊，现在你们整快速交付，部署次数多了好几倍呢。这还没啥，你们还整个啥微服务，把原来一个程序捣鼓成N个服务，每个服务都要配置环境，部署工作量又翻了N倍，后面还要监控这些服务可真是太膈应人了。

🌟这个时候DevOps就闪亮登场了🌟

膈应人的重复性手工劳动？

都用自动化工具来替代！

微服务的部署太麻烦？

用容器化技术！

发布的频率还不够？

持续集成和部署！

开发部门和运维部门有矛盾？

加强协作，改造文化！

……

通过以上这些将开发和运维一体化，并和敏捷的开发过程融合在一起，用一条工具链承载起一个贯穿产品部门、开发部门、运维部门的完整工作流程，就是DevOps啦~

未完待续...