关于iOS自动化打包的一些分享

说到自动化打包, 相信你们在平常开发中都有所接触, 尤为是在多分支并行开发的状况下, 自动化打包显得尤其重要, 不少时候, 咱们打包通常是打及成分支的包, 开发却在开发分支上, 若是采起手动打包, 咱们须要反复切分支, 不只影响工做效率, 并且会打断咱们的开发思惟, 而却在工程较大的状况下, xcode每次indexing须要的时间就好久。

即便对于不少单分支开发的小项目来讲, 自动化打 包的优点也是不言而喻的, 由于在手动打包的同时, 基本能够说是什么事都作不了的, 你须要一步步等待archive, export这些机械化的步骤。而有了自动化打包, 你只须要点击一个按钮, 即可以继续本身的开发。因此, 自动化打包势在必行。

本文主要记录了我在公司自动化打包布置中的一些探索, 及各平台的优缺点和配置过程踩过的坑。

谈到iOS的持续集成, 咱们首先想到的必定会是jenkins, 这里我先介绍下我司采用的Mac OS Server(如下简称Server)这个平台的一些优缺点。

Server相比于jenkins, 我总结优势有三:

1. 相比于jenkins的各类繁琐配置, Server配置简单, 全程基本下一步操做便可;
2. 直接使用xcode就可开始构建项目, 而不须要登陆网页;
3. 集成度至关高, 没有特别的需求, 基本能够不写脚本, 只须要配置一个plist文件便可以打包。

这里不作过多的配置介绍, 虽然Server没有jenkins热门, 但网上的文章也比比皆是, 并且如上优势1中所说, Server配置真的很简单, 在证书、描述文件齐全的状况下, 基本就是一直点下一步操做。

下面我介绍使用过程当中须要注意的一些方面:

如上图所示, 上图是对bot的各类设置, 一个bot对应一个独立工做空间, 若是有了解jenkins的话, bot能够类比jenkins的一个项目。

若是对打包没有特别需求, 勾选Archive, 选择对应Scheme、Configuration, 指定一个plist文件, 后面的Triggers不须要写任何代码, 即可以打出对应的包。

上面所说的plist文件大致结构是这样的:

这个plist文件对应一系列的参数, 并不须要咱们本身写, 手动打一次包, 便可导出这个文件。这里顺便提一句, Server配置好后, 链接此Server后, 任意机器均可以上传此plist文件, Server是将上传的plist文件拷贝到当前Bot工做目录下。

在Server配置好后, 即便是windows电脑也能够经过ip或者自签证书登陆, https://192.168.0.xxx/xcode/lastest 或 https://xxxdemac-mini.local/xcode/bots/latest, 登录后会显示如下界面, 点击integration, 即可以开始集成了, 可是这里彷佛只可以集成, 不能配置, 不过根据Apple的惯性, 想要构造本身的生态, 咱们也是能理解的。

关于jenkins的一些配置注意事项:

如下是我在配置过程当中踩到的一些坑:

1. 8080端口被其余程序占用, 启动失败: java -jar jenkins.war —httpPort=8082;
2. git权限须要告诉jenkins私钥, 而不是git上的公钥: cat ~/.ssh/id_rsa;

接下来, 其余用户直接经过浏览器登陆 http://192.168.0.xxx:8082 , 经过帐号密码登陆, 即可以配置和构建项目。

jenkins相对Mac OS Server的优势:

1. 同一局域网即可以登陆, 登陆以后即可以自行配置项目
2. 彷佛能够并行构建任务

当使用Mac OS Server进行打包, 不管进行多少个打包任务, 它只开启一个xcodebuild进程

而使用jenkins进行多项目打包, 这里开始构建两个项目就开启两个进程(下图上面两个xcodebuild进程是jenkins开启)

这里我没有作定量的测试, 猜测是jenkins的效率稍优, 对于多核处理器, 相同的计算能力, 对于两个构建来讲, 应该没多大差距, 但对于拉代码等耗时操做, 比起Server其余构建任务在排队, 这部分就能省上一些时间。

可是jenkins有更方便的打包方式: jenkins开启token, 不须要用户名登陆即可以打包:

这样给构建项目设置后仍是不行的, 由于jenkins以为这样是不安全的, 拿到了token就能够作任何事了。 系统管理->全局安全配置->勾选 Allow anonymous read access

接着, 咱们即可以经过命令来打包:

curl http://10.24.113.24:8082/job/notification_extension_test/build\?token\=123\&cause\=testBuild
复制代码

参数	注释
notification_extension_test	项目名称
token	上面设置的token
cause	可选参数, 可不传

这样彷佛能够用一台服务器, 将打包任务部署到指定机器上:

这样能够在一台机器上集成公司不一样端的项目, 并且还不影响打包效率。

关于Server和jenkins的一些总结:

1. 若是仅仅是iOS端的打包, Server是彻底够用了, 并且操做贴近咱们平时的开发风格, 虽然网页没法配置, 可是对于大部分公司来讲, 打包配置都是开发在作的, 而不是测试;
2. 对于iOS端小型项目来讲, 没有特别多的分支, 直接能够多建几个bot, 从而避开手写脚本;
3. 若是多端同一服务器, 那么jenkins无疑有较大的优点；若是公司有足够的电脑做为分布打包服务器, 那么打包效率会更上一层楼。

fastlane及打包脚本简单介绍

说到自动化打包, 就不得不谈当下很是流行的fastlane, 若是说Server和jenkins是同一维度的, 都是打包平台, 那么fastlane应该是和shell脚原本做比较, 或者能够说, fastlane是在shell的基础上封装了一层, fastlane相比于脚本打包, 短暂体验后, 我以为优势主要有:

1. 避免繁琐的路径拼接, 拷贝等
2. 修改工程配置文件, 避免调试时修改配置文件不当心提交到远程分支, 致使打包失败

咱们来简单看一段fastlane的打包代码:

上述代码参数基本见名知意, 不难看出, 这基本就是给以前Server的exportPlist文件的一种包装, 只需执行

fastlane adhocMyApp version:100000  // 100000是传的版本号
复制代码

即可以自动打出一个包, 并导出dSYM文件, 这里我故意把Distribution的provisioning Profile改为企业的

发现工程配置文件发生了改变, 这里比较暴力, 把每种configuration的Provisioning Profile和teamID全都改了

咱们再看终端, 看看fastlane究竟作了些啥

也确实和上图同样, 把全部都改为了AdHoc的。在进行修改配置后, 最终也是执行打包的核心脚本:

// 对应手动打包archive
xcodebuild archive -workspace ${work_space} -scheme ${scheme} -configuration ${configurationRelease} -archivePath ${archivePath}
// 对应导出步骤
xcodebuild -exportArchive -archivePath ${archivePath} -exportPath ${exportPath} -exportOptionsPlist ${exportOptionsPlist}

复制代码

上述脚本的参数也基本见名知意, 脚本中${work_space}等表明取一个变量的值, 这里都是各个配置对应的路径或字符串。

经历上述脚本后, 就会在指定的exportPath路径下生成.ipa文件。咱们通常是要将ipa和dSYM文件copy到指定的文件夹供测试去取, 后面即是一段处理繁琐的路径的脚本, 脚本自己没任何难度, 可是要格外注意, 且测试起来须要花费必定的时间, 若是使用fastlane就能够避免这个烦恼。

总结

本文主要是团队中的一次分享后的整理, 并非特别细致的教程, 只是对当下的自动化打包的一些尝试及过程当中遇到的一些问题和本身的一点思考, 若是有说的不对的地方, 望不吝赐教。