先说一下这次体验的结果,将自己的一个项目提交到了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
下面的,如果有多个就需要指定你想要打包的targetFLOW_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官方网站
(转载请注明来源)