Fastlane + Bugly自动化部署测试包

对一个iOS开发者而言，当你专心利用一个周期快速开发了一个版本时，在上线之前总是面临不断对内或对外发布测试版本需求。而这个过程中，应用发布和证书管理基本上都是最令人头疼的问题，好在证书的问题已经在XCode 8.0中得到充分自动化管理，基本不需要额外接入。而打包则无法避免的要走向如下重复的流程:

修改测试版本号
修改Build版本号
执行Archive
选择Adhoc导出IPA安装包文件
上传Bugly测试平台
分享测试链接二维码

如上流程是极为繁琐枯燥且毫无技术含量可言，而当一个小的需求发生变化甚至是一处小的文案的修改，你都要按照如上再次重新Rebuild. 简直是扼杀工程师的宝贵时间. 如果你跟我一样饱受部署的痛苦，我想Fastlane也许是你的救星.

FastLane

初次邂逅Fastlane是其去年5月份，当我看到完全有一个工具能够完全自动化这个流程，异常的兴奋。

Fastlane本身包含两大模块，一个是其内核部分，另外一个就是Action了。Action是Fastlane自动化流程中的最小执行单元，直观上来讲就是Fastfile脚本中的一个个命令，比如：git_pull，deliver，pod_install等等，而这些命令背后都对应其实是一个用Ruby编写的脚本。

Fastlane 是一套用 Ruby 编写的 iOS 命令行工具集（后来也支持了 Android），主要组件包括：

match / cert / sigh 协助管理代码签名
pem 自动生成 APNs 证书
scan 自动化测试
gym 自动化编译并打包生成签名的 .ipa 文件
snapshot / frameit 协助处理 iOS 屏幕快照
pilot 上传和管理 TestFlight
deliver 将应用及其它信息上传到 App Store

而正是这些颗粒度极小的Action，根据自己需求组合成一个自动化的链条。我猜想，Fastlane的作者们在项目的早期甚至规划的阶段，应该就考虑到了这一点：在实际开发中，自动化的业务场景太多，每个团队可能都有自己的独特需求，单靠一两个人的力量是无法满足的，所以如何将涉及到实际业务的功能开发，用优雅的方式交给开源社区中庞大工程师们来维护，成为Fastlane架构中需要重点考虑的内容。所以你可以看到官方Actions文档中包含大约170多个Action，这些Action大部分来自开源社区贡献。

安装

首先确保Xcode命令行工具是最新版本的:

xcode-select --install

安装Fastlane:

sudo gem install fastlane -NV

找到工程文件目录下执行：

fastlane init

在执行“Your Apple ID" 这一步输入苹果开发者账号，fastlane 会自动获取工程文件名，目录等其他数据。这一步“Please confirm the above values”，确认信息，没问题则输入 y。然后，fastlane 会进行一系列的初始化操作，包括下载 App Store 上的元数据和截屏文件。等待初始化完成之后，工程目录下就多了一个 fastlane目录：

$ cd fastlane && ls
Appfile            Fastfile           metadata           report.xml
Deliverfile        README.md          screenshots

文件目录：

metadata目录下存放整个元数据文件，包括关键词、版本更新日志、图标等.
screenshots目录下存放应用截图
Appfile文件记录App的 bundle ID、Apple ID、Team ID三种信息.
Fastfile脚本的核心执行文件.有几个默认的选项，可直接使用.
report文件时每次执行fastlane时生成报告.

安装fastlane成功后，首先拆解我们需要自动化的两个流程:

自动打包成Adhoc的安装包ipa文件
通过fastlane自动上传到bugly

很多肯定问为什么不合并成一步，其实完全是可以的，只是上传bugly需要额外单独设置对应版本一些描述信息。我为了方便自己控制，拆分成了两步.

自动化打包

自动化打包使用最多就是Fastlane中gym这个Action, 转为打包而生, 安装gym这个组件:

sudo gem install gym

cd项目根目录, 创建自动打包脚本:

vim gym.sh

输入脚本内容:

#!/bin/bash
#计时
SECONDS=0#假设脚本放置在与项目相同的路径下project_path=$(pwd)#取当前时间字符串添加到文件结尾now=$(date +"%Y_%m_%d_%H_%M_%S")#指定项目的scheme名称
scheme="Xitu"#指定要打包的配置名
configuration="Adhoc"#指定打包所使用的输出方式，目前支持app-store, package, ad-hoc, enterprise, development, 和developer-id，即xcodebuild的method参数export_method='ad-hoc'#指定项目地址
workspace_path="$project_path/Xitu.xcworkspace"#指定输出路径
output_path="project_path/APP"#指定输出归档文件地址
archive_path="$output_path/Xitu${now}.xcarchive"#指定输出ipa地址
ipa_path="$output_path/Xitu${now}.ipa"#指定输出ipa名称
ipa_name="Xitu${now}.ipa"#获取执行命令时的commit message
commit_msg="$1"#输出设定的变量值
echo "===workspace path: ${workspace_path}==="
echo "===archive path: ${archive_path}==="
echo "===ipa path: ${ipa_path}==="
echo "===export method: ${export_method}==="
echo "===commit msg: $1==="#先清空前一次build
gym --workspace ${workspace_path} --scheme ${scheme} --clean --configuration ${configuration} --archive_path ${archive_path} --export_method ${export_method} --output_directory ${output_path} --output_name ${ipa_name}

#输出总用时
echo "===Finished. Total time: ${SECONDS}s==="

把如上脚本中Xitu改成你的项目名称即可. 为脚本执行提升权限:

chmod +x gym.sh

执行一下脚本看一下打包效果:

./gym.sh

执行结果:

经过572s，Adhoc版本的ipa文件打包成功，我们在项目根目录下找到App目录：

会发现如上三个文件. ok.至此自动化打包ipa文件流程完成. 关于gym这个action调用强烈推荐看一下官方文档的调用参数,对你调试过程会非常有帮助.

上传Bugly

为什么选择Bugly呢？其实原因很简单，他能够把崩溃发生时页面访问路径和崩溃堆栈信息自动根据符号表翻译可以读懂调用代码路径. 在定位异常上更为直观，而最关键的是Bugly官方在插件版本是支持fastlane的，可以看这个文档.

官方文档提供了两个比较重要的扩展一个是上传文件和更新插件. 首先下载两个插件，而如何在fastlane中调用者两个插件呢？我们知道针对官方定义action, 直接通过fastfile文件就修改即可，那如何在fastlane中定义自己的action？

步骤很简单,首先执行:

fastlane new_action

这时命令行会要求你输入自定义action名字，直接以bugly上传文件命名:

upload_app_to_bugly

然后Fastlane会在当前目录的创建一个名为actions文件夹，这个文件夹下默认也会创建一个名为upload_app_to_bugly.rb的ruby文件。而我们要做就是把刚才下载上传插件文件在这个文件进行替换即可.

自定义action成功，改如何调用呢？这是就需要回到fastfile这个文件了。这个文件基本是整个fastlane的核心，我在调试过程花了很多时间浪费它的规则和调试错误解决上。那根据Bugly文档定义在fastfile文件添加如下代码:

而当你点击api说明你发现这个你根本打不开这个页面。这样会导致你根本不知道fastlane这些参数每个参数应该传什么值。不过没关系，经过一番折腾，还是在google上找到关于这篇文档的网页快照，而快照其实就是上个月20号左右的（可能因为最近控制第三方app在国内内测平台分发需要身份认证，Tencent继续这个角度考虑，把接口文档从官方网页入口隐藏了）: