先说一下这次体验的结果，将自己的一个项目提交到了flow.ci上，实现了基本的iOS持续集成的功能，它让我们程序员的世界更美好了一点点。本文篇幅较长，如果你没时间看可以直接跳到 #详细流程# 标题下，或者可以直接到flow.ci官网马上进行体验。
1. 为什么需要iOS持续集成
持续集成是敏捷开发的重要实践之一，设想这样一个场景，你正在考虑如何写一个正则表达式把HTML5里面的信息提取出来，正当你写到一半的时候，测试人员突然来到你后面对你说:“后端上接口了，你给这台iPhone 7打个线上的包我过一下吧”。这时候你刚刚想到一半的思路瞬间消失了，然后你只能中断当前的工作，切换一下git分支，将上个版本重新编译一遍给测试。如果这时候storyboard布局还变动了...那你只好和测试人员大眼瞪小眼直到Xcode把应用安装好了。可是如果你的项目里使用了持续集成，你就能获得以下优点:
- 迭代速度加快，甚至每次commit都可以交付可运行的代码，而测试人员可以尽早进入测试环节。
- 花费在编译，分发这样低技术含量的时间变少，打包的成功率提高，节省更多时间。
- 可以接入测试脚本，在交付给测试人员之前就把低级错误发现出来，比如接口问题，编译问题等。
2. 1 为什么选择flow.ci
主要是因为搭建自建的服务器是非常耗时耗力的!
首先，iOS工程需要在MacOS环境下编译，这个iOS闭源的特点使得我们在选择服务器上有极大的限制。同时，每个团队自建的服务器可能会有一定程度的不同。在错误发生的时候，你的经验决定了你能否准确定位错误，到底是服务器问题？Pod问题？证书问题？还是代码问题？
flow.ci 配置非常简单，迄今为止，我对 flow.ci 的体验大部分情况下还很好。至于定价方面，因为还处于内测阶段，flow.ci 在内测期间完全免费。
2.2 为什么最近才开始
是的，我知道你听得最多是Jenkins，第二多是Travis CI。
Jenkins需要你有一台CI服务器，除非你想把自己的Mac Pro贡献出来，不然还是申请一台Mac Mini当CI服务器。Jenkins+gitlab+fir.im已经是一个比较成熟的持续集成解决方案了，网络上也有一大堆教程，不过问题是需要处理的细节比较多，个人觉得很麻烦，而且有些问题并不是那么容易找到解决方案的。
Travis CI目前只对Github上的项目提供持续集成服务，对于商业项目来说，很少会考虑直接放在github上。
因为 flow.ci 对iOS的集成是在11月4日左右内测，也就是说，这个功能是一个最近才上线的。据说主要是因为需要大量Mac服务器比较难找，这直接导致了我从 flow.ci 刚刚出现的时候就一直关注到现在才用上...真的蛮久了。而且这块功能算是内测中的内测，目前(11月17日)还需要向官方发邮件，等对方提供内测资格。
新上线的功能直接导致了文档不全，如果出了一些问题，没有现成的文档可以参考。幸亏官方团队提供了一个讨论组，反正我在获得内测资格之后，马上进行实验，然后马上就碰到问题，在Google一番未果之后求助于讨论组，官方人员在第二天回复了我的问题，完美解决。
3. 详细流程
3.1 前期准备
- 获取mobileprovision文件和p12，是的，iOS打包内测版时，需要发布证书及相关签名文件。具体步骤可以参考这里。
- 整理工程项目，提交到对应的代码仓库里。
3.2 开始创建工作流
首先打开flow.ci的操作面板，点击创建项目。你可以开始选择代码仓库。目前flow.ci 有四个代码仓库类型可选，分别是
GitHub(世界最大的同性交友网站)
Gitlab(大部分公司会使用gitlab自建git仓库)
Bitbucket(类似中国码云服务，支持私有仓库)
Coding(国内的代码托管服务，支持公有和私有仓库，界面做的很棒，我觉得速度蛮快的)
3.3 授权
github和coding在账户登录的情况下会向你询问是否提供授权(Auth)，否则的话会要求你提供 RSA Key和仓库地址。如果你不知道的话，可以打开终端，输入命令cd ~/.ssh，将想要集成平台的RSA文件内容提供给flow.ci 。
3.4 配置工作流内容
选择好想要持续集成的仓库之后，点击创建第一个工作流来开始接下来的设置。
直接拉到底部，选择iOS模板
感觉你的工程设置对应的Xcode版本，之后提交工程匹配的证书
MobildProvision和p12文件。如果找不到的话可以点击这里来查看。下面设置
构建参数，其实如果你本身有使用xcode自动构建的经验的话，这几个参数和xcodebuild是直接对应的。你可以在工程根目录下，在终端使用 xcodebuild -list命令查看信息来帮你确定下面五个输入参数。FLOW_IOS_COMPILE_WORKSPACE 如果你是集成了CocoaPods的话，这里写的应该是你的工程名.xcworkspace! 注意的是这个地方如果不为空，那么FLOW_IOS_COMPILE_PROJECT就应该设置为空，二者取其一。FLOW_IOS_COMPILE_PROJECT 如果你是一个小项目而且没有集成CocoaPods的话，可以填工程名.xcodeproj ! 注意的是这个地方如果不为空，那么FLOW_IOS_COMPILE_WORKSPACE就应该设置为空，二者取其一。FLOW_IOS_COMPILE_SCHEME 填Targets下面的，如果有多个就需要指定你想要打包的target
FLOW_IOS_COMPILE_SDK 保持默认值即可FLOW_IOS_COMPILE_CONFIGURATION Debug搞定!一个简单的工作流就添加到了你的项目里。我们继续添加其他设置。
3.5 根据需求自定义工作流
- 触发器 提供了根据事件触发打包的Hook，包括Push、Pull、Tag操作，你也可以设置几个定时任务，比如每天下班后执行一次打包。
- 初始化 提供了初始化时候显示的一些信息，同时为一些编译时候的变量进行赋值，下方提供了自定义输出的模板可供选择。
- Git仓库克隆 即服务器
git clone操作 - 缓存 即pod安装包依赖，可以选择启用缓存，那么flow.ci只会在第一次的时候添加依赖(pod install)之后编译就继续使用第一次打包的pod文件。
- 安装
- 编译 即编译时候的一些变量，大部分出错是在这里设置错了，在自动化打包的时候会有对应的提示信息。
- 完成后，提供了Email和slack提醒方式，你可以选择在成功或者是失败的情况下发送邮件到指定邮箱。
3.6 分发到Fir.im
fir.im 为开发者提供测试应用极速发布的服务，测试人员可以通过生成的二维码直接扫描安装测试版应用。工作流中在完成后的左上角有一个+，点击之后选择fir.im上传插件，将你在fir.im里的token写在FIR_API_TOKEN中即可。其他两个参数可以不填。
3.7 一些小细节
-
fir.im上的二维码扫描后进入安装，但是手机报告无法安装该应用- 可能是在MobileProvision中没有将这台手机添加到测试列表中。 -
Code signing is required for product type 'Application' in SDK 'iOS 10.1'关闭Automatically manage signing，在signing中手动选择mobileprovision证书名。 -
You cannot specify both an Xcode project and a workspace.编译变量FLOW_IOS_COMPILE_WORKSPACE和FLOW_IOS_COMPILE_PROJECT选择一个填就好了。 -
The workspace named "XXX" does not contain a scheme named "XXX".查看你是不是选择对了Scheme。如果确认自己写的是正确的，那么在检查Manage scheme是否开启shared。
4. 下一步目标
集成单元测试和UI测试
5. 相关资源
flow.ci 讨论组
Fir.im 应用分发
flow.ci官方网站
(转载请注明来源)
