前言

iOS 开发在经过这几年的野蛮生长之后，慢慢地趋于稳定。无论开发语言是 Objective-C 还是 Swift,工程类型是 Hybird 还是原生，开发思想是 OOP 还是函数式，随着项目逐渐变大都在面临相同的问题: 测试、发布等重复性工作占了很大一部分时间，回归成本越来越高。持续集成不可避免地被提上了日程。

本文主要阐述 iOS 下的持续集成，以目标、内容、流程、工具入手，希望可以为大家描绘一幅 iOS 持续集成的蓝图。这可能不是一篇可以让你 Step by Step 跟着做的文章，但愿可以在你脑海中建立相关概念，以便在实操时走对方向。

我们会在后面几篇内容中，详细阐述 是什么 和 如何做 。

目标

对于我们来说，减少重复工作、提升团队效率。 对于公司来说，省钱！

狭义上持续集成指早集成早测试尽早早发现问题早修复，并辅以一些自动化的手段，其目标是减少修复的成本。通过其目的，我们可以发现，其实通过自动化减少重复工作和通过早发现问题降低成本是持续集成的核心理念。因此，我把自动化 Code Review 也放到这里讲。

内容

iOS 下的持续集成内容包括自动化 Code Reivew、自动化单元测试、自动化打包和自动化分发。自动化 Code Review 保证团队遵守代码规范，在编码阶段减少 BUG 的产生。在人员流动较大的公司里，用同一套代码规范，也可以保证项目交接更流畅。自动化单元测试在集成阶段检测出 BUG ,以减少回归成本。自动化打包和自动化分发则是减少重复劳动，毕，工程师的时间就是金钱啊。

自动化 Code Review

顾名思义，自动化 Code Review 既采用自动化的手段，对团队成员得代码进行 Review，以保证代码质量。从现实角度来说，自动化的 Code Review 更多地是对代码进行静态分析，通过扫描代码并对比制定的规则，产出所需要的结果。这个所需要的结果，可以是工程总体的量化的质量报告，也可以是显示在 Xcode 中的一条警告⚠️。这取决于用户是什么角色。

在实际实践中，一般会有两种角色会关注这份结果 -- 工程师和管理层。工程师需要在开发的过程中及时了解代码错误，以便及时纠正。管理层需要了解工程的总体代码质量，以掌握项目的相关风险。同时，也可以作为工程师绩效的依据之一。

要完成这一块内容，我们需要这些工具:

• Jenkins
• SonarQube
• OCLint OR SwiftLint

通过这三者协作，我们可以实现以下流程:

工程师通过 `Git Commit` 提交代码 → Web Hook 触发 `Jenkins` 构建 → `OCLint` 扫描代码生成PMD格式报告 → `Sonar-runner` 读取报告并展现到 `SonarQube`。 

关于 Code Review 需要指出的是，自动化工具是有局限性的。其无法分析出较为"智能"的规则。比如说下面这条

4.7 方法名以小写字母动词作为开头

还有下面这种代码，尽管含有多个容易造成闪退的 BUG,也是可以顺利逃过分析器的眼睛的

if result?.bindPhone == "true" { let range = (result?.loginId?.startIndex.advancedBy(3))!...(result?.loginId?.endIndex.advancedBy(-5))! let phoneNumber: String? = result?.loginId?.stringByReplacingCharactersInRange(range, withString: "****") self.phoneNumLabel.text = phoneNumber!
} 

因此，想要达到 “保证代码质量” 的目的，还需要人工 Review 和自动化 Review 相结合。

自动化单元测试

自动化地执行单元测试，在测试失败的情况下中断集成，并通知相关人员，就是这一块工作的内容。

为此，我们需要如下的工具:

• Jenkins
• xctool

我们可以实现以下的流程:

`Git Merge`  → Web Hook 触发 `Jenkins` 构建 → xctool 执行单元测试 → 如果失败则发邮件给相关人员。 

当然，如果你公司的项目托管在 GitHub 上，业界有两个非常的 Jenkins 替代产品 travis-ci 和 circle-ci。他们对 GitHub 的支持完美，且对开源项目是免费的。私有项目则需要付费试用。

在单元测试这一块，高的成本还是写单元测试的时间成本。脑洞大开地说，如果能实现一款工具，可以自动地为业务代码生成测试代码，那才是生产力的大大提升。

自动化打包与分发

一次完整的打包，需要经历配置证书、切换环境、调整参数(构建版本号等)、Archive、导出。 根据工程的复杂程度，以上过程快则五分钟，慢则半小时。当需要频繁发版的情况下，浪费了工程师非常多的时间。

我们其实可以利用一些工具来实现这样的一个流程:

Git Merge 到 Master（通常这意味着一个 Release）→ 触发 Jenkins 构建生成 ipa → 自动化分发。

自动分发包含以下工作：

• 自动上传 App Store
• 自动使用 TestFlight 分发
• 自动上传到 蒲公英/Fir 等平台
• 自动上传到企业 App Store

我们可以分别配置相关的脚本，来实现测试的分发，和发布等。

要实现这样的流程，我们需要这些工具:

• Jenkins
• Fastlane

Fastlane 是由一个个小组件组成的工具，功能包括上传截图到 iTunes Connect,创建 provisioning file, 管理 TestFlight 的测试员，分发等。这个工具几乎可以用命令行来实现打包上传分发相关的所有功能，并且越来越有成为默认的业界持续集成标准工具的样子。就像 CocoaPods 在依赖管理方面一样。

总结

持续集成，可以看做是通过版本控制系统、CI平台(如Jenkins)和相关工具链来完成一套工作流，以减少团队重复性工作，并保证软件可以不停地迭代而不出太大的差错。iOS 下的持续集成大体就是上述几块内容，我们在实现的过程中遇到了不少坑，后面的文章分块详细讲。