长篇加载_关于持续交付的长篇报道

In this article, I’m going to talk about artifacts and build scripts that we need to complete our delivery process. Providing build artifacts for Android is easier than for iOS, that’s why I want to start from it. Also, because my first mobile development experience was on Android and it’s kind of respect and nostalgia.

在本文中，我将讨论完成交付过程所需的工件和构建脚本。 为Android提供构建构件比为iOS提供构建构件要容易，这就是为什么我要从它开始。 另外，因为我的第一个移动开发经验是在Android上进行的，这是一种尊重和怀旧。

First, let’s answer one question: what kind of artifacts do we need? Android package (.apk) or Android App Bundle (.aap) ? The right answer is both. Play Console will use bundle files and AppCenter — good-old APK files. AppCenter could not work with android bundles, at least, on time I’m writing it.

首先，让我们回答一个问题：我们需要什么样的工件？ Android软件包(.apk)或Android应用程序捆绑包(.aap)？ 正确的答案是两者。 Play控制台将使用捆绑包文件和AppCenter-旧的APK文件。 AppCenter至少在我编写时无法使用android bundles。

Based on these requirements we need some commands to build our application. Flutter has built-in CLI, and special command to build release application.

基于这些要求，我们需要一些命令来构建我们的应用程序。 Flutter具有内置的CLI和用于构建发行版应用程序的特殊命令。

flutter build --help

After running this command in the terminal you could find two sub-commands, we needed.

在终端中运行此命令后，您需要找到两个子命令。

flutter build apkflutter build appbundle

What about arguments? We have to pass somehow environments and even more, we have to configure them somewhere. Now I want to move a step back and describe Android build tools.

那参数呢？ 我们必须通过某种方式的环境，甚至更多，我们必须在某个地方配置它们。 现在，我想向后退一步，介绍Android构建工具。

Android uses Gradle to build the application. This tool uses Groovy-based DSL for describing build configuration. You don’t have to have good knowledge of Groovy, actually saying you could handle what we are going to do without any skills in it.

Android使用Gradle构建应用程序。 该工具使用基于Groovy的DSL来描述构建配置。 您不必对Groovy有足够的了解，实际上是说您可以在没有任何技巧的情况下处理我们将要做的事情。

Every Android project has three Gradle files, hopefully, we need to work only with one. Find one at the path, I’ve provided below.

每个Android项目都有三个Gradle文件，希望我们只需要处理一个文件。 在下面提供的路径中找到一个。

android/app/build.gradle

Android has buildTypes and flavors that you can use to configure build outputs. Don’t use buildTypes to configure the multi-environment build. This configuration not for it. buildTypes configuration directly affects how the application will be built. There are should be only two types: release and debug. flavors are a good way to configure resources, sources, and variables that should be specific for any configuration.

Android有buildTypes和口味 ，你可以用它来配置生成输出。 不要使用buildTypes配置多环境构建。 此配置不适合它。 buildTypes配置直接影响构建应用程序的方式。 应该只有两种类型：发布和调试。 风味是配置对于任何配置都应特定的资源，源和变量的好方法。

You have to add this code to android/app/build.gradle to set up flavors into the build configuration into the end of the android section.

您必须将此代码添加到android / app / build.gradle中，才能在android部分的末尾的构建配置中设置风味。

flavorDimensions "environment"productFlavors {    staging {        dimension "environment"        applicationIdSuffix ".staging"    }    production {        dimension "environment"    }    development {        dimension "environment"        applicationIdSuffix ".development"    }}

`flavourDimensions` is just a named group that can be used to organize flavors, it can be named any way you want. One important field that I want to stop is applicationIdSuffix. Android differentiates applications by their applicationId, you already have met it during project creation. Usually, it’s reversed domain name of your company. You could find it also in this file:

flavourDimensions只是一个可用于组织风味的命名组，可以根据需要使用任何方式命名。 我要停止的一个重要字段是applicationIdSuffix。 Android通过应用程序的applicationId区分应用程序 ，您已经在项目创建过程中遇到了它。 通常，它是您公司的反向域名。 您也可以在此文件中找到它：

android {    defaultConfig {        applicationId : "your application id here"    }}

Why do we have to use applicationIdSuffix? To have the possibility to install all applications’ types. You want to have staging and production apps running on one phone. The only way to do it is by saying Android that it are different apps. Different apps should have different applicationId. In our configuration, we keep for production assembly default applicationId, but for others, we add suffixes that match environment names, so we can easily find specific build on the device.

为什么我们必须使用applicationIdSuffix？ 有可能安装所有应用程序的类型。 您希望在一部手机上运行暂存和生产应用程序。 唯一的方法就是说Android是不同的应用程序。 不同的应用程序应具有不同的applicationId 。 在我们的配置中，我们为生产程序集保留默认的applicationId，但对于其他人，我们添加与环境名称匹配的后缀，因此我们可以轻松地在设备上找到特定的内部版本。

Ok, now we can build three different apps and install them on one device, but they have the same name. So what we have to do next: give different names for each application. Android has really cool way to work with flavor specific resources and sources. If you want to include only specific files for flavor or if you want to override some resources you only have to create a new directory with the same name as a flavor and put everything here.

好的，现在我们可以构建三个不同的应用程序并将它们安装在一台设备上，但是它们具有相同的名称。 因此，我们下一步要做的是： 为每个应用程序指定不同的名称 。 Android有一种非常酷的方式来处理特定于风味的资源和来源。 如果您只想包含特定的文件进行调味或要覆盖某些资源，则只需创建一个与调味同名的新目录，然后将所有内容放在此处即可。

android/app/src/development/res/values/strings.xmlandroid/app/src/staging/res/values/strings.xmlandroid/app/src/production/res/values/strings.xml

Create files on the path above. Android has a specific resources directories structure, so if you are newbie here just keep the same names.

在上面的路径上创建文件。 Android具有特定的资源目录结构，因此，如果您是新手，请保持相同的名称。

<?xml version="1.0" encoding="utf-8"?><resources>    <string name="app_name">Demo Development</string></resources>

Paste code above into it. Actually we need the only app_name, so if you have such files, only add this line into it. I recommend keeping the idea with applicationIdSuffix and add environment name to development and staging builds. But that’s not all, we only defined it, now we have to apply it.

将上面的代码粘贴到其中。 实际上，我们只需要一个app_name，因此，如果您有这样的文件，只需在其中添加此行。 我建议保留applicationIdSuffix的想法，并在开发和暂存构建中添加环境名称。 但这还不是全部，我们仅定义了它，现在我们必须应用它。

Find android/app/src/main/AndroidManifest.xml file and change the label in it to the path for our resource.

找到android / app / src / main / AndroidManifest.xml文件，并将其中的标签更改为我们资源的路径。

<application    android:name="io.flutter.app.FlutterApplication"    android:label="@string/app_name"

Now if you build and run the application you will see it has the name you’ve defined. Please, remove any installed application before it.

现在，如果您构建并运行该应用程序，您将看到它具有您定义的名称。 请删除所有已安装的应用程序。

Now, I will create a build script file to simplify the build process. I usually create it into the root project folder.

现在，我将创建一个构建脚本文件来简化构建过程。 我通常将其创建到根项目文件夹中。

touch build_android.shchmod a+x build_android.sh # don't forget to make it executable 

Now let’s define build scenarios into it.

现在让我们在其中定义构建方案。

#!/usr/bin/env bashset -eFLAVOR=${CI_ENVIRONMENT_NAME:-development}if [[ "${FLAVOR}" = "production" ]]; thenflutter build appbundle --flavor ${FLAVOR}fiif [[ "${FLAVOR}" = "staging" ]]; thenflutter build appbundle --flavor ${FLAVOR}flutter build apk --flavor ${FLAVOR}fiif [[ "${FLAVOR}" = "development" ]]; thenflutter build apk --flavor ${FLAVOR}fi

I have to comment line with defining the FLAVOR variable. The script will try to read it value from CI_ENVIRONMENT_NAME, this one we will set in GitLab if it couldn’t be found it will use development value.

我必须对定义FLAVOR变量的行进行注释。 该脚本将尝试从CI_ENVIRONMENT_NAME读取它的值，如果找不到它，我们将在GitLab中设置它，它将使用开发值。

Few tricks on how to run this script on the local machine to check that everything ok. Please check them before move forward.

关于如何在本地计算机上运行此脚本以检查一切正常的一些技巧。 请先检查它们，然后再继续。

./build_android.sh #development flavorexport CI_ENVIRONMENT_NAME=staging && ./build_android.sh #staging flavorexport CI_ENVIRONMENT_NAME=production && ./build_android.sh #production flavor

To complete our build step we have to solve the versioning issue. To successfully install a new build, version number inside it has to be greater than in previous (how obvious). Thanks flutter it added build options to flutter build command to set up version. I recommend using a pipeline build number as the one to mark the current android build. So the final version of our build script will be like below.

要完成构建步骤，我们必须解决版本控制问题。 要成功安装新版本，其内部版本号必须大于以前的版本号(显而易见)。 谢谢flutter，它为flutter build命令添加了构建选项以设置版本。 我建议使用管道内部版本号作为标记当前的android内部版本。 因此，构建脚本的最终版本将如下所示。

#!/usr/bin/env bashset -eFLAVOR=${CI_ENVIRONMENT_NAME:-development}BUILD_NUMBER=${CI_PIPELINE_IID:-1}BUILD_NAME="1.0.${BUILD_NUMBER}"if [[ "${FLAVOR}" = "production" ]]; thenflutter build appbundle --flavor ${FLAVOR} --build-name=${BUILD_NAME} --build-number=${BUILD_NUMBER}fiif [[ "${FLAVOR}" = "staging" ]]; thenflutter build appbundle --flavor ${FLAVOR} --build-name=${BUILD_NAME} --build-number=${BUILD_NUMBER}flutter build apk --flavor ${FLAVOR} --build-name=${BUILD_NAME} --build-number=${BUILD_NUMBER}fiif [[ "${FLAVOR}" = "development" ]]; thenflutter build apk --flavor ${FLAVOR} --build-name=${BUILD_NAME} --build-number=${BUILD_NUMBER}fi

摘要 (Summary)

We’ve created three flavors: development, staging, production. For every flavor, we’ve set different applicationId and application name. Provided final script to build artifacts.

我们创建了三种口味： 开发，登台，生产 。 对于每种口味，我们都设置了不同的applicationId和应用程序名称。 提供了用于构建工件的最终脚本。

Verify the list of modified files during our work you should push to the repository.

在我们工作期间，请验证已修改文件的列表，然后应推送到存储库。

android/app/src/development/res/values/strings.xmlandroid/app/src/staging/res/values/strings.xmlandroid/app/src/production/res/values/strings.xmlandroid/app/src/main/AndroidManifest.xmlandroid/app/build.gradlebuild_android.sh

In the next articles, I will explain how to configure the process of signing our artifacts. So keep reading.

在下一篇文章中，我将解释如何配置对工件进行签名的过程 。 因此，请继续阅读。