iOS 打包(一)--精简总结(证书、自动化、持续集成等)(精简)

一、描述文件.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增加环境变量为每个打包环境对应一个打包模式结束。

分割图1.jpg

附：有时候您还想让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.jpg

五、打包完后

1、Bugly 符号表上传

打包完后，为了能快速并准确地定位用户APP发生Crash的代码位置，每次Jenkins构建成功后，需要上传符号表到Bugly，以备后续使用符号表对APP发生Crash的程序堆栈进行解析和还原。详细操作略，请前往官网查看Bugly iOS 符号表配置的配置方法。

2、分支branch与标签tag

①、功能开发时候的分支情况：

功能开发时候的分支情况.png

②、进入发布时候的分支情况：

进入发布时候的分支情况.png

③、发布后开始维护时候的分支情况：

发布后开始维护时候的分支情况.png

附：描述文件的位置与内容查看

描述文件的位置~/Library/MobileDevice/Provisioning Profiles

描述文件的位置.png

在上图中，点击空格键可以查看描述文件的详细信息，如下图：

描述文件的详细信息.png