转载

iOS 持续构建平台实践

58同城App伴随着多年的迭代，业务量的增加，早就迈进了超级App的大门，多条业务线并行研发，百人技术团队参与，项目的快速迭代，对App的质量要求越来越高。无线研发团队对此要保障高质量，高效率的持续交付，本文会对58同城iOS持续构建实践做简单介绍。

背景及目标

首先我们先看一下Git Flow模型，让我们对它有一个大概的了解，如下图所示 iOS 持续构建平台实践 58同城App基本采用Git Flow模型进行开发，其中Develop为当前的版本集成分支，在日常的需求开发中，会首先在版本分支中拉取对应的需求分支(如图中Feature)，待开发结束，测试完成后，再将需求分支合并到版本集成分支中。当然，上述只是对单一工程而言，58同城App的工程及其复杂，通过早期模块化，组件化的配置，由多个工程通过壳工程组装最终编译为App，模块化的简单示意图如下

iOS 持续构建平台实践

在需求开发的时候，需要改变的工程可能是N个，也就对应着N个Git地址，每个Git仓库都需要拉取对应的需求分支，当需求开发完成后N个仓库都需要合并到对应的集成分支上，那么当该版本需求量为M个，最后需要操作的工作量就为N*M，相信这样的工作量对任意一个开发，测试都是一个不小的挑战。对此我们面临着几个问题:

多个需求如何保证稳定，有序，高效的合并集成
如何保证集成分支的稳定性，不污染集成分支
如何利用自动化测试保证代码质量，产品质量

为了解决如上的一些问题，我们利用React+Node.js自主研发了iOS持续交付平台，将开发流程标准化，将需求，代码，测试，集成关联起来，从流程化转变为自动化。

1.需求与代码关联

在需求提测前，我们规定拉取的需求分支命名规则为 "<集成分支名>_<开发人员姓名>_<需求名称简写>" ，例如: 8.10.0_lilei_mainpage ，且所有涉及的Git仓库均采取同样分支名称，在提测流程中，我们会根据分支名称，自动检索出对应Git仓库，这其中的操作都是通过Gitlab提供的API进行操作的，如下代码为检索工程的全部分支 iOS 持续构建平台实践

我们会对Gitlab组内的所有工程进行分支检索，假设匹配到了相应的分支名，则将改工程保存在数组中，方便之后提交MergeRequest，在平台中我们会要求在提测时输入需求描述，标题等，作为将需求与MergeRequest关联的依据,如下图所示 iOS 持续构建平台实践最后通过GitlabAPI完成MergeRequest的创建

2.Jenkins黑盒化

目前大部分公司采用的都是Jenkins实现持续交付，利用Jenkins平台触发打包操作，但是Jenkins本身的操作比较繁琐，且配置比较复杂，但重复操作较多，例如我们提测时需要创建一个Jenkins Job的步骤如下:

输入Jenkins Job的标题
配置Gitlab地址
配置分支名称
配置打包脚本
点击立即构建

为了简化开发工作量，我们将创建Jenkins Job变为一步，点击创建即可 iOS 持续构建平台实践我们会根据之前创建的MergeRequest，自动检索出分支名，需求标题，描述等，作为创建Jenkins Job的配置信息。其中我们操作Jenkins的方式为三方库jenkins,其中Jenkins Job的配置其实是一个XML文件，如下这样我们就可以在我们自己的平台中完成与Jenkins平台的相关交互操作，开发无需关注Jenkins内部的相关操作，这也是平台中比较重要的一个组成部分

3.提测邮件模板化

提测邮件往往是提测流程中比较麻烦的一环，开发人员需要在编写邮件的软件内不断切换到各种页面内，寻找需求描述，寻找任务链接，寻找各个人员的邮箱地址等，然后将各种信息再复制粘贴到邮件中，且有时各个开发人员提测的邮件信息内容不统一，会造成QA的困惑，增加沟通成本，为此我们提供了统一提测邮件模板，并由系统发送。 iOS 持续构建平台实践其中邮件内会自动填充该需求的相关信息，减少开发人员的任务量，以免在提测邮件中浪费过多时间，提升效率。

4.自动化测试保证质量

为了保证代码质量和产品质量，我们在流程中加入了自动化测试 iOS 持续构建平台实践其中自动化测试主要依赖于我们的西部世界平台，专门处理自动化测试任务，在我们的持续集成平台完成前，该平台就已经存在，我们接入时仅需与它交互即可，其中我们利用了Jenkins进行中转，自动化测试流程如下 iOS 持续构建平台实践我们在Jenkins Job执行打包后的任务中又增加了一条任务，用来触发自动化测试任务，进行与QA的西部世界平台进行交互。若测试结果未通过是不准进入到合并流程中，在修改代码后，重新出发自动化测试任务，直至通过，若遇到不可抗力因素，可通知管理员进行跳过操作，以避免阻塞，在此感谢QA同学的大力支持

5.集成分支预编译检查

iOS 持续构建平台实践为了避免集成分支受到污染，我们的集成分支是一直处于保护状态的，且只有管理员拥有合并权限，在需求分支集成时，会在当前的集成分支中拉取预合并分支，先将需求分支合并到预合并分支中，提早的发现冲突，并进行编译检查，若编译检查通过，平台会通知管理员进行代码合并，完成一次需求的集成操作。