#
持续交付iOS应用程序对于在竞争激烈的市场中保持相关性至关重要。拥有基础设施的公司一旦开发就能够向客户发布功能，赢得了公司的竞争，从本地Xcode的某些人手动发布。在持续交付模式中，我们应该不断将iOS版本上传到iTunes Connect或TestFlight，以获得发布中涉及的所有技术和非技术人员的反馈。只要我们有适当的构建和版本化过程，将构建上传到iTunes Connects并没有什么坏处。在这篇文章中，我们将看到什么是在Continuous Delivery管道中自动增加构建号的最佳技术。
释放火车
在我们进入iOS应用程序的自动内部版本号之前，我们将看到版本号，内部版本号和版本列表在向iOS应用程序商店提交iOS应用程序时是如何工作的。Apple对 每个iOS开发人员都应该了解的版本号和内部版本号有很好的文档。版本号和内部版本号的组合唯一标识应用的App Store提交。
- 版本号
iOS应用程序的版本号与先前版本的应用程序不同。我们需要为新的应用版本创建单独的版本号。它类似于使用语义版本化在Github上创建发行版。法律的版本号是 1.0 ，1.1.1等，但你不能结合字母和数字，像ABC 。123 这将是非法版本号。版本号不能重新使用，因此您必须事先决定主要和次要版本。新的版本号值必须大于以前使用的值，并且应该随后递增。可以在 带有密钥的iOS应用程序的Info .plist文件中 找到当前版本号的值 CFBundleShortVersionString 或在上传的iOS应用程序的情况下，我们可以检查iTunes Connect来找出版本号。我们可以使用Apple的 agvtool 命令行工具检查当前版本号
Shell
| 1 | $ xcrun agvtool what-marketing-version |
|---|---|
- 内部编号
可以为特定版本号上载多个版本，但是，为特定版本号上载的版本号应该是唯一的并且按递增顺序。版本号的值可以重复用于不同的版本号。可以在 具有CFBundleVersion 密钥的iOS应用程序的Info .plist文件中 找到当前内部版本号的值 。我们可以使用Apple的agvtool 命令行工具检查当前版本号
Shell
| 1 | $ xcrun agvtool what-version |
|---|---|
- 释放火车
为特定版本提交的构建数量形成该特定版本的Release Train。在发行版中，内部版本号是增量顺序且唯一的。火车可以具有特定功能的多个版本，如果需要，我们可以将任何版本升级到App Store。简而言之，发布系列是持续交付的基础。
在发行版中建立增量
在发布版本中增加版本号的策略很少。我们会看到他们中的每一个人，并讨论哪一个对发布火车来说很棒。
Apple拥有原生命令行工具来处理版本和编号。我们可以启用 agvtool 并编写脚本以在特定发布版本中自动增加内部版本号。为了启用agvtool，我们需要确保我们已经 在目标构建设置中正确设置了 当前项目版本 和 版本控制系统属性。选择目标版本设置并搜索“版本控制”。现在，将当前项目版本设置 为1 ，并将版本控制系统值选择 为“Apple Generic”。 接下来要验证的是确保 Info 选项卡具有Bundle版本和Bundle版本字符串，对于新项目，短值可能设置为1。
我们可以使用以下命令将内部版本号增加到下一个内部版本号
Shell
| 1 | $ xcrun agvtool next-version -all |
|---|---|
当我们从CI服务器执行此操作时，它会更新Info.plist文件，一旦构建成功上载，我们需要将这些文件提交回源控件。这是该技术的缺点之一。我们必须经常从CI服务器更新源代码管理。
我们可以使用PlistBuddy工具实现构建号的版本修改，该工具用于动态更新plist文件。我们可以轻松编写脚本。
Shell
| 123 | buildNumber=$(/usr/libexec/PlistBuddy -c “Print CFBundleVersion” “$PRODUCT_SETTINGS_PATH”)buildNumber=$(($buildNumber + 1))/usr/libexec/PlistBuddy -c “Set :CFBundleVersion $buildNumber” “$PRODUCT_SETTINGS_PATH” |
|---|---|
这会将内部版本号增加一个。同样，这会更新Info.plist文件，我们需要在成功上载构建后将其提交回源控件
还有其他一些第三方工具，如 Fastlane ，也可以做同样的事情。Fastlane有增加版本号和版本号的动作。该 increment_version_number 动作可以用来增加它有各种选项，以及版本号。我们可以碰到主要版本或次要版本，我们也可以指定版本号。
Shell
| 123 | increment_version_number( bump_type: “major” ) |
|---|---|
该 increment_build_number 动作可以用于更新版本号值。
Shell
| 123 | increment_build_number( build_number: “5” ) |
|---|---|
有很多选项来管理版本号和版本号，但是这些操作也使用了agvtool。在这种情况下，我们必须使用另一个Fastlane操作来提交版本缓冲，以将新版本提交回来自CI服务器的源代码控制。
Ruby
| 1234 | commit_version_bump( message: “Version Bump”, xcodeproj: “./path/to/MyProject.xcodeproj”, ) |
|---|---|
同样，这种方法需要与Github集成，并且持续集成服务器的源代码控制频繁更改。
还有一种方法不需要从Continuous Integration服务器提交版本号。这种技术使用基于某些幻数的Scripted构建，并相应地增加构建编号。你可以在这里阅读更多关于这个技巧
这种技术非常有效，我们只需要添加另一个执行此脚本的Run Script构建阶段。
Shell
| 1234567891011121314 | #!/bin/bash # update_build_number.sh# Usage: update_build_number.sh [branch]# Run this script after the ‘Copy Bundle Resources’ build phase# Ref: http://tgoode.com/2014/06/05/sensible-way-increment-bundle-version-cfbundleversion-xcode/ branch=${1:-‘master’}buildNumber=$(expr $(git rev-list $branch –count) - $(git rev-list HEAD..$branch –count))echo “Updating build number to $buildNumber using branch ‘$branch’.”/usr/libexec/PlistBuddy -c “Set :CFBundleVersion $buildNumber” “${TARGET_BUILD_DIR}/${INFOPLIST_PATH}”if [ -f “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}.dSYM/Contents/Info.plist” ]; then /usr/libexec/PlistBuddy -c “Set :CFBundleVersion $buildNumber” “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}.dSYM/Contents/Info.plist”fi |
|---|---|
无论什么时候我们上传新版本，这都会给出新的版本号 使用这种方法的好处是我们不必从Continuous Integration服务器提交版本缓冲。
使用哪种技术？
截至目前，我们已经看到了四种不同的技术来增加iOS版本系列中的内部版本号。选择适合您iOS应用的技术有点棘手。这是因为它取决于在团队中工作的iOS开发人员的技能。如果脚本和管理得当，所有技巧都可以运行。但是，我更喜欢使用脚本化构建的最后一个，因为它不涉及从Continuous Integration服务器更改源代码控制存储库。
结论
在iOS持续交付管道中，自动化版本和内部版本号可以节省大量时间，并且可以轻松地使用上述构建增量技术轻松组织版本系列。您使用哪种策略进行构建增量？如果我错过任何事情，请告诉我。
