fastlane 项目管理_在fastlane上获取您的android项目

fastlane 项目管理

As the title implies, this piece is about automating your Android development workflow with fastlane.

顾名思义，这是关于使用fastlane自动化您的Android开发工作流程。

You may be thinking, “But, uh, automation is something generic and applies to almost anything you can think of, especially in building software. So can you be a bit more accurate?”

您可能会想，“但是，自动化是通用的，几乎适用于您能想到的任何事物，尤其是在构建软件时。 那么您能更准确一点吗？”

Well, what I’m actually referring to are the following:

好吧，我实际上指的是以下内容：

• Use build variants to indicate whether your app is running on test or production endpoints
  使用构建变体指示您的应用程序是在测试端点还是在生产端点上运行
• Assign a signing configuration for each variant
  为每个变体分配签名配置
• Automate versioning with a versioning scheme and tools
  使用版本控制方案和工具自动执行版本控制
• Use fastlane to run tests; build and distribute our app via Firebase App Distribution
  使用fastlane运行测试； 通过Firebase App Distribution构建和分发我们的应用程序

Unfortunately, the last part will only be available for Mac OS and Unix users only due to the fact that fastlane doesn’t officially support Windows OS yet.

不幸的是，由于fastlane尚未正式支持Windows OS，所以最后一部分仅对Mac OS和Unix用户可用。

构建变体 (Build Variants)

Build variants are a powerful feature of Android that allows us to have different configurations for our builds. Build variants are composed of build types in combination with flavors. I suggest reading more on build variants, if you haven’t already.

Build变体是Android的强大功能，可让我们为自己的构建使用不同的配置。 构建变体由结合风味的构建类型组成。 我建议您阅读更多有关构建变体的信息 ，如果您还没有的话。

My experience with Android has shown me that for a streamlined development environment, you need at least four build variants, unless otherwise specified by the business — e.g., premium and free application versions. The build variants we’re going for are the following:

我在Android上的经验表明，对于精简的开发环境，除非业务另有规定，否则您至少需要四个构建变体，例如，高级版本和免费应用程序版本。 我们要使用的构建变体如下：

• developmentDebug: For our day to day development

  developmentDebug ：用于我们的日常开发

• productionDebug: For extreme (or not so extreme) cases where we need to check on a bug with production data

  productionDebug ：对于极端(或不太极端)的情况，我们需要使用生产数据检查错误

• developmentRelease: This variant will be distributed to our QA team through Firebase Crashlytics. It’ll be a replica of our Play Store version — apart from the fact it’ll be using our test servers.

  developmentRelease ：此变体将通过Firebase Crashlytics分发给我们的质量检查小组。 它将是我们的Play商店版本的副本-除了它将使用我们的测试服务器之外。

• productionRelease: Play Store version

  productionRelease ：Play商店版本

Additionally, each build variant will have its own unique applicationId, meaning you’ll be able to have all four build variants installed on your device at the same time as different applications. To identify which is which, I’ll show you how to change their names, which can also be applied to having different launcher icons as well.

此外，每个构建变体将具有其自己唯一的applicationId ，这意味着您将能够同时将所有四个构建变体与不同的应用程序安装在设备上。 为了确定是哪个，我将向您展示如何更改其名称，也可以将其更改为具有不同的启动器图标。

构建类型 (Build types)

When we create a new Android project, we get two build types by default, debug and release. If you check your app module’s build.grade, the debug is omitted.

当我们创建一个新的Android项目时，默认情况下会获得两种构建类型，即debug 然后release 。 如果检查应用程序模块的build.grade ，则将省略调试。

buildTypes {


  release {
    minifyEnabled false
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
  }


}

But if you check the build variants that can be found under View > Tool Windows and select the Active Build Variant drop-down, you’ll see two variants. Android provides the debug build type by default.

但是，如果您检查可以在“视图”>“工具窗口”下找到的构建变体，然后选择“活动构建变体”下拉菜单，则会看到两个变体。 Android默认提供debug构建类型。

Default build variants

默认构建变体

I like being verbose, so for starters, we’ll explicitly define the debug build type in our Gradle file. Your files should look like the following:

我喜欢冗长，因此对于初学者来说，我们将在Gradle文件中显式定义debug构建类型。 您的文件应如下所示：

buildTypes {


  debug {
    applicationIdSuffix ".debug"
    debuggable true
  }


  release {
    minifyEnabled false
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
  }


}

At line 4, we have also provided an applicationIdSuffix. So our debug build will be suffixed with .debug, meaning if our app ID is, for example, com.example.myapp, the debug build will be com.example.myapp.debug.