深谈DevOps


前言

说到一个概念,要想理解它,最好的方式的弄清楚它的本质。

举个例子:

从本质上讲,汽车和马车并没有什么不同,它们都是载人和载货的工具;再抽象一些,它们提升了人类的能力和活动范围,从本质上讲是人力的延伸

人类所有的活动都是为了满足人类自身的某类需求,小到衣食住行,柴米油盐,大到原子探微,宇宙翱翔。

稍微回归我们的主题,软件活动也不例外:软件活动是为了满足人类某类需求而进行的活动。

随着软件活动要解决的问题越来越复杂,需要参与的人就越来越多,软件活动也变得越来越难以调和,但是不管怎么复杂,业界认可的软件活动无非包括需求活动,开发活动,测试活动和发布后的维护活动等几个活动。

对于软件活动的模型,个人觉得最好的模型是价值流模型,把软件活动做一个映射,那么有:

软件活动的目的是:

满足人类的某类需求 -> 交付价值

软件活动包含的基本活动是:

需求活动,开发活动,测试活动,维护活动等 -> 价值流(的4D)


用软件专业术语总结一下就是:软件活动的目的是交付价值,软件活动的过程是价值流动的过程。

价值流的4D模型

4D模型是4个D字打头的英文的组合,分别是:Discover,Define,Develop,Deploy。

翻译成中文就是:价值的发现,价值的定义,价值的开发,价值的发布。

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1uploading.4e448015.gif转存失败重新上传取消

(这个模型也有外文资料描述成5D,即在Develop之前还有一个Design,个人认为:架构设计,开发和测试均属于开发的一部分,不需要剥离出来。)

我们再把这个模型做一个更具象的表示(请关注加粗的名词):

  • 价值的发现:以客户为中心,进行需求的收集。

  • 价值的定义:挖掘真实的需求,定义产品

  • 价值的开发:在项目层面,进行软件设计(架构,开发,测试,UX,etc)

  • 价值的发布:发布产品,并形成反馈和闭环

Q:为什么要花那么多篇幅和时间来描述4D模型?
A:4D模型是对软件活动的高度概括,是抽象的逻辑。无论是过去流行的理念或方法论,如:瀑布,CMMI等,还是现在流行的理念和方法论,例如:敏捷,CI,CD,DevOps等,都不会超脱这个模型。

DevOps

DevOps有很多定义,不同的组织具体落地时也会各有倾向,个人认为,通过如下标签可以很清楚的描述DevOps:

  • DevOps是推动价值流快速流动和健康流动的方法论,是在端到端价值传递的基础上创造价值的方法论

  • DevOps包含一套最佳实践,它同样体现了团队协作,沟通和信任的哲学和文化。

  • DevOps的目标是快速高质量交付,并持续改进。

DevOps的底层支持

当我们提到DevOps的时候,往往说的是DevOps工具链。

DevOps的底层支撑是一整套完整的工具链,例如:

  • 产品 - 需求管理和规划:TFS,JIRA,WIKI等等

  • 产品 - 拆分到项目的开发过程:

    • 代码管理和评审:Gerrit/Git,Phabricator等等

    • 代码质量检查:KlocWork,Fortify,Converity, BlackDuck, Sonar等等

    • 持续集成:Jenkins/Pipeline, Docker等等

    • 自动化测试:RobotFramework, Postman, WebInspect, Nessus等等

  • 产品 - 的发布和维护:Artifactory, Docker, Jenkins等等

常规的理解,基于这一整套工具链,形成适合产品和组织的流程乃至文化,并固化成价值观。

DevOps的进阶

做过产品的同学都知道,要想把项目做好,从来都不是仅仅有工具就足够,最根本的是要解决人的问题;所谓人的问题,并不仅仅指人的能力的问题,更重要的是人之间沟通和信任的问题。

DevOps的工具链跨越了多个领域,不同领域之间除了所从事的工作不一样之外,很容易因为认知问题和管理问题形成壁垒,也就是“墙”文化,DevOps还需要解决“墙”的问题。

DevOps的另一大法宝是把管理工作技术化,打破不同领域之间的“墙”文化。

Q:需求失真,不透明,太抽象,需求管理混乱,怎么办?
A:需求共建,需求唯一入口,需求团队决策,需求可视化。
Q:代码质量差,怎么办?
A:代码检查CI化:代码不符合(例如不符合规范,覆盖率不达标,复杂度超标等)要求直接被CI拒绝;代码评审策略化(守护评审,多人复审才能合入,等等)
Q:测试反复,测试人力不够,怎么办?
A:自动化测试,RobotFramework,Postman走起。
Q:发布版本多,发布环境不一致,没法管理,怎么办?
A:明晰的代码管理策略,分支管理策略和环境管理策略,并使之自动化。
Q:端到端的节点,数据那么多,看不过来,怎么办?
A:可视化一切流程。

DevOps误区

误区一:DevOps就是工具链

工具链只是DevOps的外在承载,其背后需要强大的管理支撑和技术支撑。

  • 管理支撑达不到或者管理者意识不够强,DevOps就会沦为开发工具和测试工具,DevOps的效果最多在团队级,达不到项目级,更谈不上组织级。

  • 技术支撑达不到(例如:技术能力有限),DevOps走起来会很慢,出现瓶颈,但技术能力只是时间问题,如果时间允许,终归是可以解决的。

  • 管理支撑和技术支撑还需要协同才能保证最优效果:发版需要强大明晰清楚的版本管理(管理)和分支策略(技术),快速上线需要清晰明确的规划管理(管理)和自动化测试支持(技术),等等。

误区二:DevOps不适合小型团队

DevOps是产品级的实践,跟团队大小无关。分两个方面来说:

  1. 只要产品和产品管理完整,小团队可以使用轻量级的工具链来支撑,用不了云级的支撑,单机版服务器也可以啊。

  2. 如果条件不允许的话,也可以在局部领域(比如开发效率高,测试效率高)做到极致,从而推动产品进步。

后记

其实说到底,做产品、搞事情无非是要解决Why,What和How的问题,DevOps不仅仅支撑了Why,What和How,而且通过一整套自动化的工具链,加速了其进程,从而达到快速高质量交付,并持续改进的目标。

PS:DevOps和Agile

如果说Agile是心法的话,那么DevOps则是剑法。
  • Agile描述了一套价值观,却没有显式的把方法论体系化。

  • DevOps定义了一套方法论,却把价值观蕴含在其实践中。

(↓ - 有些内容只在小龙家发,可关注同名“趣Python”号,谢谢 - ↓) 

发布了28 篇原创文章 · 获赞 0 · 访问量 728
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 深蓝海洋 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览