引言
几个月前就想写一期关于在Bitrise上如何实现Flutter应用发布自动化的文章，但拖延症犯了，好在没有对别人做过什么承诺。
自动化的好处就不必多说了，比如说方便管理密钥、避免密钥泄露等等。我觉得最重要的是解放双手，不用重复做一些重复环节，如打包apk、上传到Google Play等等，搞不好某个环节还容易操作失误，还有一点就是不必非得找开发人员打包之类的。太多了不说了。
欢迎关注我的微信公众号：OpenFlutter，感谢
CI/CD的工具有很多，但今天要说的是Bitrise。
为什么要用Bitrise
简单说一下Bitrise。
Bitrise是一个专注于移动端DevOps的CI/CD平台。
它提供了针对移动端CI/CD做了优化，并提供了易用的界面，相对Jenkins来说，确实好太多了。可以说Bitrise提供一站式，甚至傻瓜式的CI/CD体验。
本文要分享的是主要是Flutter应用通过Bitrise实现发布自动布（我指的是发布到Google Play和Appstore）。
当然本文也需要一定的基础，比如说：
- 至少你得会在
Bitrise上创建一个CI项目 - 知道什么是
webhook - 知道
Google Play的service account如何创建 - 知道常见的flutter 命令 等等，不过不会也没关系，可以选择硬着头皮看完本文。
Bitrise相关的一些概念
我认为Bitrise的关键概念有三个，分别是steps（步骤）、workflows（工作流程）和pipelines（管道）。除此之外，我还简单说一下环境变量。
下面我先简单介绍一下三个概念。
Steps
steps是Bitrise的心脏，也就是核心中的核心。一个Step，说人话就是一个构建任务，比如说Git Clone这一步就是要把你的代码仓库克隆下来。
一个 Step（步骤） 包含执行构建任务的代码。你可以配置定义该任务的输入和参数，并查看和重用该 Step 生成的输出。重用输出意味着另一个 Step 可以将其作为其某个输入的值来使用。
Step（步骤） 是以YAML格式定义的，代码使用 Bash 或 Go 编写。
这意味你可以直接通过编辑yaml文件修改CI/CD配置，当然我不建议你这么玩，因为GUI更好呗
Bitrise通过StepLib提供了丰富的Steps，大部分情况都可以满足我们的日常需求，如果满足不了，那就自己写shell啥的吧。
每个Step可以有输入或者输出，这个很重要。
- 输入：意味着你可以配置你的Step，比如说
Keystore的位置。输入项也可以是一些环境变量，这个后面会讲到。 - 输出：这个其实也挺重要的，一些step会告诉你他的一些产出物放在哪个目录里，只有了解了这些你才可以通过脚本获取这些产出物。
我们以Flutter Test这个Step为例吧：
比如，你可以更改Project的存储位置。
比如，你可以在$BITRISE_FLUTTER_COVERAGE_PATH这个位置获取到测试报告。
细心的朋友已经看到上面有截图是When to run，没错，你可以在任何给定的 Workflow中启用或禁用一个Step ，你也可以为步骤设置执行条件。你可以直接在自己的电脑上使用 Bitrise CLI 来完成，或者通过Workflow Editor（工作流程编辑器）中的 bitrise.yml 标签页进行设置。
我们主要使用 run_if 表达式来实现这些功能。请查看示例，了解可能的模板表达式：run_if 表达式示例。
你也可以在 GitHub 上查看这些示例：模板表达式示例。
run_if可以是任何有效的 Go 模板一个
run_if表达式可以是任何有效的 Go 模板 ，只要它的求值结果为true或false（或者任何字符串表示，例如True、t、yes或y都会被视为true）。如果模板求值结果为true，则该Step将运行，否则它将不会运行。
Step中还有一个概念就是Step Bundles，顾名思义，就是把一组Step封装到一起了就是一个Step Bundle:
Workflow
一个Workflow是由一系列 Steps（步骤） 组成的。当一个项目的构建运行时，每个 Step 将按照在 Workflow 中定义的顺序执行。工作流程可以通过两种方式创建、定义和修改：
- 使用
bitrise.io上的图形化工作流程编辑器，或者在你自己的设备上使用离线版本。 - 直接编辑项目的
bitrise.yml文件。
最终，这两种方法都是在修改 bitrise.yml 文件------只是工作流程编辑器是一种更友好的操作方式！
默认情况下，一次单独的构建就是一个 Workflow。但你也可以将多个Workflow连接起来，让它们依次运行，也可以触发多个 Workflow 同时运行。
Workflow 还可以被组织成 Pipelines 。一个 Pipeline 由多个 Stage（阶段）组成，而每个 Stage 又包含一个或多个并行运行的 Workflow。
总之，我们的发布流程就是在workflow上完成的。
创建一个Workflow:
Pipelines
一个 Bitrise Pipeline 是我们 CI/CD 配置的顶层。管道可用于组织整个 CI/CD 流程，并设置高级配置，支持多个不同的任务并行或按顺序运行。
没用过也没实际应用场景，所以不做太多叙述，我只知道我们当前这个付费计划中还不配使用
Pipelines
环境变量
环境变量可以从两个维度区分，即保密与非保密。
保密的叫Secrets，这意味着他们是被加密存储的，一旦存成Secret，那你在log中是看不到对应值的，如果你把标记为Protected，那意味你再也看不到他的真实值了。
另一种的环境变量就是普通的环境变量(Env Vars)了，也是有两种，一种是项目级别的，一种是workflow级别的。顾名思义，Project级别的变量是对整个Project都好用的变量，workflow级别的只针对当前的workflow好用。
好戏开场了
说了这么多，总算正式开场了。
首先准备一下Play Store和 App Store Connect配置。我假设你已经会配置Googe service account和Apple service connection。
申请完以后,Google 会给你的xxx.json文件，而Apple会给的xxx.p8文件，还有对应的Name,Issuer ID和Key ID，反正把一堆东西扔到下面的步骤里就好了。
不过，为了保证程序正常运行，需要注意的Google Service account需要以下权限：
- Access level: View app information.
- Release management: Manage production releases, manage testing track releases.
- Store presence: Edit store listing, pricing & distribution.
由于Play Store是英文的，我就不翻译了。
同样的，iOS的API key也有一些要求，这样方便Bitrise管理签名：
- 一定要是Teams Key
以下的配置都是基于Bitrise全自动化作业，即自动化管理签名，分布。如果想手动配置签名的话，自己研究吧。
Bitrise
你得知道我们接下来配置的东西在Workpace settings=>Integrations里。
Apple的API Key申请可以参照官方文档。
上面两步配置完了以后，我们需要回到Project setting=>Integrations=>Store中，把对应的设置勾选上。
Apple
太累了，先写到这里，也不知道有没有人看，要是没人看就不写了，有人看了再说。