分发自动化_使用bitrise自动化应用分发

分发自动化

You really don’t know the benefits of automation until you see it for yourself

您真的不知道自动化的好处，直到您自己看到它

Hopefully by the end of this article I would have convinced you to stop what you are doing and add some automation to your app/project.

希望到本文结尾时，我已经说服了您停止正在做的事情，并为您的应用程序/项目添加了一些自动化功能。

介绍 (Introduction)

A few weeks into this new freelance project, maybe a month, I set up a distribution process in Firebase so the client can start receiving frequent progress updates and provide feedback as soon as possible.

在这个新的自由职业项目的几个星期(可能是一个月)中，我在Firebase中设置了分发过程，以便客户可以开始接收频繁的进度更新并尽快提供反馈。

At the beginning it was all manual, archiving the only scheme (pointing to staging) from Xcode, exporting for Ad-hoc, uploading the .ipa to Firebase, and send it to the only tester (himself). And it was fine, the whole process was between 5–10 minutes, even if you repeat the process twice a day, we are talking about 20 minutes max, no big deal.

在一开始，一切都是手动的，从Xcode归档唯一的方案(指向暂存)，导出为Ad-hoc，将.ipa上载到Firebase，然后将其发送给唯一的测试者(他自己)。 很好，整个过程在5到10分钟之间，即使您每天重复两次该过程，我们所说的最大时间是20分钟，没什么大不了的。

But then the archiving time started to increase as a consequence of adding more third-party libraries, and a new scheme was added pointing to production.

但是随后，由于添加了更多的第三方库，归档时间开始增加，并且添加了一个针对生产的新方案。

The whole process just multiplied by 2 overnight. Archive x3, export x2, upload to firebase x2.

整个过程乘以2整夜。 存档x3，导出x2，上传到firebase x2。

And I am a lazy developer. The lazy word might have a negative connotation, but I think it fuels the motivation to automate repetitive and annoying tasks, resulting in having more time for the important stuff. Automation is ideal for repetitive tasks like this one.

而且我是一个懒惰的开发人员。 懒惰的单词可能具有负面含义，但我认为它激发了自动执行重复性和令人讨厌的任务的动机，从而导致有更多时间来处理重要内容。 对于此类重复性任务，自动化是理想的选择 。

Another good reason to automate is to reduce or eliminate the risk of human error. Many times when archiving I forgot to bump the build version and things like that. When you define a comprehensive workflow on the automation tool, you ensure they will always be executed.

自动化的另一个好理由是减少或消除人为错误的风险。 存档时，很多时候我都忘记了构建版本之类的东西。 在自动化工具上定义全面的工作流程时，请确保将始终执行它们。

If you are still not convinced about the reasons, every time I archive the CPU usage and temperature skyrocket:

如果您仍然不确定原因，那么每次我存档CPU使用率和温度飙升时：

Anyone wants fried egg?

有人要煎鸡蛋吗？

There are many online CI/CD platforms out there to choose, you can find comparison table here, here and here.

有许多在线CI / CD平台可供选择，您可以在此处 ， 此处和此处找到比较表。

I chose Bitrise because has a free tier including Mac OS VM, because of the vast amount of plugins to add in a workflow (will see it later), and the simplicity of use.

我之所以选择Bitrise，是因为它具有包括Mac OS VM在内的免费层，这是因为要在工作流中添加大量插件(稍后会看到)，并且使用简单。

But Bitrise is just a tool, feel free to use the one that adjusts to your needs.

但是Bitrise只是一种工具，请随时使用可根据您的需求进行调整的工具。

比特升起 (Bitrise)

After signing up on Bitrise.io using my Github account, the platform prompts to create a new App. A wild wizard appeared!

使用我的Github帐户在Bitrise.io上注册后，平台提示创建一个新的应用程序。 一个狂野的巫师出现了！

Wizard to create a new App on Bitrise.io

在Bitrise.io上创建新应用的向导

Since I already connected Bitrise with Github, it pulls all my public and private repo from there, making it easier to select the location of the source code.

由于我已经将Bitrise与Github连接起来，因此它将所有我的公共和私有存储库从那里拉出，从而使选择源代码的位置更加容易。

Bitrise automatically detects that it’s an iOS app and uses Cocoapods as dependency manager. It can even pull the icon from the project and set it as avatar for this newly created app.

Bitrise自动检测到它是一个iOS应用程序，并使用Cocoapods作为依赖项管理器。 它甚至可以从项目中拉出图标，并将其设置为该新创建的应用程序的头像。

All I need to do is select which scheme to build and which export configuration (dev, adhoc, appstore, enterprise). Bitrise will automatically configure the necessary keys (with privileges to clone the selected repo) and webhook on Github.

我需要做的就是选择要构建的方案和导出的配置(dev，adhoc，appstore，Enterprise)。 Bitrise将自动在Github上配置必要的密钥(具有克隆所选存储库的权限)和webhook。

Why webhook? So Github can tell Bitrise whenever there is a change on the designated repo, new code pushed, new tag created, etc.

为什么要挂机？ 因此，只要指定的存储库发生更改，推送了新代码，创建了新标签等，Github就可以告诉Bitrise。

We land on the dashboard for the app, and the very first build running. Of course it’s gonna fail, since Bitrise needs to corresponding certificate (.p12 file) and provisioning profile(s).

我们登陆该应用程序的仪表板，并运行第一个构建。 当然，这将失败，因为Bitrise需要相应的证书(.p12文件)和供应配置文件。

The dashboard for the newly created App

新创建的应用程序的仪表板

To fix this, we go to Workflow tab, and opens this in a new window:

要解决此问题，我们转到“ 工作流程”选项卡，然后在新窗口中打开它：

Where the magic happens

奇迹发生的地方

This window contains all the workflows and configurations for the App, divided into the following tabs:

该窗口包含该应用程序的所有工作流程和配置，分为以下选项卡：

1. Workflows: where you can create, edit, remove workflows, a primary workflow is created by default with some basic steps

   工作流程 ：您可以在其中创建，编辑，删除工作流程的地方，默认情况下会通过一些基本步骤创建主要工作流程

2. Code Signing: where you can add the certificates and provisioning profile

   代码签名 ：您可以在其中添加证书和配置文件

3. Secrets: to store ssh keys, passwords, etc

   秘密 ：存储ssh密钥，密码等

4. Env Vars: to be shared across all steps in the workflow, for example the path to the .ipa file is an env variable

   Env Vars ：要在工作流的所有步骤之间共享，例如，.ipa文件的路径是一个env变量

5. Triggers: where you can run a particular workflow when there is a new pull request, code push in a branch, or new tag created on the repo

   触发器 ：当有新的请求请求，分支中的代码推送或在存储库上创建新的标签时，您可以在其中运行特定的工作流

6. Stack: to specify the stack to be used on the VM, version of mac OS, Xcode, Swift version, etc. A different stack per workflow can be configured. It is recommended to use the latest stack, however your app might not be compatible with it yet. Check the details of the default stack

   堆栈 ：指定要在VM上使用的堆栈，mac OS的版本，Xcode，Swift版本等。可以为每个工作流配置不同的堆栈。 建议使用最新的堆栈，但是您的应用程序可能与此尚不兼容。 检查默认堆栈的详细信息

7. Bitrise.yml: auto-generated when you modify the other tabs, you don’t really need to modify this file

   Bitrise.yml ：当您修改其他选项卡时自动生成，您实际上不需要修改此文件

工作流程 (Workflows)

A workflow is a list of steps in a given order to achieve anything. The default workflow created by Bitrise has the recipe to generate a .ipa file.

工作流是给定顺序的步骤列表，以实现任何目的。 Bitrise创建的默认工作流程具有生成.ipa文件的方法。

Steps can be re-arranged, add new ones, remove existing

可以重新安排步骤，添加新步骤，删除现有步骤

Each step is open source, and the Github url is available with to contribute, report issues, etc. Each step has different variables/flags to configure. For example on the Archive & Export step you can define whether to use Bitcode or not.

每个步骤都是开放源代码，并且Github URL可用于贡献，报告问题等。每个步骤都有不同的变量/标志可配置。 例如，在“ 存档和导出”步骤中，您可以定义是否使用位码。

This workflow essentially:

该工作流程实质上是：

1. Ensures Bitrise uses the SSH key to access Github
   确保Bitrise使用SSH密钥访问Github
2. Clones the repo
   克隆仓库
3. Pulls cache if exists with the aim to speed up the overall process, by avoiding the need of installing all the dependencies from scratch
   提取缓存(如果存在)，旨在通过避免从头开始安装所有依赖项的目的来加快整个过程
4. Executes pod install
   执行Pod安装
5. Archives the given scheme, and exports using the given config
   存档给定方案，并使用给定配置导出
6. Collects the .ipa file, dsym folder, and other artifacts, and makes them available to download on every build detail page
   收集.ipa文件，dsym文件夹和其他工件，并使其可在每个构建详细信息页面上下载
7. Pushes cache if required
   如果需要，推送缓存

分发到Firebase (Distributing to Firebase)

Although Bitrise has its own distribution channel, I already set up Firebase to share the app with the client, the idea was to keep using the same.

尽管Bitrise拥有自己的发行渠道，但我已经设置了Firebase与客户端共享应用程序，但想法是继续使用该应用程序。

There is a Firebase App Distribution step we can add to the workflow, in order to automatically upload the .ipa file to our Firebase account.

我们可以将Firebase应用程序分发步骤添加到工作流程中，以便将.ipa文件自动上传到我们的Firebase帐户。

Steps related to Firebase

与Firebase相关的步骤

The step has to be placed after the Archive & Export step, to ensure the .ipa is available on the given path.

步骤必须放置在归档和出口步骤之后 ，为保证的.ipa可在给定的路径上。

And the configuration of this new step is rather straightforward:

这个新步骤的配置非常简单：

Firebase Distribution step

Firebase分发步骤

1. We need a Firebase Token that can be generated from the Firebase CLI. The SENSITIVE label is forcing us to create a Secret variable, this will ensure the token won’t be visible on the build logs

   我们需要可以从Firebase CLI生成的Firebase令牌。 SENSITIVE标签迫使我们创建一个Secret变量，这将确保令牌在构建日志中不可见

2. App Path: by default the env var $BITRISE_IPA_PATH is filled out, nothing to change
   应用程序路径：默认情况下，env var $ BITRISE_IPA_PATH已填写，没有任何更改
3. Firebase App ID: retrieved from the Firebase Admin Panel
   Firebase应用程序ID：从Firebase管理面板中检索
4. Release Notes File: it is committed together with the source code, so whenever it’s time to create a new build, I modify manually this .txt file
   发行说明文件：该文件与源代码一起提交，因此每当需要创建新版本时，我都会手动修改此.txt文件
5. Tester Groups: Firebase allows the creation of groups of testers, instead of specifying one by one
   测试人员组：Firebase允许创建测试人员组，而不是一一指定

After this step, I added another one to upload the dsym to Firebase in order to visualize the crashes that may occur.

此步骤之后，我添加了另一个将dsym上传到Firebase，以可视化可能发生的崩溃。

链接工作流程 (Chaining workflows)

Remember the idea was to distribute two builds with different schemes.

请记住，该想法是分发具有不同方案的两个内部版本。

First I renamed the primary workflow into something more comprehensive, for example firebase-stage.

首先，我将主要工作流程重命名为更全面的内容，例如firebase-stage 。

Then created a new workflow using firebase-stage as base, and named it firebase-prod.

然后使用firebase-stage作为基础创建一个新的工作流，并将其命名为firebase-prod 。

Finally, modified the Archive step to use the corresponding scheme and export method, and the Firebase step to ensure the .ipa is uploaded to the right App (I set up 2 different apps on Firebase).

最后，修改存档步骤以使用相应的方案和导出方法，并修改Firebase步骤以确保将.ipa上传到正确的应用程序(我在Firebase上设置了2个不同的应用程序)。

One option to chain workflows is to use the built in buttons:

链接工作流的一种方法是使用内置按钮：

But these buttons will concatenate the steps of the given workflows, resulting in a long pipeline.

但是这些按钮将串联给定工作流程的步骤，从而导致冗长的流程。

I forgot to mention that the Bitrise free tier has a limit of 30 minutes per build. Chaining the workflows this way will take more, trust me.

我忘了提到Bitrise免费套餐每个版本最多30分钟。 相信我，用这种方式链接工作流将花费更多。

Luckily, there is another step you can incorporate that will trigger another given workflow.

幸运的是，您可以合并另一个步骤，该步骤将触发另一个给定的工作流程。

So what I did, is to add this step at the beginning to firebase-stage, triggering firebase-prod. The free tier doesn’t allow simultaneous builds, so firebase-prod is put on hold and added to the queue. That is fine for me, there is no rush!

所以我要做的是在开始时将此步骤添加到firebase阶段，从而触发firebase-prod。 免费套餐不允许同时进行构建，因此firebase-prod会被保留并添加到队列中。 对我来说很好，没有急事！

Now when I trigger a build manually (or schedule it to a specific day/time), both workflows will run in serial, and distribute 2 different .ipa files.

现在，当我手动触发构建(或将其计划到特定的日期/时间)时，两个工作流将串行运行，并分发2个不同的.ipa文件。

But what! there is more!

但是什么！ 还有更多！

输入Fastlane (Enter Fastlane)

Like I said, I am a lazy developer and want to automate as much as possible, for example the creation and push of a new tag, and incrementing the build number of the project.

就像我说的那样，我是一个懒惰的开发人员，希望尽可能地自动化，例如创建和推送新标签，以及增加项目的内部版本号。

Once you install and initialize fastlane for your project, add a new lane (function) to the fastfile created automatically:

在为项目安装并初始化fastlane之后 ，将新通道(函数)添加到自动创建的fastfile中 ：

fastfile

快速文件

This lane called release will:

这条称为发布的通道将：

1. increment build number by 1
   将内部版本号增加1
2. commit the modified file(s) from step 1, with a comprehensive commit message
   使用全面的提交消息提交步骤1中修改后的文件

3. create a new tag with name release/{version}.{build}

   创建一个名称为release / {version}的新标签。{build}

4. push the commit and tag created in step 2 and 3
   推送在步骤2和3中创建的提交和标记

扳机 (Triggers)

And finally, on the Triggers tab inside the build’s workflow page, I specified that every time there is a new tag with prefix release/, launch a new build using workflow firebase-stage.

最后，在构建工作流页面内的“ 触发器”选项卡上，我指定每次使用前缀为release /的新标签时，都使用工作流firebase-stage启动新构建。

Setting up the new trigger

设置新触发器

就是这样🚀🚀🚀 (And that’s it 🚀🚀🚀)

Now whenever I finish a feature, fix a bug, etc, what I do is:

现在，只要我完成一项功能，修复一个错误等，我所要做的就是：

1. Update the release notes in the .txt file
   更新.txt文件中的发行说明

2. Run fastlane release on the terminal

   在终端上运行fastlane release

接下来是什么？ (What is next?)

The process described works fine when you are working alone, when working with a team there are considerations to have. For example the possibility that the tag already exists in remote.

当您独自工作时，与团队一起工作时，所描述的过程很好用。 例如， 标签已经存在于远程中的可能性。

App distribution is not the only thing to automate, it is encouraged to automate tests with a coherent criteria. For example quick unit tests on every push, integration tests on every pull request, full tests suite upon creating new tag, merging to release or master branch, or even schedule it once a day to ensure everything is neat and tidy when you start working the morning after.

应用分发不是唯一自动化的方法，它鼓励使用一致的标准来自动化测试 。 例如，每次推送的快速单元测试，每个拉取请求的集成测试，创建新标签时的完整测试套件，合并到发布或主分支，甚至每天安排一次，以确保开始工作时一切都整洁之后的早晨。

In addition, it is possible to automate App Store deployment. Just add a new step to a workflow in order to upload the .ipa to App Store Connect. After some minutes will be available in the portal to distribute using Test Flight or submit for review.

此外，可以自动进行App Store部署。 只需在工作流程中添加一个新步骤，即可将.ipa上传到App Store Connect。 几分钟后，门户中将可以使用Test Flight进行分发或提交进行审查。

结论 (Conclusion)

My laptop is faster than the Bitrise VM, at least the free tier. If I measure only the time variable, the whole process described is faster on my machine.

我的笔记本电脑比Bitrise VM更快，至少是免费套餐。 如果仅测量时间变量，则在我的计算机上描述的整个过程会更快。

But during this time, my laptop is completely useless, can’t even open a chrome tab.

但是在这段时间里，我的笔记本电脑完全没用，甚至无法打开chrome标签。

On top of that, there is a lot of manual work that is error prone (uploading to the incorrect Firebase app, not bumping build number, etc).

最重要的是，有很多容易出错的手动工作(上传到不正确的Firebase应用程序，不增加内部版本号等)。

The automation strategy might not be better in terms of raw time. I see it as a stress-free, failure-free solution to delegate tedious and repetitive work, while I can focus on more important stuff.

就原始时间而言，自动化策略可能不会更好。 我认为这是委派繁琐且重复的工作的无压力，无故障的解决方案，而我可以专注于更重要的事情。

You see the real benefit once the process is in place and you start using it. The only regret is not having implemented it earlier.

一旦流程到位并开始使用它，您将看到真正的好处。 唯一的遗憾是未及早实施。

翻译自: https://medium.com/flawless-app-stories/automating-app-distribution-using-bitrise-4356b8da8077

分发自动化