Bitrise 自动化发布 Flutter 应用终极指南（二）

书接上回（Bitrise 自动化发布 Flutter 应用终极指南（一）），先回答一下评论区的两个问题：

iOS的包上传最后是脚本？ ：宏观上是的，微观上说Bitrise已经有现成的Step还处理这个流程，只需要我们去做简单配置即可。
Flutter iOS的cicd很复杂吧。cicd要搭配下载平台。 ：其实也不是太复杂，都有现在成的Step，当完成打包后，再通过Step把产出物直接输出到Bitrise上就可以实现企业内部分发了，比如Android的apk， iOS的AdHoc。

上传文件至Bitrise

很多时候我们需要把文件上传至CI/CD平台以供使用，比如一些密钥/配置文件、Android的Keystore文件等等。

首先，我们到Project settings=>Files，点击Add file，然后把文件上传至Bitrise：

稍后，我们将通过Download URL下载相关文件。

APP侧配置

还没忘记怎么在Bitrise上设置环境变量吧。

Android

对于Android来说，如果你直接把aab输出给Play Store并由Play Store签名，那似乎看起来这里不需要什么额外设置。关于这部分如果说错了，请大家指正，我确实没有验证过。这里是有一个小坑，我不清楚是否因为我当时选择直接上传aab导致直接把Signing by Google Play开启了，导致APP签名出现了问题。不过，别怕，我已经为大家找到了解决方案。

又说多了，回到Flutter项目中，找到android/app/build.gradle.kts,我们需要配置一下Android的签名,即仅在CI/CD中才会使用给定的keystore进行打包：

kts 复制代码

signingConfigs {
    if (isCI) {
        create("ciBuild") {
            storeFile = file(System.getenv("ANROID_APP_KEYSTORE_PATH"))
            storePassword = System.getenv("ANROID_APP_KEYSTORE_PWD")
            keyAlias = System.getenv("ANROID_APP_KEYSTORE_ALIAS")
            keyPassword = System.getenv("ANROID_APP_KEYSTORE_KEY_PWD")
        }
    }
}


buildTypes {
    release {
        if (isCI) {
            signingConfig =
                signingConfigs.getByName("ciBuild")
        } else {
            signingConfig = signingConfigs.getByName("debug")
        }

        proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")

    }
}

其中isCI是用来判断当前任务是否处理CI/CD环境：

kts 复制代码

private val isCI get() = System.getenv("CI")?.toBoolean() ?: false

这个是比较基础的配置，如果有更复杂的配置，如Flavors，需要自己动动脑筋哦。

iOS

由于本人iOS是十八线水平，所以iOS相关的如有误请大家指出。

尽管我们采取的是自动签名，但我们仍然需要把签名文件上传至Bitrise,即传说中的.p12文件，至于怎么导出.p12，我就不做赘述了，如果大家有兴趣，我可以再写。

所有 iOS 代码签名方法都要求你将你的 iOS 代码签名证书导出并上传到 Bitrise。

上传.p12至Bitrise也有两种方式：

我只说GUI。

首先确保你的账号有Admin 权限，然后在Project setting=>Code signing中，点击Add .p12 file：

iOS完活。

写CI/CD脚本

用"写"不太准确，准确地说是把各种step组合一下。先看个workflow的图吧：

由于每个公司的策略都不一样，包括内测和发布流程都不一样，所以我只依据我的经验写一个大致流程：

css 复制代码

Activate SSH key
Git Clone Repository
Download
Flutter Install
Flutter Analyze
Manage iOS Code Signing
Flutter Build
Export iOS and tvOS Xcode archive
Google Play Deploy
Deploy to App Store Connect
Deploy to Bitrise.io

大致的流程就是这样的。

接下来，我有选择性地讲解一下：

Download

这个其实很好用，但你要知道不同的初级付费计划只允许你添加16个Step！这个可太坑了，所以这么好用的Step我是舍不得用啊。所以用Script这个Step写shell脚本更实惠，毕竟自己写脚本量大管饱：

bash 复制代码

#!/usr/bin/env bash
echo "Download env files..."
if curl -o "$BITRISE_SOURCE_DIR/.env" "$MOBILE_APP_ENV_URL"; then
    echo "Download env successful"
else
    echo "Download env failed"
    exit 1
fi

Flutter Install

这个是用来安装Flutter的，Flutter的版本默认是Stable，但依我的体验来看，Stable这个参数也太Stable了------版本落后啊。所以，不管出于版本落后的考虑，还是出于App的稳定性考虑，我建议把版本锁死：

Manage iOS Code Signing

这个是管理iOS签名的，可以选择是ad-hoc或者是app-store之类的。

由于我们选择的API Key的形式与Apple service进行连接，所以直接选择Default(api-key)就可以了。

至于Distribution method(optional)，是ad-hoc还是app-store就得依据你的实际需求了。

其中Project path中的值为：$BITRISE_SOURCE_DIR/ios/Runner.xcodeproj

Flutter Build

这个Step是用来打包的，可以选择仅打包Android、仅打iOS或者全部。

有一点需要提醒的是，如果你打包是需要做tree shaking，即在flutter build中添加了如下参数：

ini 复制代码

--obfuscate --split-debug-info=$BITRISE_MAPPING_PATH

我们需要把mapping文件存放到指定地方，这里我推荐放到类似$BITRISE_DEPLOY_DIR、BITRISE_MAPPING_PATH的文件夹中，因为有的目录可能没有读取权限。。。因为在实际项目中可能需要把这mapping文件上传到如Firebase这类的bug追踪平台上。

这里也有针对Android/iOS独立的配置。

iOS产出物类型我们选择archive，至于Android的产出物选择是appbunble还是apk就得基于你实际需求主了。

Export iOS and tvOS Xcode archive

你知道你要发布到app-store还是ad-hoc就行了。

Google Play Deploy

你知道你的app的应用包名就行了。。。

Deploy to Bitrise.io

这个Step就是把你的产出物发布到Bitrise供内部测试用了。每次的产出物可以在Project=>Artiacts中找到。也可以在每次Build的中的Artifacts中找到。

结束语

总得来说,Bitrise体验还是不错的，如果大家有问题，可以评论区留言。欢迎大家关注一波。