×

微信扫一扫,快捷登录!

标签: 暂无标签
本帖最后由 FYIRH 于 2022-5-26 16:25 编辑

一、我们要解决什么问题

伟大领袖毛主席教导我们:“没有调查就没有发言权。”其实做 DevOps 也是一样,如果不了解具体企业、具体团队、具体项目的 DevOps 情况,就开始指指点点搞规划,那是没有什么好效果的,因为没有抓住它的痛点。


不论你是工具团队负责人,还是过程改进团队负责人,或者是 DevOps 教练,不论你想从工具角度做改进,或者从流程角度做改进,当你帮助一个团队做改进时,你总得先摸清楚当前 DevOps 的落地情况是怎样的。


所以我们就来看一下摸底工作到底怎么做?这个摸底的方法也是我们这些咨询师,这几年在为几十个项目做DevOps咨询的时候逐步探索出来的。


在开始之前,我们还是先说明一下我们这里说的 DevOps 是指啥。近几年 DevOps 是一个很火的词汇,搞得好像什么都是 DevOps 了,而今天重点讨论的是 Dev 之后,Ops 之前的部分,就是从你写完一行代码到把它发布上线这期间要考虑的部分。


那这部分里面发生了什么事情呢?


第一,生成转换。我们会看到程序的形态从源代码形态通过构建生成了安装包形态,再进一步被部署到线上运行起来,变成运行中的程序。程序的形态发生转换,从源代码最终生成转换为运行中的程序。

第二,配套支持。程序要想运行起来,需要相应的运行环境(测试环境、生产环境)支持,数据库表结构变更需要管理,不同环境有不同的配置,所有这些都是需要提供支持的。因为要想程序运行起来,需要一系列配套的东西在一起。

第三,累积汇聚。发布上线的时候,其实并不是只上线一行源代码改动,而是上线了一系列改动,这些改动是在软件交付过程中不断汇聚、累积起来的。如果你一个人写源代码就是不断累积,但一次发布的东西可能不止是一个人的改动,不同人写不同的用户故事,这实际是大家工作汇聚的过程。

第四,质量提升。最重要的是,这个过程当中会不断提升软件质量,直到达到可以发布的程度。这包括了静态测试和动态测试。

从这个过程来看,DevOps 包括了这四类活动,来实现从改动一行源代码到最后发布上线的事情。我们今天说的DevOps,就是这期间发生的事情。我们也可以把这个过程称作软件交付过程。



下面我们看一下我们这里讲的 DevOps 或者说软件交付,在软件开发全过程中的位置。


软件开发包括了哪些内容?总体上,大致划分为定义侧、实现侧,一起构成了软件开发。定义侧就是关于确定该研发什么,该把这个产品做成什么样子,产品的定义和业务定义是什么样的。产品经理,CEO 等都在这一侧,他们要定义产品是什么东西。


而咱们在座所有人都是在实现侧,把定义的东西实现出来。实现侧大体上包括了设计编码、交付、运维三个部分。设计编码是 Dev、运维是 Ops,这两者中间是交付过程,也就是我们这里说的 DevOps,某种意义上,它可以说是既属于 Dev,又属于 Ops,是两者的交集。


好,我们搞清楚了概念,下面就开始介绍如何做调研。


二、了解项目和团队总体情况

做调研,总得先了解一下总体情况吧。先看一下业务和系统的主要特征。


  • 业务:这里说的业务是指,产品是做什么的。进而要了解产品是企业内部用户使用,还是企业外部用户使用,等等。
  • 形态:这里指软件的形态。比如淘宝,它首先有服务端,成千上万台服务器。然后是客户端,手机淘宝。你要仔细分析服务端和客户端长什么样子。服务端可能全球只部署一套,所有人都访问这里。也有可能服务端是部署在各个企业内部,即私有云。服务端的不一样的情况会影响到 DevOps 的流程,如企业内部部署需要同时维护提供给不同企业的多个版本。客户端指的是用浏览器访问还是通过移动端 App 访问,还可能是嵌入式设备。只有分别考察客户端和服务端,才知道这个软件是什么形态,这个形态会决定后面调研什么。比如说客户端是浏览器,那考察的时候既要看服务端的后端模块也要看前端模块。而如果服务端是一个后端系统,供别的系统通过 API 和它打交道,这时候再看整个 DevOps 方案的时候就不关心前端的事情了,也不关心自动化UI测试,只需要关注自动化接口测试。
  • 规模:规模决定了软件开发的难度,也会影响到软件的交付过程。
    • 软件规模是指有多少行源代码。研发团队规模是指由多少人在上面工作。因为人越多,协作越困难,需要分更多层级,越需要流程。
    • 还要看用户规模、部署规模。访问量大了,负载就高了,就需要部署更多的机器和节点。访问量大了,对质量的要求也有所提高。
    • 耦合性。耦合性是指如果系统是由一个个松散的单元组成,比如微服务,当你说规模的时候,基本上只需要关注一个微服务的规模就可以了,因为是相对独立的。而如果是一个强耦合的大系统,比如比较古老的一个大型单体应用,这时候不能只看某一个模块的规模了,在看规模的时候就得看系统整体的规模。
  • 质量:一方面是质量要求高不高,另一方面看质量是不是好实现,如果算法特别复杂,逻辑特别复杂,可能就不好实现,如果只是一个简单的转接,就比较容易实现高质量。



然后我们要大致了解一下管理实践。


首先一个问题是,这个产品管需求条目叫什么?就叫需求,还是用户故事,还是特性,甚至可能是项目。我们要用跟用户一样的语言,所以先要了解用户怎么说。另外需求是分层级的,我们关键是要抓住哪个层级呢?抓住可以独立测试、独立发布的需求,这个层级。因为将来它很可能会映射成一条 Feature 分支。将来统计测试的内容、发布的内容的时候,也说的是有哪些这样的条目。


接下来是关于开发的组织方式。典型的,Scrum 这样的迭代方式,或者精益看板墙来管理的精益方式。后者比前者要更好些。


最后落实到要看当前的发布频率。比如可能是每个迭代末发布。当然也有多个迭代才发布一次或者一个迭代发布多次的情况。



接下来我们顺着生成转换过程了解下,从源代码,然后构建,再到部署运行起来。这些事情一方面是了解情况,比如用没用容器啊,用没用容器编排啊。另一方面和项目团队建立一些共同语言,将来沟通的时候,你说的别人听得懂。

为什么你说的别人听得懂?因为你是用别人的语言来说。比如说,开发环境,在不同的团队里,它的含义就不一样。有时候指的是个人开发环境,还有的时候指的是开发人员共用的一个服务器端的测试联调环境。



最后看一下分支策略。如果想了解流程,那么先看分支策略,因为分支策略是承载了它的流程的。你能看到代码在哪儿 Checkout,在哪儿提交的,在这条分支上怎么被管理的,流程再往下走,提交到新的分支又怎么去管理,你顺着分支就捋下来了,就是一个完整的 DevOps 过程。


1000个项目有1000种分支策略。那你怎么去着手了解呢?有一个小的窍门,就是从这四个角度去了解:

  • 总的分支模式:是基于 GitFlow 模式,还是基于 AoneFlow 模式?跟这样的典型分支模式的差别在哪儿?如果这个事情一上来就弄清楚了,那可就省事儿了。
  • 代表线上最新版本分支:现在常用 master 分支来做这件事,它上面的版本代表了当前最新发布到生产环境的版本。
  • 集成/发布分支:典型的,GitFlow 里的 develop 分支。而 AoneFlow 里就没有一条长期存在的 develop 分支,而是一条一条的 release 分支。过去常提的主线开发模式,主线指的就是集成/发布分支。还有 Hotfix 用的分支,它的本质也是一条发布分支。
  • 特性分支:特性分支不一定需要。如果有的话,就看它叫什么名字,从哪里拉出来的,合并到哪里,合并之前要满足哪些质量上的要求等等。

三、沿价值流进行梳理


解完总体情况,下面我们来梳理价值流。这是精益里面的一个方法,沿着软件交付的流程进行梳理,从写下一行代码开始,是怎么一步一步最后发布上线的。通过梳理找到要改进的地方。



既然是沿价值流进行梳理,那我们就解释一下软件交付过程的6个阶段。


  • 代码改动累积。代码改动累积就是在本地开发环境里没有做 git push 之前的事,随着不断地开发、不断地写代码,你要不断进行测试。这包括了静态代码扫描,也包括了本地的人工自测试、单元测试等等。关于自测试,还要详细考察,它是端到端的,还是只测一个微服务,其他都 mock 了。后者其实还是挺不够的,因为还有很多问题没有测到。理想情况下,尽管微服务是在个人开发环境里跑起来的,但是可以连通到整体测试环境和整体系统,于是可以做端到端的测试,这时候会发现更多的问题,将来遗漏给测试人员让他遇到的麻烦更少。代码改动累积阶段应该被重视。
  • 代码改动提交。看看在 Push 之前有没有进一步的质量确认步骤。另外还要考察,多久提交一次。以前常说每天都提交,这可不是说,每天下班前必须要提交一次,是大概频率就好。
  • 特性改动累积。如果你使用了特性分支,那就有这个阶段。为每一个用户故事、每一个需求拉出特性分支,在这个分支上面,为这个特性不断开发和 git push。在特性分支上,改动不断累积。并且可能每次 Push 都触发了流水线,做构建、单元测试、代码扫描。
  • 特性改动提交。特性改动完成了,把特性分支合并到集成分支。这经常是一个 Merge Request 或者 Pull Request。
  • 集成。它是指在集成分支上,不断收到新的特性或者新的代码改动,不断累积,在累积过程当中不断给你质量上的反馈,比如说提交触发流水线。进而做持续测试,不要等着所有功能开发后再测试,即使人工测试也不要这么等。每当有一两个 Feature 做完了,合并到集成分支上了,测试人员又有空闲,那就去做测试。
  • 发布。这个阶段指什么呢?是指当所有的打算发布的功能都做完了,都提交到集成分支了,于是开始这个阶段。这个时候进行进一步的测试,如果测试特别顺利,全都通过了,那我就发布了。不像集成的时候,即便测试通过了也不会发布,因为还没攒够一拨呢。所以发布阶段就是最后一哆嗦。这里最重要的策略就是把发布阶段里干的事情尽量往前挪,挪到集成阶段,甚至再往前挪。我们要尽量避免在发布阶段做很多事情,这样我们才能比较频繁地发布。


所以看起来就是,首先是代码改动的不断累积不断测试,然后 piu,提交上去。接下来是特性分支上改动不断累积不断测试,然后 piu,合并到集成分支。最后是集成分支上代码不断累积不断测试,最后 piu,发布出去。你用这个框架去调研项目实际的交付流程,会让你思路特别的清晰。


四、了解各个具体活动

我们沿价值流进行了梳理,了解了在流程上,何时发生了什么,各个具体的活动是在什么时候发生的。但是对具体的活动本身,还需要更深入细致的了解。一个活动一个活动地细致深入地了解。


我们把所有的活动分一下类,然后看一下每个分类里面有哪些活动。



左边是非测试的活动。上面是源代码版本控制、构建、构建环境管理、制品管理等,总之是从源代码到构建,再把构建生成的制品储存起来。


下面是部署运行方面的事情,也就是怎么让制品变成运行中的程序,并为它提供环境上的支持。


右边是测试相关的活动。上面是静态测试,也就是靠分析源代码就进行的测试。包括人工的评审,也包括自动的代码扫描和制品分析。


下面是动态测试,也就是让程序跑起来进行的测试。从最简单的单元测试开始,一直到在生产环境下做的测试,比如全链路压测什么的。(转自董越)



本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:DevOps赋能软件定义汽车
下一篇:终于明白了 DevOps 与 SRE 的区别!
姗姗来迟

写了 312 篇文章,拥有财富 1672,被 4 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

返回顶部