肖俊:HPE IT 的DevOps 实践分享

本篇文章来自于HPE和msup共同举办的技术开放日HPE测试技术总监肖俊的分享,由壹佰案例整理编辑。

一、DevOps含义解析

这是DevOps的趋势图。DevOps这个概念大概是在2009年被提出来的,2010年有一些公司开始试点,之后DevOps的热度持续增加,这是我们在谷歌搜索DevOps关键字得到的搜索量,这条曲线表示了DevOps热度呈指数级增长。因此我预计2016年DevOps仍然会成为一个非常受关注的技术。

什么是DevOps?

我们在试点DevOps的时候做了很多研究,也在网上做了很多搜索。比较普遍的说法是:DevOps是一种文化,用以打破开发、运维以及测试之间的工作壁垒。之所以会有壁垒是因为开发、测试、运维的工作职责、目的存在不一致性。比如开发的主要目的是赶紧实现业务级的新需求及功能,交给客户使用,然后根据反馈信息继续更新;运维的主要目的是生产必须快速、不能出问题,所以他们不是很喜欢“变化”,因为变化可能会带来风险,随之而来的就是各种问题,这是他们最不愿意看到的。

如果站在他们各自的角度来看,这些考虑都很正确,但现在的市场要求所有研发人员的最终目的都是“帮助业务部门创造商业价值”,而不只是狭隘地满足各自的目标。如何创造商业价值?充分满足客户的需求。客户的需求是多变的,而且变化的速度很快,这就要求我们必须跟上他们的步伐,快速实现最新功能并交给客户使用,如果一个系统很稳定但没有人使用,那它一样不能给我们带来任何东西。

维基百科上对DevOps的解释是:软件开发人员和IT运维技术人员之间沟通合作的文化、趋势或实践。透过自动化(软件缴付)的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。之前开发、测试、运维三者之间可能是独立的,现在要求更紧密一点。一句话总结,DevOps就是:开发测(试)(运)维融一体,敏捷高效自动化。这也是我们对DevOps的定义和理解。

自2009年提出DevOps的概念起,很多公司都开始实施DevOps,国外比较著名的有Google、Facebook等,国内著名的有百度、华为、阿里、Flickr等,他们实施DevOps的结果是每天有10次部署,这是非常了不起的。

二、HPE IT在DevOps上的实践

HPE IT部门在2014年年底的时候引入DevOps概念,2015年找了一些内部的敏捷项目做试点,2016年我们开始在400多个应用里推广DevOps。

1、引入DevOps的实际背景

既然要实践要推广,我们看一下目前的现状。IT在开发的流程上使用敏捷已经很久了,所以可以看到,开发实际上采用了敏捷的迭代方法,每个冲刺都会产出一个可发布的产品。到了运维这边,我们不得不遵循企业发布规则:每三个月一次发布窗口,我们就必须等待。根据应用的技术不同,有不同的运维团队来帮助你做生产环境的部署和监控,所以我们得找到相应的运维团队,提前7天提交一个rfc。这些流程做完之后,运维团队开始部署,这时要写一个“部署文档”告诉他怎么上传到服务器,把哪个文件删掉、哪个文件备份等,我看到最大的可能有十几页,很多时候运维人员要管很多项目,部署又有问题。整个流程非常繁琐,敏捷在实现在开发中的运用,但在运维中仍然不足。最后我们看到“部署”变成最后一公里,最后一公里如果没法做到“敏捷”的话,前面的“敏捷”可能就白做了。

2、DevOps持续交付、持续部署
为了解决这些问题,我们提出了一个DevOps的方案,通过持续交付和持续部署来实现。持续交付和持续部署大体上包括了4个部分:1.开发和开发相关的;2.QA测试相关;3.用户测试相关;4.生产运维相关。通过整个的DevOps持续集成、持续交付把开发、测试、运维三者都包括其中。

开发环节的持续集成
我们强调每一个开发人员做的任何修改,必须得在本地通过新功能的单元测试。通过了新功能的单元测试后会做整合,然后提交到代码仓库,一旦提交代码到代码仓库,我们的服务器会自动触发,做自动化构建和比较全面的单元测试,然后再做部署到itg上面,如果这个新的代码通过了itg的测试就会显示时绿色的,没通过会显示是红色的。

有的时候开发很着急,不断写新代码希望做得快一些,不注意细节,QA就觉得很难理解,有的时候甚至构建不起来,提交过来也没办法部署。举个例子,我们要求所有代码都是小写,有一次我们的开发用了第三方的一些库文件,而这个第三方的库文件中间会有大写的字母,这些大写的字母出现在配置文件中,到部署时就可能导致QA环境出错。因为我们的QA环境是Liunx的系统,对大小写比较敏感。

开发经常说:“在我这边是好的,是你的问题,不是我的问题。”为了避免这样的状况出现,我们要求必须得在itg上做测试,这个itg和生产环境比较类似,都是Liunx。

代码分支策略:单分支结构

接下来介绍一个我们的分支策略。我们的代码分支策略叫单分支结构,这样的好处有:

(1)如果在开发时有太多的分支,最后合并会很麻烦。每一次合并分支开发人员都要花少则半个小时到一个小时,多则半天到一天的时间,合并好以后测试人员再做回归测试。整个流程下来,一天就过去了,所以我们不太赞成有太多的分支。

(2)我们持续集成的服务是监控主干的,主干上有任何代码提交都会发现。如果我们不去看这些分支,这些分支就不做持续集成,这样的风险很大。

这是我们分支的策略,我们要求每个开发每天至少要提交一次代码到代码仓库。每天提交、每天做测试就不会那么容易出现问题;如果很久才做测试的话不仅会发现很多问题,而且修改起来非常费时间。我们可以做到大概每天1.5次/人的代码提交。

测试环节的持续集成
持续测试

测试环节主要是新功能和非功能的回归测试。每个地方都有一个圈子,圈上面有剪头,表示持续循环地做,而不是只做一次,所以我们叫“持续做测试”。我们尽量使用和生产环境类似的操作系统、数据等来做测试,这样回归测试做完之后我们就很有信心,因为测试环境和生产环境一致,测试完之后放到生产环境中就很放心了。测试中我们在Shift Letf上的关注有几点:

(1)需求给了开发,开发完之后给测试,大家目的不一致互相不买账,讨论来讨论去大家开始扯皮,到底是开发与测试对需求的理解不一样还是什么?再把BA等拉进来讨论,非常浪费时间,这不是我们希望看到的。我们希望看到的是整个自动的流程就过去了,这样才可以达到敏捷和快速交付的目的。所以我们会在做需求的时候就让测试参与进来。

(2)要把测试尽早来做。我们之前在做敏捷的时候,开发可以做到敏捷,然后交给测试,但测试不一定能够马上就进行,因为还得部署,得找人部署到QA系统。原来都是手工部署,比如我们的前端有5个模块,后端有1个模块,都部署完手工做要将近20-30分钟。

在开始大家工作都不是很忙的时候可以让开发的人帮忙部署,而在最后几天大家都非常忙,开发有很多需要修改的地方,没有时间做其他的事情,所以我们必须采用自动化部署。我们在做“持续集成”的时候有部署的脚本,做进一步的加工和改善,让他直接部署到这个环境。这样QA可以直接选择QA环境部署,也可以在任何一个缺陷提交上来的时候马上做测试。

持续回归

测试方面我们引入的另外一个概念叫“持续回归”。如果你最后做回归测试的话会发现很多缺陷,这些缺陷再让开发修改,时间上会有问题。其实这也是Shift Letf的概念之一,尽早做回归测试并持续做好。我们差不多两天左右会做一次回归测试,持续这么做的好处在于:两周后再做最后一轮的回归测试就相对简单多了,因为这个时候很多回归上的问题很早就被发现并修改了。

自动化测试

自动化测试非常重要,因为持续化的部署和回归测试的频度非常高,持续化的回归两天一次,如果让QA人员做手工测试他们肯定会说:“两天一次怎么做得完?”这就需要进行自动化测试。

每次自动部署到QA环节后,我们的“持续部署服务器”会调自动化测试的框架,其次是关注在稳定的功能模块。我不想去自动化所有的东西,这不太现实,我不希望我们的测试花太多时间在维护测试脚本。

非功能的也要关注,以前开发和测试更多关注功能性的需求,而非功能性的需求运维关注得比较多。很多时候会听到客户关于性能的抱怨:我登陆一两分钟都登陆不进去。DevOps是打破壁垒,融合各个teams。所以开发和测试一定要更多地关注非功能点,关注运维对于性能安全方面的要求。

运维环节的持续集成
准生产环境

我们会给用户做“验收测试”,同样要保证他的环境和生产环境比较一致,比如数据的一致、部署文件的一致。从持续集成开始,文件部署到ITG还是QA还是STG还是生产环境?部署脚本只有一个,我们只给他一个参数,说要什么目标,然后他去做部署。这么做的好处是什么呢?其实这个文件本身是要被测试的,否则自动部署到生产环境会很危险。通过不断地测试,包括QA环境每天都要部署,这么多次部署确定这个脚本没有问题。所有的东西都会放在代码仓库里,包括脚本,部署的脚本也是从代码仓库里实时拿过来再做部署,这是准生产环境。

持续部署

部署到生产环境,我们面临的问题很复杂,要做很多手工的操作。如何改善这最后一公里呢?我们和运维人员商量:你们能不能不要在我每次部署的时候跟我说“你要完成这个,要完成那个”,而是在完成之前我们就开始合作,我部署的过程和你team一起做。因为你对部署是有要求的,你确认这个部署文件是OK的、符合生产环境中对“安全”“稳定”各方面的要求,包括在部署之前我们必须要做的一些安全测试、性能测试,都在我们的部署文件里被自动触发,一旦你认可了,我们就用这个部署文件去部署,然后所有的日志都会被记录下来。这样做的好处是打通了自动化,不用再依赖于运维人员手工部署。

在生产环境中我们会有监控,整个监控体系分为三层:业务监控、应用监控、系统监控。可以看到,我们其实在开发和部署的流程里已经把运维包含进来了。包括我们现在用的更多的云服务,用了“云”以后把运维的一些基本服务给了云商,比如我们用亚马逊或微软的云,如果有问题他会给我们发邮件提醒。

通过DevOps这样的流程我们可以做到把原来高风险的发布变成每次发布一点,但发布的频率很高。业务人员也能接受,有的时候他们要做一些紧急的业务更改,在之前得到的答复是:等三个月,三个月之后给你,这样他肯定不愿意,因为紧急上线;现在得到的答复是:没关系,两个礼拜以后就可以给你,业务人员更愿意接受后者,因为可以保证生产的稳定,保证开发的顺畅。这就是DevOps能够帮助我们解决的问题,减少发布的风险,全流程自动化顺畅。

三、DevOps带来的好处
1、由代码的提交触发:消除等待时间+快速反馈给业务和开发人员。
2、每个变化对应一个交付管道:使问题定位和调试变得简单。
3、全流程自动化:稳定,快速,交付结果可预测。
4、持续进行自动化回归测试:提升交付质量。
5、设施共享并按需提供:资源利用最大化。

这是DevOps在敏捷方面的实施。敏捷大家很熟悉,比如四周一个敏捷项目:第一周做敏捷的迭代、计划会议,周一开始做了,开完会之后开发和测试以及po或ba一起再讨论一下,周四开发,开发到第三周结束,接下来是回归、验收测试、发布上线这样的流程。敏捷通常最后我们会部署在stg给PO做Demo,为了尽可能早的发现问题,我们会在第二周的周四或第三周的周三部署已完成的部分到STG,有的时候业务人员提需求的时候想得也不是很明白,等你做完之后他可能又会觉得不是很好,所以就要尽早测试,有问题尽早改,最后我们发布到生产环境做冒烟测试,然后这里再创建一个新的分支。所有的测试都是循环使用,所有的代码都放在代码仓库里。

四、持续部署Pipeline和工具、DevOps业界工具链

五、这就是DevOps
开发测试运维之前各自为政,现在融为一体能够协同的合作,幸福的生活在一起,这个就是DevOps的文化所关注的。

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.