Tag: 部署管道
iOS-CI / CD和内部版本号
近一个月（或更长时间），我正在尝试找到处理iOS应用程序内部版本号的最佳方法。 好吧，是的，如果您是唯一处理代码的人，这绝对是容易的。 但是，即使在这种情况下，值得有人照顾也是值得的，为什么不呢？ 另外，在一个正确建立的构建管道中更有意义。 因为找出大多数自动化的东西总是更好的，因为它可以帮助团队中的所有开发人员最少地担心它。 在开始共享我的解决方案之前，我觉得最好退一步并分享我的发现背后的思考过程。 敏捷开发是所有软件开发行业的需求。 在这里，您必须以可装运产品的形式交付一小部分工作。 因此，您完成了一个工作项（用户故事/ Jira票证等），然后将构建版本发布到质量检查中。 这正是您想到的一个步骤，我将如何自动增加内部编号以使每个人的生活变得轻松？ 现在，当我说“正确建立的构建管道”时，至少意味着您具有代码的基准主分支，每个开发人员都使用该基线主分支来创建该分支，以进行特定工作项的工作。 一旦完成工作，他们就必须将其分支合并到master分支中，这是QA接收构建的地方。 因此，简单的步骤看起来像- 1.选择要处理的项目并从母版创建分支 2.完成工作并提交+将更改推送到分支 3.合并代码到master分支 4.假设CI / CD版本是从master分支构建的，则您的QA将获得一个新的构建以测试您的工作 等一下…。 我在哪里更新内部版本号？ 到目前为止，这是答案。 在发现阶段，我遇到了以下选项，该选项可以帮助您维护iOS应用程序的内部版本号- 在.plist文件中手动更新您的内部版本号，然后执行commit + push，然后合并代码（是的，我也不太喜欢它。 使用Fastlane的crement_build_number操作（更多信息在这里） 使用XCode agvtool（更多信息在这里） 发布构建阶段脚本（更多信息请点击此处） 所有选项都包含在此处，并在一篇文章中进行了说明 即使拥有了上述所有选项，我仍然想写这篇文章并共享我的解决方案，因为我认为这些参考足以了解增加内部版本号的方法。 但是，仍然缺少如何在CI / CD管道中实际实现这一目标的步骤？ 更重要的是，哪一个最容易且最适合CI / CD？ 提出最佳解决方案的方法与开发人员在发布构建版本的过程中执行的实际步骤一致。 因此，步骤是- 设置内部版本号（例如＃1 完成工作项 将代码合并到Master分支 生成（＃1）由管道释放 增加内部版本号（＃2）以用于下一个版本 …..并重复这些步骤。 我之所以认为它与实际步骤一致，是因为首先设置内部版本号，然后开始为其工作，而不是以其他方式进行，这是有意义的。 因为管理内部版本号非常容易，并且更适合实际版本号的实际情况。 意思是，一旦您将1.0版本发布到App Store，此后您要使用的是下一个版本号，而不是1.0版本。 因此，更有意义的是先更新版本号，然后再开始使用它。 这也将有助于跟踪所有可交付成果到正确的版本。 例如，在开发过程中针对特定版本执行的测试用例，等等。 这样，它也是内联的，内部解释也一样。 […]
所以我想部署一个二进制文件
你不可以过去！ 到目前为止的故事 最初，宇宙是被创造出来的。 这使很多人非常生气，被普遍认为是一个坏举动……开玩笑！ 这一切都是从最近开始的。 确切地说，在星期四晚上6:42 pm。 我有一些带宽，因此决定解决我团队长期以来遇到的麻烦 -使用CircleCI环境进行手动部署。 直到星期四晚上，我们对于使用（请参阅：构建和维护）不同的工具或利用完全独立的服务来达成最终目标的想法不尽相同。 理想情况下，我们应该能够利用CircleCI API并以此方式触发作业。 不幸的是，截至撰写本文时， 如果您正在使用CircleCI 2.1和Workflows ，则目前无法 （通过API） 触发单个作业 。 但是，我们手头有一个更简单的解决方案，这对我们来说是未知的。 工作流程 根据CircleCI的文档，为了通过更快的反馈，更短的重新运行和更有效的资源利用来提高软件开发的速度，我们应该配置工作流 。 我们已经使用了它们，它们为我们服务很好。 但是有一个我们不知道的配置密钥- type: approval 。 围绕它的文档措辞混乱，难以理解。 但是经过几次重读后，我到达了那里。 批准书 在CircleCI工作流下为工作分配 approval类型时，“工作”在config.yml必须是唯一的。 例如，如果您定义了三个主要作业： 建立 测试 部署 每个都在您的工作流程中运行，那么手动触发器必须命名为上述以外的名称。 还必须仅在您的工作流中定义它。 此外，为了使手动触发器真正起作用 ， 必须依赖于它的另一个后续工作。 我将触发器命名为deploy-branch 。 只有在打开CircleCI Web UI并手动启动它时，才会运行此程序。 换句话说，当一个人给予批准时 。 结果 一旦我继续进行工作，并调整了工作流程以包括type: approval为roval的工作，我们便有了一个真正的手动触发器。 它没有精美的界面，例如Github标签或Slackbot命令，但是它确实做到了上面所说的。 结论 作为行业和专业的iOS开发人员，我在摆放我们的CI环境的同时，真正地走出了自己的舒适区。 […]
