00:00
大家好,那欢迎来到G交付与DES体系这一章节。那我们先来看一下传统的瀑布式的一个开发流程,那在呃PC端软件盛行的时代,那通常采用的一个架构是这样子,比如说微软很早的时代,那么它就会采用这个这样的一个工作流程,首先有前面我们完成商业需求的分析,然后产品的需求整理,然后产品的一个架构设计,最后呢,到了研发的编码阶段,编码完成之后呢,然后再交给后面的测试,完成对质量检测,最后我们把呃整个产品交付给我们的一个最终用户。这是传统的一个瀑布式的一个流程。那这个流程的问题啊,主要在于部门与部门之间,那是有个很高的一个部门强的,那我只关注本部门的产出,上个部门我只等待他的一个输出,我在开展我的工作,我不会提前把做一些呃这种相关的一些工作了,那每个部门之间到下个阶段都有一个明显的一个交付物,可能是文档,也可能是一些代码,也可能是一些我们打包之后的工具。
01:06
那这个流程呢,就导致说部门之间缺少这种。比较完善的一套流水线,那就导致你的效率就很难得到一个提高,那随着后来敏捷的盛行,那么这个瀑布的方式就逐渐的啊被取代了。那被什么样的方式来取代呢?首先是敏捷开发的体系。然后。在敏捷流行之后啊,在敏捷流行之后,然后慢慢的就是我们的软件研发就进入了一个新的一个时代啊,我们也通常称之为叫敏捷开发的一个时代,或者敏捷开发的一个体系,那这个体系呢,非常的庞大,里面有很多的一些技术理念。那么我们举几个比较流行的,比如说一打通,为了打通开发与测试之间的部门墙,那么它有一个叫做持续集成的一个对吧,开一个方法论,然后是什么呢?然后是打通产品开发跟测试之间啊,让这三个角色能够很顺畅的进行沟通的,能够快速的迭代了,那么它的是叫做敏捷体系,里面有scra,对吧?然后是为了打通开发测试和运维之间的这个部门墙,那么又诞生了de UPS,然后把整个流程完全连接起来的,那么就变成了一个持续交付,所以近可以看到啊,基本上是为了提高我打消各个部门的,呃,各个部门之间的部门墙,然后提高我们的交付的效率。
02:27
那我们有非常多的一些方法,那来去解决啊,每个部门所遇到的这些问题,最后的结果是什么呢?我们可以让用户的啊,更早的享受到这个价值,让我们的整个产品迭代能够越快,让市场能够尽早的去接受,对吧,我们的一些一些一些变更。那么这里面就要求一些敏捷的一些基本的一些理念来实现说我们能够快速的往前去走好。那么每一个手段里面到底是怎么去做的呢?那我们来看一下,这样呢,我们比较流行的几个持续继承,持续交付,持续部署,以及代VE bos,我们今天呢,聚焦于这四个最主要的一个事件。
03:09
先看持续继承,持续继承呢,在亚马逊对它的定义是这样说的,持续继承呢是一种在develops软件的开发实践,那么采用持续集承的时候呢,开发人员会定期的将代码变更合并到一个呃,中文的代码仓库里面,系统呢会自动去运行和构建对应的一个测试操作。那持续集成呢,通常是指软件发布流程中的构建和集成的一个阶段,那么带有一部分的测试,它要求呢,会用到一些自动化的组建文化的组件,包括一定的测试手段。持续集成的主要目的呢,是为了更快的发现和解决问题,主要其实就是为了更早的集成吧,从而发现这种集成阶段,那么所遇到的一些相关问题。其实它也是提高效率的一个方式,那么它的主要方式呢,基本上就是通过这个流程研发呢,写完代码提交到get仓库,然后接着呢,我们的像一些持续集成软件,比如像get lab啊,像一些S嗯,他会呃去拉取代码,然后进行相关的一些构建代码的构建代码的测试,然后出对应的结果,然后反馈给研发人员。
04:09
好,这是它的一个整个的一个流程,其实持续继承呢,它的概念比develops要更早,它是最早是属于极限编程的一个核心理念,叫做持续继承。好,这个理念因为它很顺,顺应了行业里面流水线的这个体系发展,所以它自然就成为一个现在无论是去集成、持续部署,还是带包子,都成了他们很重要的一个组成部分。好,因为他现在呃,Divve UPS比较火,所以说大家通常会把它认为是divves的一个核心时间,其实它比UPS的理念啊要更更早了。好,我们来看一个啊,比较常规的啊一个流程,那这是get lab的一个C流程,我们可以借鉴一下,比如首先,然后假设你这是呃,部署的一个线上部署的一个代码,那这个时候呢,我们拉几个分支来进行对应的一个产品的一个开发,这个过程中呢,研发会不断的往里面去push一些新的代码提交。
05:04
这个代码提交呢,提交完成之后,这阶绍呢,就会把研发的代码拉取下来,然后进行相关的一些自动化的构建,自动化的单元测试,覆盖率的分析,审代码的审计,包括静态测试,OK,一旦发现了bug怎么办呢?那提醒研发进行修改,研发阶段再去提交代码,那么又提交了若干次commit,提交完成之后呢,OK,再完成一轮的测试。那这一轮测试完成。那么没有问题,那么就会进入下一个阶段,好在这个环节里面你可以看到把研发的代码持续的进行什么呢?呃,集成对吧,构建,然后测试的这个过程,我们称之为叫做持续集成的一个阶段。当常见的持这种手段,那有非常多啊。我们会把哪些手段纳入进来呢?一些单元测试,静态测试,然后带覆盖率呃,呃覆盖率统计,代码审计,还包括说一定的这种呃用于呃这种像功能的啊,一些冒烟的测试,我们也会把它呃集成过来,那举个例子,比如说一个APP的测试,APP呢研发提交换代码,它可以自动构建出来一个APP的基本的把这个界面的,那这个界面里面我想进行测试,那么我可以把一定的猫烟case移入过来,或者说我把一些类似于介容性测试啊,稳定性测试,包括说一些智能编辑测试融入过来,所以它里面呢,可能也会有一定的UI测试,或者一定的接口测试,只不过这个呢,相对来说它比较少,更多的还是呃最基本的代码的构建代码的。
06:40
呃,单位测试,呃,静态测试,代码审计啊,主要是这些环节。好,那么因为前面的测试手段呢,它其实只是把开发开,尤其是开发部门,开发多个部门之间的协作,变得更能够更早的继承,能够发现有问题,包括说跟开,跟测试同学有一定的配合,完成一些基本的一些测试工作的一个建设,好在这个阶段里面更多是偏向于测试左移的一个一个相关的一个时间,那大部分测试本身所做的手工测试啊,那么UI的级别的测试,接口级别的测试,包括端到端的测试,其实这个时候并没有体现在刚才的这个,呃,区域集成里面。
07:19
那为了更高更高的去提高效率,更好的保证出来,那么就诞生了一个持续交付的一个概念,那么持续交付是什么呢?亚马逊对它定义是这样说的,持续交付呢,是一个软件开发的时间,通过持续交付系统呢,可以做到什么效果呢?可以为可以加代码呃,更改发布到你的室内环境做好准备,呃,现代软件,它是现代软件呃,应用开发的一个支柱,那持续交付呢,通过在构建阶段啊,将所有的代码变更啊,部署到测试环境和市场环境,注意到这个区别。前面呢,只是简单的集成,把编译测试,包括呃一些,呃,可能有一些简单的打包,但是呢,他并没有真正的把整个系统部署到我们的特定环境里面,比如说我把前端后端所有代码部署到一个可工作的环境里面去,可能是开发环境,测试环境或者联系环境。
08:10
前面的继承更多是代码,一直到打包这个阶段就截止了,他没有真正的把所有的体系部署到一个具体的可工作的环境里面,好区域交付呢,把这个概念做了一个扩展,他对持续继承呢做了一个扩展,那么在实施的过程中,开发人员可以持始终啊拥有对吧,什么呢,以通过标准化测试流程的部署就绪的,呃,这种啊,对吧,这种构构建的一个构建,那么采用什么呢?采呃,采用持交付的时候,开发人员可以什么呢?自动的去执行单元测试之外的这些测试,前面我们提到了。它只有集少量的大量的单元测试,呃,进来测试代码审计,以及少量的一些UI和接口的这种测试啊,能够提前能够转移过去的。那么大量的端等端的测试其实是没有被纳入进去的,那这个时候呢,开发人员,那么他就可以呃,在持续交付的环境里面完成前面说的在安元测试这个手段之外的大量的测试,那主要是这个等到端的测试,这样呢,他们就可以在部署到客户环境的对吧,环境环境前能够跨多个维度对你的应用进行相关的一些验证,常见的就是UI的负载的集成的些相关测试,API的可靠性的测试吧,这方面可以有助于啊我们整个团队更早的发现其中的一些问题,那如果说跟前面图的区别。
09:28
在这个环节里面就持续集成,从代码的构建,测试,基本的一个报告OK到开发,这是第一个小的阶段,这是一个持续集成了。如果要到持续交付。那么你要能够做到说把我的代码能够持续的部署到一个可工作的呃这个环境里面,比如说我的联调环境啊,测试环境啊与发布环境,那当然线上自动化的发布,OK,它是不包含权力的。好,这个体系啊,相当于扩展了对环境的一个自动化的一个交,一个一个交付,所以呢,这个也是持续交付的一个阶段。
10:02
好,那么持续集成与持续交付,那明显的就是吧,如果是说明显的区别啊,我们来看这张图,持续集成呢,涵盖的是从代码的构建啊,等你提交代码开始。我们通过持续集成平台来去构建它,然后对它进行一些基础的测试,其中呢,我们我们测试工作就被拆成两部分吧,能够迁移的我们就尽量迁移过去啊,其中呢,有一部分测试啊,是研发来写的,比如像单元测试,然后还有一些测试能够协助的,那嗯,一些代码的审计呀,那一些静态测试工具,像findx之类的,我们就可以提前这个阶段,甚至包括说一定的冒烟的测试,呃,UI的和接口的一部分的测试啊,小部分的测试你可以迁移过来。这个我们称之为一个持续的继承。在这个过程中啊,只是把包打出来了,打出来的把包啊打出来APK,打出来各种工具,但他们并没有把前端后端所有代码部署到一个可工作的环境里面,也就是这个时候呢,大家只能看到一个包,还不能对它进行完整的一个对端等端的一个测试。
11:03
好,那持续交付呢,就扩展这个测试能力,OK,那么我把整个环境也可以轻松的部署到多个体系里面来,是吧?那连带多个环境,通常就是来电环境啊,测试环境啊与发布环境,这三个环境都可以自动化的很顺畅的部署过去。这个时候你所有的UI测试结果测试的各种各样单测试都是可以做的。好,那么在这个层面上,基本上就到了持续交付的这个阶段,持续交付呢,关注的是吧,我们的刚才说的啊,集成级别的测试,系统级别的测试啊,等等等的测试,一直到最后部署到各个环境。他关注的是这个环节,但是持续交付呢,它实际上整体也包含了前面的部分,整个的其实我们都称之为是一个持续交付,只不过是这个持续交付呢,重底薪是在后面,前面呢其实也是包含在内的。好,那么通常大部分公司的一个是交互流水线呢,差不多就是一个比较复杂的,复杂的一个一个一个结构里面呢,从代码构建开始都需的对吧,各种各样的代码的checkout,然后代码的构建,代码基本的一个测试。
12:04
那然后是呃,部署部署环境之后,相关的一些集成级别的一些测试,然后包括说到各种各样的测试,最后呢,测试完成,OK,我们完成一个部署,其实这个部署呢,还有多个环境,所以这中间呢,会有一个多个阶段。好,那么如果说你使用小S的lo,那么你就可以发现吧,类似于这样的一套流程,那么当你使用loion的时候,那么从你的构建开始,对吧?首先最基本的单元级别的测试,OK,会有一个测试机器,但是测试集成完,测试完成之后你要打包,打包能构建出来一个环境,所以这里面呢,还会有对应的各种各样的一些。呃,集成级别的测试,系统级别的测试,包括端端测试,其中每一个环境里面,你在D的环境里面,你要完成一系列的验证,OKD环境验证OK了,接着再到stage环境也要完全对应一套测试体系,那一直到我们上线处于一种可发布的ready状态,但是还没有做到自动化的一个发布,那如果说对吧,我们想把流程再扩展一下,那那我们想让它自动化的部署。
13:06
那其实就到了下一个阶段,就是持续的一个部署了。好,我们来看一下get lab get lab是如何去做它的持续交付流程的,这有个图,大家也可以看一下,假设啊,你有一个代码,比如说你的产品代码。那从我们开始提交开始啊,你可以看到从你基本的提交从这里开始,一旦我们提交到到第一个阶段。那从你线上的个版本开始,那我们拉出来一个分支进行代码的一个提交,提交完成之后,OK完全持续集成的一轮测试,发现bug,提交bug FA继续进行集成,OK集成过程中包含了哪些工作呢?对吧?代码的质量检测对吧,性能可能会有啊,就是一些BACHMARK1性能测试,单测试,呃一些容器的扫描,也组建依赖的,这个依赖库的一些扫描,就各种样的静态测试,代码审计,基本的一些这种一些测试的。好,这个性能测试呢,主要是代码的,基本的就是代码单元级别的一些benchmark的意思是。
14:05
好,这个测试完成了,接下来会进入一个打包的过程,这我会打出来各种各样的包,那有你的ma吧,比如说像挖包啊,架包,包括说APM的各种包啊,可能还有二进制的包,对吧?那除了这些之外呢,还有一些容器化的部署,如果整个功能确认是OK的,那我是比如说它是挂包,我直接顺手就打出来一个容器的一个镜像,打出一个镜像来,我后面呢,这个持续部署,呃,持续交,持续交付,然后来把提供这个有效的一个构建在这里面,主要是产出比较良好的各种各样的一些构建产品。好,一旦这个完成,那我们再看持续的一个持续交付,好当这些东西都有了,那么OK,那我就开始在各个环节里面进行部署,在部署的过程中呢,里面就有啊很多的对吧,各种各样的一些版本叭,如说我的精呃机机版本,Bad版本,二尔法版本,包括说我的连龄测试环境就是年龄环境啊,测试环境与发布环境。
15:03
OK,在这里面你会有多重要的环境啊,在这里面完成多轮的一个测试,就是每一次发现bug,我去提交,走一整套的流程,重新再到这个地方来。就是持续的交付到我的各个环境里面去,但他并没有最后交付给我们用户,只是交付给了呃我们的整个团队,让团队呢,能够及时的在各个环境里面完成更顺畅的各种各样的一些研发测试。好,到这个时候呢,用户是看不到我们最新的一个变化的,只有我们内部团队,这个呢,对于效率上已经是很大的提升了,以前我们都要去维护啊,各种各样的一些环境,对吧,这环境我们要写自动化脚本,要去做各种各样的事情,甚至说有时候啊,有些公司做不到,还要手工部署,配数据库之类的,非常麻烦。他有了持续交付,那么里面就有很多的相关的技术,比如容器的技术,那我就可以很顺畅的在各个环节里面进行部署,效率会有很大的提高,研发者改一行代码。我就可以快速告诉他这个代码有没有问题,如果没问题,环境就自动部署好了,我们就可以介入我们的自动化测试和人工的测试,这是效率上会有一个很大的一个提升。
16:09
好,这个我们称之为是持续交付的一个阶段。好,那么前面我们说了,那对这个阶段我们还希望说能够更加的顺畅,顺畅到说既然我们内部测试过都没问题了,那可以可不可以自动化的直接发布到用户,OK,这个阶段如果你能打通,你就到了持续部署的一个阶段。那么通过持续部署啊,那微软给到定义是这样说的啊,通过持续部署呢,可以自动完成从代码提交到生产的一个全过程,开发与交付,呃,交付阶段啊,之间的一个触发器是自动的,也就是说从我的U环境到我真正的生产环境是完全自动化的。因此呢,在代码更改获得验证并且通过所有测试后,理论上你就应该立即要发布了,这就意味着什么?在改进功能啊,只要是可用后,客户便可以立马获得这些功能。他对交付效率上,那肯定是一个很大的一个提升,当然他对技术的要求也会很高的,那自动化发布之后,如果遇到问题怎么办,能不能自动化的回滚吧,那能不能实时去监控这个效果啊,能不能不影响所有的用户,出了问题也会影响所有的用户,所以这里面就会引入了非常多的各种理念,比如说像AB测试啊。
17:17
各种各样的一些灰度,灰度发布啊,你都要去解决这些问题,好,一旦到了线上,你要考虑的点就会更多。好,那么持续继承交付和持续部署这三个到底什么区别呢?那画几张图,那也可以看一下,好,这个图呢,也是亚马逊的一张图,那我们来看一下它的区别啊。如果说你要去发布一个产品,从你代码构建开始到构建的这个阶段,通常我们称持续的进行构建和测试,这个过程我们称之为是一个持续集成的阶段,所以它的工作是到这个阶段。那从这个阶段开始到下一个阶段,我持续的部署到我的各个环境里面,连接环境、测试环境与发布环境,OK,这个叫做持续的交付,它交付的对象是整个团队,并不是最终用户。
18:00
如果说我把我的交付延伸到对用户也能够自动化的交付,那么就到了持续部署阶段,那持续部署阶段你就要考虑刚才更多的,刚才我提到的吧,AB是啊,灰度发布啊,然后包括说各种各样的质量监控啊,对吧,你都要有更完善的体系,你才可以做到吧,这个更加顺畅的这个发布给呃用户。好,那么一旦发布给用户之后,用户总会提相关的意见,对吧,那接着呢,我们要进行改进,包括发布之后你的产品有没有bug,那么我们要有一定的线上的测试,那包括说线上的监控,那把这收集回来的数据重新再去指导我们的商业产品要不要进行改进,根据用户的习惯,根据用户的这个各种的一些数据。好,那这个时候有了新的需求,我们就可以再次去提交新的版本变更计划啊,我的商业应该商业模式是怎么,如何改进,我的产品如何改进,那么接下来就完成下一轮迭代,这个时候你会发现呢,是原来的瀑布式就变成了一种双环的一种模式。
19:01
在这个双环模式之下,那整个流水是非常顺,就是整个流水线是非常顺畅的,所有的东西都是一条流水线,都可以自动化的完成所有的一个工作。好在这个工作里面主流的东西啊,就已经是很顺畅的,它不一定是100%自动化,它更多的是强调的是说我的数据是吧,可控的,所有的东西是可控的,然后可迭代的,然后那个所有的数据呢,也非常齐全,我是可观测的,好达到这个程度,OK,就等在UPS这个阶段。在斯呢,他有更多的一些理念,比如说去继承,去交互,这都是基本对吧,它的一个基本能力。然后是也要用到为服务你的技术架构,那也要能够以对吧,很好的能够进行维护和管理起来啊,上线之后的监控和日志,对吧,以及强调啊代表啊,研发测试和运维之间的一个协作。好,那么代develops需要哪些技术站呢?那我们每个阶段里面,它涵盖的阶段比较多,那几乎是完整阶段都涵盖到了,所以它的技术站也比较广,比如说从我们啊最熟悉的,那从代码阶段开始,从产品经理交付给我了,交付过了,我要级编码的过程中,要求代码的版本化管理,对应的文档,对应的一个项目管理追踪。
20:18
构建阶段,你要掌握各种样的构建工具,像me,像gridle对吧,像过像一些各种各样的构语言的编呃构建工具。然后是。测试阶段,那我们有单位测试,集成测试和系统级的测试,包括端端端的测试,那么这些测试能力,你要掌握各种各样的一些测试框架和测试能力的一些,这种测试能力好,一旦这些东西测试通过之后,我们就要能够持续的啊,就首先能够发布,通过发布各种包,二进制包,对吧,包括说镜像。发布完成之后,我们要完成部署,部署呢我们要动用一些容器相关的技术来完成对它的很适当的部署,包括说一些自动化的一些脚本,然后再往后是什么呢?是我能够在我的线上能够去运用它,部署完成之后,我对我的集群可以进行相关的运维和对那个管理吧,包括说我的一些稳定性提升,那在这方面,那你可能要用到一些开呃,K8SOK,再往再往下呢,是监控发布之后线上用用户开始使用了。
21:15
那这个时候呢,那我们要去收集用户的数据,比如说他的访问的性能数据,崩溃的数据,包括的各种相关的一些用户日志,用来给我们下一个阶段产品经理去做一些决策,从而更好的改进产品,所以这里面的技术站那就相对来说就比较广。这儿呢,只是举到了一些典型的,也就这样。OK,那么从从我们整个研发体系进入Dave UPS这个时间以后,那么就诞生了双环模型,那么在这个双环模型里面,它对我们测试的挑战就带来了一个,就带来一个,呃,比较大的一个影响,好对测试是什么样的一个挑战呢?我们传统的测试如果是流水线呢,就是就是瀑布式的模型,瀑布式的模型里面我们只关注研发给我包就行了,我去测,测完我出对应的测试报告,来决定下一个阶段要不要到,呃,要不要到运维阶段。
22:05
OK,这个呢,是一个传统的瀑布式的,瀑布式的一个流程。好,那么到了deve里面,那我们就不能只关注自己的,因为整个流,整个流程都是一套流水线,全自动化的部署,那我的测试工作我想更快的进行交付,更快的能够,对吧,能够去服务整个团队,那我的一些能力其实就要适当的做一些延伸了。就是我不只是完成我本阶段的测试工作,我还要把我的测试能力往前提,从而让整个双环能够运转的更快。那哪些能力可以往前提呢?其实在前面我们在讲去集成的时候也提到了是吧,对于那些比如说首先单元测试研发写的,但是相关的单元测试的一个数据的一个呃一个一个一个监督,然后覆盖率的一个监督,呃代码的静态测试的,在代码静态测试代码的审计,就这也对代码质量推动,也是需要我们测试进行接入的。那包括说一些自动化的测试,也冒烟测试,我们也把它自动化也往前置。
23:03
包,甚至包括一些性能测试都可以往前指OK,到这个阶段里面,我们就需要介入一些相关的工作,甚至说可以研发进行密切的合作。比如持续阶段阶段我们都有大量的工作要做,研发机写代码,我们去完成对代码的各种各样的一些测试方法,测试的一些手段,我们都把它实施过去。所以在这个阶段里面。我们所做的测试工作,大家通常都会给大家归类成一个叫做测试的一个左移。好,那然后进入我们传统的测试阶段啊,我们的各种各样的集中的测试啊,系统级的测试等等等等测试,对吧,差不多会在这个包括一些相关的一些专项的测试。好,一旦这个测试完成,我们要持续的部署了,对吧,那持续的一个发布,那这个发布里面包你要学会构建对应镜像,对吧,构建完镜像呢,你还要能够把环境里面自动化部署起来,这一块需要测试与运维的一个密切的一个协作。所以在这里面呢,就产生了一个测试的一个右移,我们要给。
24:02
运维对吧,能够有密集的配合,我们可以完成什么呢?容器的构建,容器的部署,对吧,集群的一个,呃,自动化的一个一一个运作,集群的自动化的一个运维,包括说发布之后的数据有没有崩溃,有没有性能问题,OK,我们也需要从。发布前的环境,甚至包括发布后的线上环境,我们都要能收集这些数据去改进我们的产品,所以在这个阶段里面也有大量的工作要做,这个阶段我们都能称之为是一个叫做右翼的一个阶段。好,所以Dave UPS对我们测试,呃,挑战就是我们给我们带来了新的左移右移,那我们测试的能力呢,或者我们测试的责任其实要比以前要更强,以前是软件测试工程师,我们对软件对吧,对硬件进行相关的一些测试,现在呢,新的时代在dev develop这个时代下,他对测试工程师的要求已经进行了一个提升,也就是测试工程师呢,不能再专注于自己已有的测试阶段,那么那我们需要把能力进行外延,变成了测试,就是要融入测试左一个测试的右翼,所以新形式啊,对我们测试工程师的要求就变成了测试开发工程师。
25:10
好,OK,那么本节课就到这里结束,咱们下下节课见。
我来说两句