本篇文章来自于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的文化所关注的。
本文由壹佰案例技术编辑根据HPE & msup技术开放日讲师的分享内容整理后原创首发，转载或节选内容前需获授权。同时，也欢迎更多企业、社区与TOP100公众账号展开内容合作，更欢迎您成为原创作者。更多内容合作请添加微信EF0815，输出你的技术品牌！