企业级DevOps实战案例-移动APP持续交付实践

本文由团队内大瑶同窗撰写。

 

 

引言

 

移动App具备更新频繁的特性，这一点，从各大App在应用市场的版本发布频率可见一斑。高频发布意味着迅速迭代和交付，这对需求、开发、测试、运维的效率提出了更高的要求。那么，在快速变化的互联网环境下，如何在保证质量的前提下，提升App的交付速度？这是业界共同面临的问题。DevOps提供了解决该问题的答案，它倡导尽量多地对软件构建过程当中的全部步骤进行自动化处理，也就是构建自动化流水线，以提升效率、缩短开发周期。在当今的IT领域，DevOps倡导的持续交付理念已经被广泛接受，实施DevOps实践已经成为软件组织管理的趋势。近几年，随着敏捷软件模式的深化，咱们也一直在尝试敏捷、持续集成等实践，以积极的态度拥抱DevOps。

 

值得重视的是，DevOps并不是一个固定的模式或标准，事实上，业界对DevOps没有统一的定义（并且DevOps的定义是随着时间不断演变的）。它是一种普适的软件工程文化和实践，但每一个企业的组织文化有差别，DevOps基础也不尽相同，现有的一些成功方案每每并不彻底适合团队的实际状况，业界也不存在一个万能的实例供咱们复制。所以，应当基于自身实际状况，参考同类优秀案例和经验，摸索出最适合本身的模式。一方面，咱们缺少专门的工具部门或团队，短期内没法创建起大型的一体化持续交付平台；另外一方面，咱们又急需创建起持续交付流水线，以改进敏捷产品的开发测试流程。所以，咱们以开源持续集成工具为核心，再适当开发辅助工具，构建了一个较为实用的App产品持续交付流水线。

 

1、案例背景

 

随着App的功能日益复杂，与第三方合做的模块愈来愈多，开发、测试阶段联调的难度也随之增长。同时，为迅速响应市场需求变化，App的迭代愈来愈快，发布周期愈来愈短。工期紧、任务多，这给开发、测试人员带来了很大的压力，例如，开发为了按时完成代码，挤压了一些原本用于代码评审、单元测试的时间，致使项目代码的质量降低；随之而来的是生产风险的提升，产品质量难以保障；开发须要花费额外的精力偿还技术债（漏洞、不规范的代码等），这又给新一轮迭代带来风险——如此便陷入“疲于奔命”的恶性循环。

 

为解决上述问题，在参考DevOps等主流解决方案基础上，咱们也吸取DevOps和敏捷理念，开展App产品持续交付流水线实践，从工艺改进、组织文化等方面，改进App产品的持续交付实施过程，最终构建起一条完备的流水线。

 

2、案例内容

 

（一）问题分析

 

与其余产品不一样，App的交付比较特殊。例如，H5产品须要将部署包放置到服务器上，并进行相应的配置，用户就能够经过访问网址获取服务；而安卓和IOS并非部署在企业本身的服务器上，而是须要在各自的应用市场“上架”，用户才能从市场上获取App，安装到本身的手机上，完成交付过程。

 

对症方能下药，咱们首先必须明确，是什么影响了App的迭代效率？通过分析和总结，咱们发现，App的实施过程存在如下痛点：

 

一、开发任务繁重，代码质量不高。

 

形成这一点的缘由有不少，如需求规划不合理、环境问题致使联调失败、代码评审不到位、测试覆盖不全面等。

 

二、版本分发效率低。

 

因为App产品的特殊性，用户必须在手机上安装新版本才能获取其服务。在开发人员频繁打出新版本的场景下，测试者须要及时得到最新的App版本。然而现实状况一般是开发在本身的电脑上构建（俗称“打包”），再把构建出的App安装包发给测试人员——这样人工的构建分发效率低，也难以保证构建出的安装包是“合格”（即经过了单元测试、代码扫描等必要的检查环节）的。

 

三、容易出现不一样环境下版本不一致问题。

 

在测试阶段，测试人员一般对测试环境下的版本进行测试，而产品发布时，使用的是测试版本对应的生产版本，必须作到这个两个版本除了环境相关的参数配置不一样外，其余代码彻底一致。然而从测试经过到人工切换成生产环境参数并构建生产版本的这段时间，可能会存在开发人员改动代码的风险，致使一个未经测试的App版本被发布。所以，须要寻求同时构建多个不一样环境参数的App的方案。

 

四、测试分析不到位，同类质量问题重复出现。

 

咱们的目的不只仅是修复问题，并且要保证往后再也不发生一样的错误。事实上，一个产品的缺陷能够给其余产品带来启发，咱们须要吸收他人的经验和教训，增强不一样产品之间的交流。

 

以上几个问题，其实都是缺少规范的流程、人工介入过多等缘由形成的。当人工操做影响到工做效率时，应当考虑借助工具来节省人力，提升效率。

 

（二）方法体系

 

从工艺改进和组织文化两个方面入手，逐步构建起持续交付的实施流程和与之匹配的组织结构。

 

一、从工艺改进的角度，构建App持续交付流水线。

 

● 分别对DevOps的各个步骤进行优化和改进，并组合成一条基于Jenkins自动化持续交付流水线，覆盖从需求到交付的各个环节，从实施流程上规范App交付的各个环节，如优化需求拆分、强化代码评审等步骤，提升代码质量。

 

● 自主开发小型工具，如App持续交付工具、挡板系统等，完善上述流水线，以提升开发、测试效率。

 

二、进行组织结构调整，开展开发测试融合实践。

 

● 在开发测试融合思惟的导向下，开发与测试团队被规划到同一部门，这消除了部门壁垒，使得敏捷迭代中开发、测试成为一个总体，强化了两者的沟通和联系。

 

● 强化质量监督环节，测试团队发挥QA做用。测试团队再也不仅仅负责传统的测试工做，而是统筹测试实施、质量管理、工艺改进三大板块。在这种模式下，测试团队不只仅负责传统的测试实施任务，还要深刻敏捷团队，担任QA角色，监督自动化测试、持续集成等环节，从更高层次上把控产品质量。

 

● 开展DevOps相关的交流活动，如开放日、系列培训等，在部门内部、部门之间进行推广和交流，互相借鉴经验，培养员工的持续交付理念和能力。

 

（三）构建持续交付流水线

 

在各种资源有限的状况下，咱们必然要借助现有工具来支持持续交付实施过程。做为最受欢迎的CI工具之一，Jenkins成为咱们的首选平台。它以插件的形式支持各类功能（官方提供了丰富的插件库，开发者也能够根据官方API开发定制化插件）。此外，Jira、Sonarqube等受业界承认的工具成为流水线的组成部分。

 

一、App持续交付流水线

 

正所谓“工欲善其事，必先利其器”，自动化流水线的搭建必然须要借助工具。业界对于持续交付流水线工具的选择，能够大概分为两类：一是使用通用的CI、CD工具，二是使用一体化DevOps平台。前者灵活通用、不须要太多成本，但缺乏业务元素；后者提供一站式解决方案，但通用性不强。

 

既然短期内不具有采购或自主开发一体化DevOps平台的条件，咱们选择前者来实现交付流水线。如图1所示，将各个环节如同串珠子同样串联起来，组合成完整的流水线。

 

图1 App交付流水线

 

1）需求/知识：需求决定了任务量，进而决定了开发、测试的工做量，也直接影响代码的质量。所以，要从流水线源头进行改进，避免因需求规划不合理影响开发效率。

 

● 过去：存在需求堆积、粒度过粗、变化频繁，把开发“逼疯”的状况；过度依赖人工看板，不容易统计迭代燃尽图、故事活跃度等数据。 

● 如今：合理规划需求、减小任务粒度，减轻迭代工做量，为实现小步交付作准备；使用Jira电子看板，方便存档用户故事、问题等，更好地把控敏捷健康情况。

 

2）源代码：使用SVN或Git托管代码。代码库也有鄙视链，在大多程序员看来，彷佛Git才是更“高级”的工具。其实，不管是SVN仍是Git，都具有至关完备的功能，选择哪种工具并不重要，关键的是如何规范使用。

 

● 过去：因为并行任务多，分支策略混乱，代码整合起来很复杂，耗费人力。 

● 如今：逐步转换成串行任务，采起主干开发策略，减小产品并行开发的状况；强化代码提交纪律，如要求开发必须通过本地构建成功、单元测试经过、规范检查经过后方可提交，且注意及时拉取和提交代码。增强对关键逻辑代码的管控和审查，改进代码评审方式。

 

● 过去：人工走查的方式，常常一拖再拖，积压了大量代码，致使走查时耗费大量时间，效果也难以保证。 

● 如今：利用相关工具（如Gerrit）实施代码评审环节，取代原始的人工走查。这样既能够及时发现问题，又能减小开发人员的工做量。

 

● 过去：CI纪律形同虚设，常有构建失败无人处理的状况。 

● 如今：强化CI纪律，每一个敏捷组配置红绿仪表盘，实时查看动向。如有构建失败，当即进行修复，修复不成功全组不下班。

 

3）代码拉取：即Jenkins从代码库拉取代码、触发后续流水线/Job构建。这一般是Jenkins Job执行的第一步。

 

4）自动化测试：主要分为自动化单元测试、自动化接口测试、自动化UI测试三部分。其中自动化单元测试做为Job的一个环节，随着Job构建而执行；而其余两类自动化测试则借助专门的自动化工具（RobotFramework、Appium）实施，在Jenkins上进行相应配置，可定时触发和构建自动化测试Job。

 

5）静态代码扫描：对于代码的质量，不能仅仅局限于那些“可视的”bug。代码中每每存在大量潜在的问题，如健壮性问题、浮点数比较大小等，不容易被发现，但就像定时炸弹同样，是产品质量的隐患。所以，咱们借助静态代码扫描工具进行代码扫描。例如，Sonarqube工具为各开发语言提供了静态代码扫描支持，用户也能够自定义本身的规则。对于扫描出的各种问题，要求开发尽快解决。此外，Sonarqube还能够读取自动化单元测试报告，并将单元测试结果展现在其仪表盘上，方便相关人员随时了解代码质量。

 

6）安全扫描：增长安全扫描环节，提升代码安全性。以Checkmarx安全扫描工具为例，在流水线中引入Checkmarx插件，触发安全扫描环节。同时，对于扫描报告中出现的问题，要求开发予以解决，将问题及时归零。

 

7）App加固：对App进行加固处理，防止被反编译。

 

● 过去：使用客户端进行加固。 

● 如今：为了将加固环节自动化、归入持续交付过程，使用shell脚本调用加固命令，取代手动加固。

 

8）构建：前面的环节都是为了这一步作准备。对App产品而言，最终构建的结构是生成安装包（ipa或apk）。App开发涉及开发、测试、灰度、生产环境，如何保证其处理环境参数外，其余代码彻底一致，是值得咱们关注的问题。对此，咱们借助Jenkins的Pipeline流水线，提出并行构建机制。

 

● 过去：开发通常在开发、测试环境下编写代码，经过测试后，手动修改代码里的环境配置，而后构建出对应的生产版本，用于后续投产。若这个过程当中有人修改了功能性代码，则构建出的生产包包含未通过测试的代码，直接投产的风险可想而知。 

● 如今：项目代码设置多环境（开发、生产、测试等环境）配置，执行构建命令时可指定环境，从而构建出对应环境的App版本；使用Pipeline并行脚本，同时构建出多个环境参数的版本，这几个版本除了环境配置不一样，其余彻底一致。在选取生产版本时，强制选择其中的生产版本，该生产版本和测试版本同时被构建出，不存在被修改代码的可能，能够保证App功能测试版本和生产版本一致性。

 

9）制品：制品即安装包，也就是构建出的版本，将被推送至App持续交付工具进行统一管理。

 

二、流水线中的工具建设

Jenkins不是万能的，它只提供了一个纯粹的流水线引擎，不包含业务属性。也就是说，Jenkins上的流水线没法关联软件管理周期中的需求、项目、任务、产品等元素，它们只能是一个无层次的平行Job的集合。所以，上述环节并不能知足App建设的实际须要。为此咱们自主研发了几个工具：App持续交付工具、QA仪表盘、多协议挡板系统、错题本，以进一步提升交付效率。

 

● App持续交付工具：App产品版本管理的平台，提供开发、测试、交付功能。

 

1）可对接Jenkins平台，获取Jenkins制品，并按照其对应的环境参数，分阶段统一管理，解决Jenkins Job无序、缺少制品管理的问题；

 

2）App可经过扫描二维码进行下载安装，取代原有的手工分发模式，极大地提升测试效率。

 

3）提供灰度发布功能，用于App的灰度测试。

 

● 多协议挡板系统：提供模拟接口，用于环境不联通致使真实接口没法调用的场景。开发人员再也不手动编写假数据，而是像调用真实接口同样调用挡板模拟出的接口，解决环境不通引起的进度阻塞问题。

 

1）实际开发阶段、测试前期中，每每会遇到接口不通的问题，影响开发进度，使用该挡板能够Mock接口。

 

2）现有接口不具有复杂数据、特殊场景等，对测试异常状况形成困难，此时可使用挡板模拟特殊数据，进行相应测试。

 

● QA仪表盘：必要的质量监督环节能够提升开发、测试的QA意识，QA仪表盘是对流水线质量数据进行收集和统一展现的平台。尽管咱们能够从SVN、Jenkins、Sonar上看到相应的数据，但它们基于分散的Job，无产品关联信息，且缺乏统计类数据。为了更好地发挥质量监督做用，咱们开发了QA仪表盘，将各个环节质量数据进行收集、加工、展现。

 

1）以产品为基本维度组织数据，并进行团队、部门等不一样层级的统计和展现。

 

2）提供邮件订阅等个性化功能，方便用户按期监督产品质量数据。

 

● 错题本：顾名思义，这是一个记录质量问题的平台。各个阶段注入的问题（需求、开发、测试分析、测试实施、运营等）均可以归入这个平台，并进行详细跟踪记录。测试经理也会按期从错题本导出问题，组织质量问题分析会。经过及时记录问题、分析问题，能够为之后的测试分析积累经验，避免同类质量问题重复出现，减小往后“踩坑”的概率。

 

（四）开发测试融合组织形式 

 

开发测试融合与敏捷实施是相辅相成的。从组织结构上看，将开发、测试团队融于同一部门，其中测试团队承担部门的测试实施、质量管控、工艺改进（工具建设）工做；产品以敏捷组为单元开展任务实施，敏捷组里包含PO、开发、测试，逐步创建起一个全功能敏捷虚拟团队。经过这样的组织调整，增强测试与开发的联系，也加强敏捷团队的集体意识，有利于培养DevOps文化氛围。

 

伴随着上述组织调整，测试团队的职能也发生了改变。过去，测试团队的主要任务是实施测试任务，测试经理们重点关注的是案例执行状况、测试流程等；而随着开发测试融合的推动，咱们赋予了测试经理更多的话语权：测试经理承担产品QA角色，从产品需求到投产阶段结束，关注整个工程活动周期的质量问题，如用户故事质量、单元测试状况、缺陷分析等，创建QA全流程质量控制机制。从这个角度讲，测试经理要不断提升自身能力，培养更全面的质量意识。

 

3、案例效果

 

通过上述一系列提高和改进工做，App产品的交付效率有了明显改善，各敏捷小组的质量意识和CI意识也获得了显著提高，DevOps的氛围已经造成。

 

一、App产品的迭代速率明显提升。得益于App持续交付流水线的有效实施，任务下达至完成时间明显缩短。App持续交付工具、挡板等工具获得了有效推广，工具赋能对于开发、测试效率提高发挥了巨大做用。

 

二、迭代质量显著提高。2018年之前，部门迭代成功率仅为70%，2019年已提高至93%。迭代过程当中，持续交付流水线的构建成功率也保持在80%以上。

 

三、产品质量明显提高。开发更加注重本身的代码质量，并在QA的监督下关注自动化测试数据，从而使开发团队的Bug数量明显减小。自动化接口测试积累了大量案例，自动化单元测试覆盖率从无到有，从有到高，目前部分产品覆盖率已达90%以上。

 

 

本文介绍的实践案例仍处于初级阶段，App持续交付流水线还存在很大的提高空间。将来，计划进一步优化持续交付流水线，扩展工具功能，深化DevOps实践。