版本构建iOS 进阶iOS开发

[iOS-Release] 自动修改构建号

2017-01-05  本文已影响471人  水止云起

Version 和 Build 的概念

在应用 target 的 General 面板中有两个设置项,分别为 Version 和 Build,它们实际对应了 Info.plist 文件中的两项:

这两项都是用来标识应用的版本号。区别在于,Version 标识应用程序的发布版本号,格式应采用语义化的版本号,而 Build 则用来标识产品构建时的内部版本号(包括发布与未发布的),简单的可使用递增的整数表示。Version 是对外向用户显示说明的,而 Build 是开发内部用来唯一确定一次分发版本的。这里是官方介绍:Setting the Version Number and Build String

Version 一般在应用发布或更新时由产品部门确定,在了解清楚两者的不同后,我们主要关注开发中使用的构建号。Build 可以方便我们清晰的追踪构建的版本,比如在发布前,随着测试与修复 bug 的进行,我们需要不断的给测试人员提供新的版本,这时,通过构建版本号就可以清晰的标识具体的测试版本。或者我们可以通过构建版本号来区分收集的 Crash 信息。

构建版本号的自动修改

通过上述对 Build 的介绍我们知道,构建版本号是随着内部分发版本而需要不断更新的。为了提高效率,我们可以让构建版本号在产品构建过程中自动更新,方法是在应用 target 的 Build Phases 面板中添加用于更改构建版本号的自定义脚本。

需要将 Run Script 步骤拖放到 Copy Bundle Resources 步骤之前,这样可以保证 CFBundleVersion 的值与最新一次的构建版本一致,否则 CFBundleVersion 的值为下一次的构建版本。

修改构建版本号的脚本

通过 shell 脚本,我们可以实现不同格式的构建版本号的自动修改。

递增整数

最简单的构建版本号的设置就是,随着每一次的构建,整数版本号递增1。第一种方式是使用苹果公司提供的命令agvtool,这里是该命令的介绍:Automating Version and Build Numbers Using agvtool。在脚本中只需要简单的执行以下命令:

agvtool next-version -all

另一种方式就是获取当前的构建版本号,加1后再重新设置构建版本号:

build_number=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" ${INFOPLIST_FILE})
build_number=$((${build_number} + 1))
/usr/libexec/PlistBuddy -c "Set CFBundleVersion ${build_number}" ${INFOPLIST_FILE}

构建号与版本号的拼接:

build_number=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" ${INFOPLIST_FILE})
version_number=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" ${INFOPLIST_FILE})
build_number=$(echo $build_number|sed 's/.*\./''/')
build_number=$((${build_number} + 1))
/usr/libexec/PlistBuddy -c "Set CFBundleVersion ${version_number}.${build_number}" ${INFOPLIST_FILE}
基于 Git

我们也可以通过 Git 的提交信息来标识构建版本,如以提交次数作为构建版本:

build_number=$(git rev-list HEAD | wc -l | awk '{print $1}')
/usr/libexec/PlistBuddy -c "Set CFBundleVersion ${build_number}" ${INFOPLIST_FILE}

或者以最新提交的 ID 作为构建版本号:

build_number=$(git rev-parse --short HEAD)
/usr/libexec/PlistBuddy -c "Set CFBundleVersion ${build_number}" ${INFOPLIST_FILE}
基于日期时间

还可以用不同格式化的当前时间作为构建版本号

build_number=$(date +%Y%m%d)
/usr/libexec/PlistBuddy -c "Set CFBundleVersion ${build_number}" ${INFOPLIST_FILE}

自定义脚本

上述各种格式的脚本都可以进行修改以符合自己的格式需求,而且可以对各种格式信息进行组合。最终,我选择的格式为日期+当天构建次数+环境标识,如:201701051R。这种格式相比单纯的构建次数递增,除了达到唯一确定标识一次构建版本的作用外,还提供了更有意义的信息,比如测试人员可以很容易的根据环境标识选择要测试环境对应的构建版本。以下是我使用的脚本:

if [ ${CONFIGURATION} != "Develop" ]
then

last_build_version=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" ${INFOPLIST_FILE})
last_build_date=${last_build_version:0:8}
#因为最后一位为环境标识位,所以构建次数通过截取第九位到倒数第二位的字符确定。
last_build_number_length=$((${#last_build_version} - 9))
last_build_number=${last_build_version:8:$last_build_number_length}
current_date=$(date +%Y%m%d)

if [ ${last_build_date} = ${current_date} ]; then
    build_number=$(expr ${last_build_number} + 1)
else
    build_number="1"
fi

build_number=$(printf "%02d" ${build_number})

if [ ${CONFIGURATION} = "Debug" ]; then
    environment_flag="S"
elif [ ${CONFIGURATION} = "Release" ]; then
    environment_flag="P"
fi

build_version=${current_date}${build_number}${environment_flag}
/usr/libexec/PlistBuddy -c "Set CFBundleVersion ${build_version}" ${INFOPLIST_FILE}

fi

脚本中最外层有一个判断,作用是过滤所有开发调试中的构建过程。只有真正构建一个要分发出去的产品时,才应计入构建版本号中。而另一种方式则是勾选 Run Script 面板中的 Run Script only when installing 选项,勾选该选项后,脚本在平常调试构建过程中并不会执行,而只在 Archive 的构建过程时才会执行,这样也就不需要添加外层的判断了。

对于脚本中使用到的一些环境变量,如 CONFIGURATION,INFOPLIST_FILE 等,如果你勾选了 Run Script 面板中的 Show environment variables in build log 选项,则可以在构建过程的 log 中看到所有添加的环境变量,主要是当前 Build Settings 中的值。

上一篇下一篇

猜你喜欢

热点阅读