iOS-CI / CD和内部版本号

近一个月（或更长时间），我正在尝试找到处理iOS应用程序内部版本号的最佳方法。 好吧，是的，如果您是唯一处理代码的人，这绝对是容易的。 但是，即使在这种情况下，值得有人照顾也是值得的，为什么不呢？ 另外，在一个正确建立的构建管道中更有意义。 因为找出大多数自动化的东西总是更好的，因为它可以帮助团队中的所有开发人员最少地担心它。

在开始共享我的解决方案之前，我觉得最好退一步并分享我的发现背后的思考过程。 敏捷开发是所有软件开发行业的需求。 在这里，您必须以可装运产品的形式交付一小部分工作。 因此，您完成了一个工作项（用户故事/ Jira票证等），然后将构建版本发布到质量检查中。 这正是您想到的一个步骤，我将如何自动增加内部编号以使每个人的生活变得轻松？
现在，当我说“正确建立的构建管道”时，至少意味着您具有代码的基准主分支，每个开发人员都使用该基线主分支来创建该分支，以进行特定工作项的工作。 一旦完成工作，他们就必须将其分支合并到master分支中，这是QA接收构建的地方。 因此，简单的步骤看起来像-
1.选择要处理的项目并从母版创建分支
2.完成工作并提交+将更改推送到分支
3.合并代码到master分支
4.假设CI / CD版本是从master分支构建的，则您的QA将获得一个新的构建以测试您的工作
等一下…。 我在哪里更新内部版本号？ 到目前为止，这是答案。

在发现阶段，我遇到了以下选项，该选项可以帮助您维护iOS应用程序的内部版本号-

1. 在.plist文件中手动更新您的内部版本号，然后执行commit + push，然后合并代码（是的，我也不太喜欢它。
2. 使用Fastlane的crement_build_number操作（更多信息在这里）
3. 使用XCode agvtool（更多信息在这里）
4. 发布构建阶段脚本（更多信息请点击此处）
5. 所有选项都包含在此处，并在一篇文章中进行了说明

即使拥有了上述所有选项，我仍然想写这篇文章并共享我的解决方案，因为我认为这些参考足以了解增加内部版本号的方法。 但是，仍然缺少如何在CI / CD管道中实际实现这一目标的步骤？ 更重要的是，哪一个最容易且最适合CI / CD？

提出最佳解决方案的方法与开发人员在发布构建版本的过程中执行的实际步骤一致。 因此，步骤是-

1. 设置内部版本号（例如＃1
2. 完成工作项
3. 将代码合并到Master分支
4. 生成（＃1）由管道释放
5. 增加内部版本号（＃2）以用于下一个版本

…..并重复这些步骤。
我之所以认为它与实际步骤一致，是因为首先设置内部版本号，然后开始为其工作，而不是以其他方式进行，这是有意义的。 因为管理内部版本号非常容易，并且更适合实际版本号的实际情况。 意思是，一旦您将1.0版本发布到App Store，此后您要使用的是下一个版本号，而不是1.0版本。 因此，更有意义的是先更新版本号，然后再开始使用它。 这也将有助于跟踪所有可交付成果到正确的版本。 例如，在开发过程中针对特定版本执行的测试用例，等等。 这样，它也是内联的，内部解释也一样。 将内部版本号1发布给质量检查人员进行测试后，随后的工作就是内部版本号2。因此，在成功释放当前内部版本之后，立即增加内部版本号。

为了实现这种方法，我编写了.sh，它做了两件重要的事情-

1. 使用PlistBuddy在info.plist中增加内部版本号
2. 提交+通过CI / CD作业跳过到主分支

然后从master分支成功释放当前版本后执行此操作。
以下是我编写的.sh的代码段-

我希望有很多回显语句和注释，这个.sh是不言自明的。 从项目Info.plist文件更新CFBundleVersion的非常简单的脚本。 我只是使用PlistBuddy为我完成这项工作。 随意使用适合您的任何东西。 但是，重要的一步是当您提交更改并将其推送到存储库时，请确保CI / CD跳过要再次执行的作业。 否则，它将是无休止的一系列工作，并且您将有一系列的发布。 在我的代码中，当我使用Gitlab时，可以通过提交消息“ [ci skip]”轻松实现。 我确信您可以在开发环境中使用任何CI / CD来做到这一点。 这是另外一个较小的原因（仍然是VIMP），我想在将当前版本成功发布给您的质量检查后再这样做。 因此，将此解决方案与您的CI / CD结合使用，步骤如下：

前提条件—将.plist文件中的内部版本号设置为n

1. 开发人员从母版创建分支并开始处理工作项
2. 一旦完成开发，代码将合并到master分支
3. CI / CD首先执行测试作业，以确保代码已正确集成并通过了所有测试
4. 然后，它创建档案并将版本发布给质量检查人员
5. 执行.sh以增加内部版本号并提交+推送至master分支
6. 转到步骤1

然后，这5个步骤将继续……Yeeeeee！

我知道到目前为止，您一定想知道直接将某些内容提交到master分支的可能性是什至可以接受。 但是，您知道版本控制确实允许您配置分支，以便您可以有一些例外。 至少Gitlab确实允许。 因此，您必须弄清楚如何配置master分支，以便它允许我们为特定用户执行一次一次性commit + push操作。 我可以在Gitlab中做到这一点，只允许CI运行程序用户使用此功能，而其他贡献者则不能。

这是我应该在这里回答的重要问题。 我确实尝试了所有可用的选项，但在我的项目环境中无法轻松实现这一目标。 我面临的关键问题是如何维护内部版本号的持久值？ 我确实尝试了所有环境变量，最终将其包含在.plist文件本身中。 Fastlane动作是一个很好的选择，我知道它确实使用PListBuddy，这就是让我了解Fastlane动作的方法，此外，还可以将值保留在master分支中。

增大内部版本号是一个基本要求，它将对在快速开发环境中工作的开发人员有很大的帮助。 到目前为止，此选项是最好的选项之一。 请发表评论，以防您发现实现此目标的任何其他方法。 对于改进我总是可以接受的。 🙂