iOS自动打包并发布脚本

本文最终实现的是使用脚本打 Ad-hoc 包，并发布测试，当然稍微修改一下脚本参数就可以打其他类型的 ipa 包了。另外该脚本还实现了将生成的 ipa 包上传至蒲公英进行测试分发。文中内容包括:

1. xcodebuild 简介

2. 使用xcodebuild和xcrun打包签名

3. 将打包过程脚本化

xcodebuild 简介

xcodebuild 是苹果提供的打包项目或者工程的命令，了解该命令最好的方式就是使用 man xcodebuild 查看其 man page. 尽管是英文，一定要老老实实的读一遍就好了。

DESCRIPTION
xcodebuild builds one or more targets contained in an Xcode project, or builds a scheme contained in an Xcode workspace or Xcode project.

Usage

To build an Xcode project, run xcodebuild from the directory containing your project (i.e. the directory containing the name.xcodeproj package). If you have multiple projects in the this directory you will need to use -project to indicate which project should be built. By default, xcodebuild builds the first target listed in the project, with the default build configuration. The order of the targets is a property of the project and is the same for all users of the project.
To build an Xcode workspace, you must pass both the -workspace and -scheme options to define the build. The parameters of the scheme will control which targets are built and how they are built, although you may pass other options to xcodebuild to override some parameters of the scheme.
There are also several options that display info about the installed version of Xcode or about projects or workspaces in the local directory, but which do not initiate an action. These include -list, -showBuildSettings, -showsdks, -usage, and -version.

总结一下:

1. 需要在包含 name.xcodeproj 的目录下执行 xcodebuild 命令，且如果该目录下有多个 projects，那么需要使用 -project 指定需要 build 的项目。

2. 在不指定 build 的 target 的时候，默认情况下会 build project 下的第一个 target

3. 当 build workspace 时，需要同时指定 -workspace 和 -scheme 参数，scheme 参数控制了哪些 targets 会被 build 以及以怎样的方式 build。

4. 有一些诸如 -list, -showBuildSettings, -showsdks 的参数可以查看项目或者工程的信息，不会对 build action 造成任何影响，放心使用。

那么，xcodebuild 究竟如何使用呢？ 继续看文档:

挑几个我常用的形式介绍一下，较长的使用方式以序列号代替:

• xcodebuild -showsdks: 列出 Xcode 所有可用的 SDKs

• xcodebuild -showBuildSettings: 上述序号6的使用方式，查看当前工程 build setting 的配置参数，Xcode 详细的 build setting 参数参考官方文档 Xcode Build Setting Reference ， 已有的配置参数可以在终端中以 buildsetting=value 的形式进行覆盖重新设置.

• xcodebuild -list: 上述序号7的使用方式，查看 project 中的 targets 和 configurations，或者 workspace 中 schemes, 输出如下:

Information about project "NavTabBar":
    Targets:
        NavTabBar
        NavTabBarTests
        NavTabBarUITests

    Build Configurations:
        Debug
        Release
        Ad-hoc

    If no build configuration is specified and -scheme is not passed then "Release" is used.

    Schemes:
        NavTabBar

• xcodebuild [-project name.xcodeproj] [[-target targetname] ... | -alltargets] build: 上述序号1的使用方式，会 build 指定 project，其中 -target 和 -configuration 参数可以使用 xcodebuild -list 获得，-sdk 参数可由 xcodebuild -showsdks 获得，[buildsetting=value ...] 用来覆盖工程中已有的配置。可覆盖的参数参考官方文档 Xcode Build Setting Reference , action... 的可用选项如下, 打包的话当然用 build，这也是默认选项。

  • build

    Build the target in the build root (SYMROOT). This is the default action, and is used if no action is given.

  • analyze

    Build and analyze a target or scheme from the build root (SYMROOT). This requires specifying a scheme.

  • archive

    Archive a scheme from the build root (SYMROOT). This requires specifying a scheme.

  • test

    Test a scheme from the build root (SYMROOT). This requires specifying a scheme and optionally a destination.

  • installsrc

    Copy the source of the project to the source root (SRCROOT).

  • install

    Build the target and install it into the target's installation directory in the distribution root (DSTROOT).

  • clean

    Remove build products and intermediate files from the build root (SYMROOT).

• xcodebuild -workspace name.xcworkspace -scheme schemename build: 上述序号3的使用方式，build 指定 workspace，当我们使用 CocoaPods 来管理第三方库时，会生成 xcworkspace 文件，这样就会用到这种打包方式.

使用xcodebuild和xcrun打包签名

开始之前，可以新建一个测试工程 TestImg 来练习打包，在使用终端命令打包之前，请确认该工程也可以直接使用 Xcode 真机调试成功。

然后，打开终端，进入包含 TestImg.xcodeproj 的目录下，运行以下命令:

xcodebuild -project TestImg.xcodeproj -target TestImg -configuration Release

如果 build 成功，会看到 ** BUILD SUCCEEDED ** 字样，且在终端会打印出这次 build 的签名信息，如下:

Signing Identity: "iPhone Developer: xxx(59xxxxxx)" Provisioning Profile: "iOS Team Provisioning Profile: *"

且在该目录下会多出一个 build 目录，该目录下有 Release-iphoneos 和 TestImg.build 文件，根据我们 build -configuration 配置的参数不同，Release-iphoneos 的文件名会不同。

在 Release-iphoneos 文件夹下，有我们需要的TestImg.app文件，但是要安装到真机上，我们需要将该文件导出为ipa文件，这里使用 xcrun 命令。

xcrun -sdk iphoneos -v PackageApplication ./build/Release-iphoneos/TestImg.app -o ~/Desktop/TestImg.ipa

这里又冒出一个 PackageApplication, 我刚开始也不知道这是个什么玩意儿，万能的google告诉我，这是 Xcode 包里自带的工具，使用 xcrun -sdk iphoneos -v PackageApplication -help 查看帮助信息.

Usage: PackageApplication [-s signature] application [-o output_directory] [-verbose] [-plugin plugin] || -man || -help
Options:
[-s signature]: certificate name to resign application before packaging [-o output_directory]: specify output filename [-plugin plugin]: specify an optional plugin -help: brief help message -man: full documentation -v[erbose]: provide details during operation

如果执行成功，则会在你的桌面生成 TestImg.ipa 文件，这样就可以发布测试了。如果你遇到以下警告信息:

Warning: --resource-rules has been deprecated in Mac OS X >= 10.10! ResourceRules.plist: cannot read resources

请参考 stackoverflow 这个回答

将打包过程脚本化

工作中，特别是所做项目进入测试阶段，肯定会经常打 Ad-hoc 包给测试人员进行测试，但是我们肯定不想每次进行打包的时候都要进行一些工程的设置修改，以及一系列的 next 按钮点击操作，现在就让这些操作都交给脚本化吧。

1. 脚本化中使用如下的命令打包:

xcodebuild -project name.xcodeproj -target targetname -configuration Release -sdk iphoneos build CODE_SIGN_IDENTITY="$(CODE_SIGN_IDENTITY)" PROVISIONING_PROFILE="$(PROVISIONING_PROFILE)"

或者

xcodebuild -workspace name.xcworkspace -scheme schemename -configuration Release -sdk iphoneos build CODE_SIGN_IDENTITY="$(CODE_SIGN_IDENTITY)" PROVISIONING_PROFILE="$(PROVISIONING_PROFILE)"

2. 然后使用 xcrun 生成 ipa 文件:

`xcrun -sdk iphoneos -v PackageApplication ./build/Release-iphoneos/$(target|scheme).app"

3. 清除 build 过程中产生的中间文件

4. 结合蒲公英分发平台，将 ipa 文件上传至蒲公英分发平台，同时在终端会打印上传结果以及上传应用后该应用的 URL。蒲公英分发平台能够方便地将 ipa 文件尽快分发到测试人员，该平台有开放 API，可避免人工上传。

该脚本的使用可使用 python autobuild.py -h 查看，与 xcodebuild 的使用相似:

Usage: autobuild.py [options]
Options: -h, --help: show this help message and exit -w name.xcworkspace, --workspace=name.xcworkspace: Build the workspace name.xcworkspace. -p name.xcodeproj, --project=name.xcodeproj: Build the project name.xcodeproj. -s schemename, --scheme=schemename: Build the scheme specified by schemename. Required if building a workspace. -t targetname, --target=targetname: Build the target specified by targetname. Required if building a project. -o output_filename, --output=output_filename: specify output filename

在脚本顶部，有几个全局变量，根据自己的项目情况修改。

CODE_SIGN_IDENTITY = "iPhone Distribution: companyname (9xxxxxxx9A)"PROVISIONING_PROFILE = "xxxxx-xxxx-xxx-xxxx-xxxxxxxxx"CONFIGURATION = "Release"SDK = "iphoneos"USER_KEY = "15d6xxxxxxxxxxxxxxxxxx"API_KEY = "efxxxxxxxxxxxxxxxxxxxx"

其中，CODE_SIGN_IDENTITY 为开发者证书标识，可以在 Keychain Access -> Certificates -> 选中证书右键弹出菜单 -> Get Info -> Common Name 获取，类似 iPhone Distribution: Company name Co. Ltd (xxxxxxxx9A), 包括括号内的内容。

PROVISIONING_PROFILE: 这个是 mobileprovision 文件的 identifier，获取方式：

Xcode -> Preferences -> 选中申请开发者证书的 Apple ID -> 选中开发者证书 -> View Details... -> 根据 Provisioning Profiles 的名字选中打包所需的 mobileprovision 文件 -> 右键菜单 -> Show in Finder -> 找到该文件后，除了该文件后缀名的字符串就是 PROVISIONING_PROFILE 字段的内容。

当然也可以使用脚本获取, 此处参考 命令行获取mobileprovision文件的UUID :

#!/bin/bashif [ $# -ne 1 ]then
  echo "Usage: getmobileuuid the-mobileprovision-file-path"
  exit 1fimobileprovision_uuid=`/usr/libexec/PlistBuddy -c "Print UUID" /dev/stdin <<< $(/usr/bin/security cms -D -i $1)`echo "UUID is:"echo ${mobileprovision_uuid}

USER_KEY, API_KEY: 是蒲公英开放 API 的密钥。

将autobuild.py脚本放在你项目的根目录下，进入根目录，如下使用：

./autobuild.py -w yourname.xcworkspace -s schemename -o ~/Desktop/yourname.ipa

或者

./autobuild.py -p yourname.xcodeproj -t targetname -o ~/Desktop/yourname.ipa

该脚本可在 github 查看，如有任何问题，请留言回复。

常见问题:

1. 找不到request module.

import requests
ImportError: No module named requests

找不到request module，参考 stackoverflow , 使用 $ sudo pip install requests或者sudo easy_install -U requests;

2. 如果使用了上传蒲公英，且安装需要密码，请打开脚本，搜一下脚本里的password，将其值设置为空。

========== update 2016-12-28 ==========

github上脚本进行更新：

1. 使用xcodebuild -exportArchive替换PackageApplication进行打包.

2. 解析传入参数使用argparse替换OptionParser.

3. 去掉对PROVISIONING_PROFILE和CODE_SIGN_IDENTITY的配置，请使用Xcode8的自动证书管理。

4. 新增exportOptions.plist文件，用于设置导出ipa文件的参数，该文件中的可配置参数可使用xcodebuild --help查看。

5. 脚本传入参数去掉--target和--output，ipa文件默认会存放在Desktop创建诸如{scheme}{2016-12-28_08-08-10}格式的文件夹中。

假如你的项目目录如下所示：

|____AOP
| |____AppDelegate.h
| |____AppDelegate.m
| |____Base.lproj
| | |____LaunchScreen.xib| | |____Main.storyboard
| |____Images.xcassets
| |____Info.plist
| |____main.m
| |____ViewController.h
| |____ViewController.m
|____AOP.xcodeproj|____autobuild
| |____autobuild.py
| |____exportOptions.plist

先进入autobuild目录，使用脚本打包的命令如下:

python autobuild.py -p ../AOP.xcodeproj -s AOP

脚本执行完毕，若成功，则会在桌面生成ipa文件。

若是打包xcworkspace项目，则打包命令格式如下所示:

python autobuild.py -w ../yourworkspace.xcworkspace -s yourscheme

exportOptions.plist文件中的可选配置参数如下:

compileBitcode : Bool  For non-App Store exports, should Xcode re-compile the app from bitcode? Defaults to YES.

embedOnDemandResourcesAssetPacksInBundle : Bool  For non-App Store exports, if the app uses On Demand Resources and this is YES, asset   
  packs are embedded in the app bundle so that the app can be tested without a server to   
  host asset packs. Defaults to YES unless onDemandResourcesAssetPacksBaseURL is specified.

iCloudContainerEnvironment  For non-App Store exports, if the app is using CloudKit, this configures the   
  "com.apple.developer.icloud-container-environment" entitlement. Available options:   
  Development and Production. Defaults to Development.

manifest : Dictionary  For non-App Store exports, users can download your app over the web by opening your   
  distribution manifest file in a web browser. To generate a distribution manifest, the   
  value of this key should be a dictionary with three sub-keys: appURL, displayImageURL,   
  fullSizeImageURL. The additional sub-key assetPackManifestURL is required when using on demand resources.

method : String

  Describes how Xcode should export the archive. Available options: app-store, ad-hoc,   
  package, enterprise, development, and developer-id. The list of options varies based on   
  the type of archive. Defaults to development.

onDemandResourcesAssetPacksBaseURL : String  For non-App Store exports, if the app uses On Demand Resources and   
  embedOnDemandResourcesAssetPacksInBundle isn't YES, this should be a base URL specifying   
  where asset packs are going to be hosted. This configures the app to download asset   
  packs from the specified URL.

teamID : String

  The Developer Portal team to use for this export. Defaults to the team used to build the archive.

thinning : String

  For non-App Store exports, should Xcode thin the package for one or more device   
  variants? Available options:  (Xcode produces a non-thinned universal app),   
   (Xcode produces a universal app and all available thinned   
  variants), or a model identifier for a specific device (e.g. "iPhone7,1"). Defaults to .

uploadBitcode : Bool

  For App Store exports, should the package include bitcode? Defaults to YES.

uploadSymbols : Bool

  For App Store exports, should the package include symbols? Defaults to YES.