肖俊：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等拉进来讨论，非常浪费时间，这不是我们希望看到的。我们希望看到的是整个自动的流程就过去了，这样才可以达到敏捷和快速交付的目的。所以我们会在做需求的时候就让测试参与进来。…