目录
- 一、描述文件
.mobileprovision的再次认识 - 二、使用Xcode增加环境变量为每个打包环境对应一个打包模式
- 三、认识打包命令
- 四、自动化打包时候，参数化环境改变
- 五、打包完后
1、Bugly 符号表上传
2、分支branch与标签tag - 附：描述文件的位置与内容查看
其他文章：
iOS 打包(二)--扫码安装问题的完整排查
前言
首先说明这边不对简单的打包再累诉，因为网上一堆。
这边只对一些平时不容易注意的东西，以及重要的一些点进行说明。
1、要达到的目的/效果：
构建一个Jenkins项目，通过该项目，在输入打包环境后自动打包项目。
2、实现过程中需要了解和操作的东西：
- ①项目中存在多个环境
- ②每个环境都有自己打包时候需要的对应描述文件
一、描述文件.mobileprovision的再次认识
通过以下表格，你将认识到为什么你这个环境需要使用这个描述文件打包，用其他描述文件会有什么问题。
| 类型 | 可安装的设备 | 证书环境(开发/生产) | 推送 | 用于测试环境(测试/预生产/生产) |
|---|---|---|---|---|
| development | 已注册的设备 | 开发环境的证书 | 测试环境的推送 | 测试环境 |
| adhoc | 已注册的设备 | 生产环境的证书 | 和appstore一样的正式环境推送 | 预生产环境 |
| appstore | 所有的设备 | 生产环境的证书 | appstore的推送肯定是要正式环境的 | 生产环境 |
所以在需要考虑收到的推送环境是否正确的情况下，有下面的因果关系：
①测试环境：需要"测试推送"，且可以测试，所以只能使用development;
②预生产环境：需要"正式推送"，且可以测试，即又不能上线，所以只能用adhoc;
③生产环境：需要"正式推送"环境，又需要上线，所以只能用appstore;
二、使用Xcode增加环境变量为每个打包环境对应一个打包模式
首先，请回想你是否有以下这个笨笨的经历，如果有请认真看本节内容。
什么经历呢？即：给测试人员打预发布版本的时候，去Xcode设置里选
xxx_adhoc.mobileprovision，提线上版本的时候，又去Xcode里将它改为xxx_appstore.mobileprovision。
image.png
本操作没什么问题，就是你不觉得如果可以不用改来改去的话会更好吗？
所以，以下说法鉴于你不想每次打包时候去Xcode设置里频繁的根据所需要的环境修改使用的描述文件。不去修改才是正道，如果你习惯了频繁的修改，建议你改掉那个习惯。如果你不想改，请略过本小节。
- 问题/为什么会有此操作：
我们的正常开发环境总有“测试环境”、“预生产环境”、“生产环境”三种环境，而Xcode默认的模式只有DEBUG和RELEASE两种模式。没法让我们一一对应。 - 解决：
在项目中增加一个预发布环境或者再增加其他多个环境。即使用Xcode增加环境变量为每个打包环境对应一个打包模式 - 步骤：
步骤①、点击下方的"+",选择复制Debug模式的栏目
image.png
细心的你，可能会发现我们项目中这里有pod，所以我们需要立即执行一下pod install，让pod自己去生成新的正确的xcconfig文件才能被识别到。否则待会你编译的时候会报错。那么你打包的时候肯定也会报错，一般是报Pod库问题，如下图：
image.png
重新pod install后的图如下：
image.png
步骤②、因为创建的 Prerelease 环境变量，是copy Debug模式下的，所以在Xcode的配置中需要更改预编译的环境变量为PRERELEASE=1,，修改处路径是：TARGETS-->Build Settings-->Preprocessor Macros
image.png
恭喜您，至此，使用Xcode增加环境变量为每个打包环境对应一个打包模式结束。
附：有时候您还想让app根据不同的环境显示不同的应用名，那么您可以：
image.png
打包配置就讲到这，下面讲讲打包命令。这个在自动化打包中常需要用到。建议都熟悉一下。
三、认识打包命令
所使用的打包命令：
# 进入build路径clean一下你的工程
xcodebuild clean -workspace ${TARGET_NAME}.xcworkspace -scheme ${TARGET_NAME} -configuration ${BUILD_TYPE}
# archive导出.xcarchive文件
xcodebuild archive -workspace ${TARGET_NAME}.xcworkspace -scheme ${TARGET_NAME} -archivePath {ARCHIVEPATH}
# 导出ipa包
xcodebuild -exportArchive -archivePath "${ARCHIVEPATH}/${TARGET_NAME}.xcarchive" -exportPath ${EXPORTPATH} -exportOptionsPlist ${EXPORTOPTIONSPLIST}
解释：
${TARGET_NAME} 项目对应targets的名字
${BUILD_TYPE} 打包类型 Debug，Release 等
${archivePath} .xcarchive文件导出目录
${EXPORTPATH} 导出.ipa包的目录
${EXPORTOPTIONSPLIST} exportOptionsPlist文件所在目录，可判断development, ad-hoc等
1、archive
略
2、exportArchive
这个步骤，着重介绍需要使用的exportOptionsPlist文件内容是怎样的，如果要修改要怎么修改
。
所以，我们再对平时手动打包出来的文件目录，重新认识下。细心的你应该发现里面其实已经有一个ExportOptions .plist文件了。
ExportOptions(打包出来的文件目录).png
我们打开该文件查看一下里面的内容。
ExportOptions(打包出来的内容).png
下面我们举个例子
# 一个完整 exportOptionsPlist 文件内容如下：
<?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>compileBitcode</key>
<false/>
<key>method</key>
<string>development</string>
<key>provisioningProfiles</key>
<dict>
<key>com.dvlproad.Demo</key>
<string>com.dvlproad.Demo_development</string>
</dict>
<key>signingCertificate</key>
<string>iPhone Developer</string>
<key>signingStyle</key>
<string>manual</string>
<key>stripSwiftSymbols</key>
<true/>
<key>teamID</key>
<string>你的teamID,不管是什么描述文件,teamID都是一样的</string>
<key>thinning</key>
<string><none></string>
</dict>
</plist>
其中的重点是
<dict>
<key>com.dvlproad.Demo</key>
<string>com.dvlproad.Demo_development</string>
</dict>
上面的key值，是bundleID，肯定是有"."的;
但是下面的string值，是苹果开发者中心下管理描述文件下的Name，而不是下载下来生成的Name，或者自己改的Name。这个点尤其要注意。
描述文件匹配.png
仔细看图，上面的Name自己在创建时候，命名的是有.的，所以我们这边exportOptionsPlist文件中的这个string值，也应该使用有.的(当然如果你取的时候是没有，那这边也应该是没有，反正这边的是要和网站上的Name保持一致的，而不是自己随便重命名的那个)。
四、自动化打包时候，参数化环境改变
参数化环境改变，这是什么鬼意思？
首先，在我们的项目中，肯定有一个变量是控制当前打包的是什么环境的代码吧。一般的代码如下：
#import "STDemoEnvironmentConfig.h"
//@"Product",
//@"PreProduct",
//@"Develop1",
//@"Develop2",
//@"Develop3",
NSString * const STDemoCurrentEnvironment = @"PreProduct"; //取值为上述五个中的一个
如果我们是手动打包，那么每次打包之前都得修改当前打包的环境变量。那自动化打包的时候呢？难不成我们也那么处理，每次打包时候，去修改项目中的代码，让其打包成我们想要的环境。可以，但不要这么做，下面将告诉你为什么?
试想以下两种情况，情况①，什么功能都没修改，只是为了换个打包环境就得去修改代码，然后重新commit，Jenkins再构建，是不是感觉不知不觉多了很多不必要的commit节点。情况②，某个分支下已经是稳定的了，如master，但是测试人员想要不同的环境，你认为为了这个需求，你频繁的去改这个稳定的版本有必要吗？(情况①在这里就显得更容易理解了)。
所以为了避免这些多余的无用功，我们将更改环境的操作，参数化到Jenkins中执行命令的地方，通过命令中所带的参数结合python脚本，让python脚本去把我们项目中的环境变量值改为命令中的。
这里我们把环境改变脚本macro_env.py和要改变的文件单独提取出来测试。
参数化环境改变1.png
可以看到执行命令后，脚本中指定的文件中的CJDemoCurrentEnvironment变量的值被我们改变成了Develop3(原本在项目中的值为Develop1)。
附：脚本小样地址：CJDemo
五、打包完后
1、Bugly 符号表上传
打包完后，为了能快速并准确地定位用户APP发生Crash的代码位置，每次Jenkins构建成功后，需要上传符号表到Bugly，以备后续使用符号表对APP发生Crash的程序堆栈进行解析和还原。详细操作略，请前往官网查看Bugly iOS 符号表配置的配置方法。
2、分支branch与标签tag
①、功能开发时候的分支情况：
功能开发时候的分支情况.png
②、进入发布时候的分支情况：
进入发布时候的分支情况.png
③、发布后开始维护时候的分支情况：
发布后开始维护时候的分支情况.png
附：描述文件的位置与内容查看
描述文件的位置~/Library/MobileDevice/Provisioning Profiles
描述文件的位置.png
在上图中，点击 空格键可以查看描述文件的详细信息，如下图：
描述文件的详细信息.png
