前言
新到公司的时候发现公司还在使用传统的手动打包测试方式，所以利用自己的闲暇时间开发了一个 iOS 打包平台，经过不断改良，现在公司在使用新一款的打包平台，测试人员可以轻松完成打包工作。我目前也在重新构建平台，发布开源版本。
本系列文章记录完整的 iOS 打包平台搭建过程，文章列表记录如下：
iOS自动打包平台搭建：一 概述
iOS自动打包平台搭建：二 模块（组件）化开发
iOS自动打包平台搭建：三 Master/Slave架构
iOS自动打包平台搭建：四 打包脚本(待完成)
iOS自动打包平台搭建：五 内网OTA(待完成)
iOS自动打包平台搭建：附 安卓打包(待完成)
开端
因为在开发过程中，为测试人员打包是一个耗时、重复操作较多并且容易出错的一个部分，如果能将这一部分由测试人员自助完成，将节省很多时间，而为测试人员提供自助打包的服务，就需要搭建一个简(sha)单(gua)易(dou)用(hui)的平台来提供支持。
Jenkins 是业界使用最多，评价最高的开源服务，但是因为使用 Jenkins 需要进行二次开发才能提供一个很友好的操作界面，并且很难自定义化我们的需求。而二次开发对于我们目前的情况而言并不是很合适。
使用 shell 开发可能会遇到各种难题，但相对于 Jenkins ，得到的产品更容易被我们掌控，而且我们的需求也仅限于持续打包和模块集成， shell 很轻松能应对这些。
下面先简要介绍一下第一版的一些情况及新版的一些展示，我们后续的文章将围绕新版展开。
第一版
打包流程
打包的想法来源于 xcode 自身提供的命令集，市面所有的 iOS 打包的底层实现全部都是依赖这些命令集，仅仅有这些命令是不够的，即使每次使用命令没有问题，但这些命令依赖于 xcode ，也就是说只能在 Mac 系统下进行（Jenkins为什么可以？它并不可以，它需要我们设置代理机器来执行操作，而这个代理机器只能是 Mac）。
到这里，我们需要一个 Mac 来做为这些脚本的暖床，果断选择自己的电脑，不过用命令行执行我电脑中的命令让我毫无思路，开启服务，apache + PHP 或者 nodejs，第一版中我选择了前者。
打包用到的脚本为 1.sh、2.sh、3.sh， 直接丢到一个 PHP 函数中执行，看上去并没有问题，但是好像并不能看到当前的进度，页面会一直处于加载页面，直到脚本结束，这对于一个需要很长时间的操作用户体验很差啊，索性再将脚本分开，每一个 PHP 函数执行一个脚本，并且对结果做处理，然后在页面使用 ajax 请求 触发 PHP 函数，将每次的结果更新到界面，再根据结果处理是否继续向下执行，如果成功生成一条记录写入数据库，第一版就这样完成了。
第一版开发中受限于时间问题没有深入了解 PHP 的一些功能，所以使用了 js 一步一步驱动打包的进展，而这种方式的弊端也是显而易见的，无法在页面关闭的情况下完成打包操作，而且架设在我的电脑上，造成对我的电脑的严重依赖，如果有一天我请假，那么整个打包流程无法进行。
新一版的想法是回归最开始的想法，所有脚本丢到一个 PHP 函数中，通过 ajax 请求执行函数，将执行的结果实时写入数据库，并且检测到一旦正在打包，开启轮询的方式获取当前进度。或许 redis 会是更好的选择，但是对于我们没有那么高的需求，检测到打包结束，关闭轮询。
安装包分发
有一种方式可以让用户下载安装包，可能你更多的了解是很多分发平台在使用这种技术，它叫 OTA ，是苹果在 iOS 4 发布的一种技术，可以让测试人员通过非商店方式安装应用，它的协议头是 itms-services ，从最开始的只有 safari 到现在大部分浏览器都支持（微信不支持），我们通过如下 HTML 就可以安装对应的应用：
<a title="iPhone" href=“itms-services://?action=download-manifest&url=https://192.168.0.1/installIPA.plist">
Iphone Download</a>
其中的 plist 文件是对应用的描述文件，其中包含应用名、版本、包地址等信息，具体展示如下：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>https://ipack.pub/Packages/installer/1.2.0/1.2.7.ipa</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>pub.ipack.installer</string>
<key>bundle-version</key>
<string>1.2.0</string>
<key>kind</key>
<string>software</string>
<key>title</key>
<string>iPack</string>
</dict>
</dict>
</array>
</dict>
</plist>
我们将安装包存放在本地，然后配置好 plist 文件，在网页中配置好链接的按钮就可以了，为了方便我们开发了一款专门用来安装的 APP，因为苹果在介绍中有说过，可以通过网页、邮件、APP 等方式让用户安装 APP，能有多少员工会在手机端接受公司邮件呢？ 显然邮件不在我们考虑范围内。而提到网页的形式，如果让用户手动输入 url，也不是明智的方案，如果简化呢？二维码，这是一项伟大的发明，而我们公司使用钉钉交流，钉钉提供的机器人加上二维码简直就是上天安排好的一次约会，果断用起来。
遇到的问题
shell 与 PHP 的交互是一个很蛋疼的问题， shell 获取 PHP 的参数容易，但是获取 shell 执行的结果还真有些难度，打包的脚本会输出很多信息，怎么才能知道最后执行的结果呢，一旦判断错了，会影响后续的操作，可能明明成功了我们误判为失败了。。。
因为第一次使用脚本做这样的事儿，所以在脚本的调试过程中，也出现了很多事故，现在的平台也无法保证不出现问题，但至少经过了上百次打包的洗礼。
部分设备无法安装，良思许久终不得解，苹果官网上也只见有人发问，不见官方答复，不得不将 plist 文件由本地存放移动到 github 上，后经同事点醒，找到问题所在，之后又移回本地。
展示
新版
展示
总结
本文主要针对第一版打包思路进行介绍，并且对我们后续要展开介绍的新版进行简要的展示，如发现错误或有任何疑问欢迎留言交流。
更多内容请访问 http://blog.makaiwen.com
