如何使用 GitHub Action 在 Android 中构建 CI-CD_github actions 实现cicd

一、什么是 CI/CD？

在现代软件开发中，持续集成和持续开发（CI/CD）至关重要。它可以自动执行软件构建、测试和部署等任务，确保快速且一致的发布。通过将工作划分为更小的部分并自动化工作流程，CI/CD 可以减少错误、加速开发并保持软件就绪状态。在当今的技术领域，CI/CD 是保持敏捷、响应能力和竞争力的基本要求。

CI/CD 是一种通过在应用程序开发阶段引入自动化来频繁向客户交付应用程序的方法。CI/CD 的主要概念是持续集成、持续交付和持续部署。CI/CD 是解决集成新代码可能给开发和运营团队带来的问题（又名“集成地狱”）的解决方案。

具体来说，CI/CD 在应用程序的整个生命周期（从集成和测试阶段到交付和部署）引入了持续的自动化和持续监控。总而言之，这些互联实践通常被称为“ CI/CD 管道”，并得到开发和运营团队的支持，他们通过DevOps或站点可靠性工程 (SRE)方法以敏捷的方式协同工作。

二、什么是 CI：持续集成？

CI/CD中的“CI”总是指持续集成，这是开发人员的自动化过程。成功的 CI 意味着对应用程序的新代码更改会定期构建、测试并安全地合并到共享存储库。它解决了同时开发应用程序的多个分支可能相互冲突的问题。

在现代应用程序开发中，目标是让多个开发人员同时开发同一应用程序的不同功能。但是，如果组织设置为在某一天（称为“合并日”）将所有分支源代码合并在一起，则最终的工作可能是乏味的、手动的且耗时的。这是因为，当独立工作的开发人员对应用程序进行更改时，它有可能与其他开发人员同时进行的不同更改发生冲突。如果每个开发人员都定制了自己的本地集成开发环境 (IDE)，而不是团队同意使用一种基于云的 IDE，那么这个问题可能会进一步复杂化。

持续集成 (CI) 帮助开发人员更频繁地将代码更改合并回共享分支或“主干”，有时甚至每天一次。一旦开发人员对应用程序的更改被合并，这些更改就会通过自动构建应用程序并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证，以确保更改不会破坏应用程序。这意味着测试从类和函数到构成整个应用程序的不同模块的所有内容。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更轻松地快速、频繁地修复这些错误。

三、什么是CD：持续部署？

CI/CD 中的“CD”指的是持续交付和/或持续部署，这是有时可以互换使用的相关概念。两者都是关于管道的进一步阶段的自动化，但有时会单独使用它们来说明正在发生多少自动化。

3.1 持续交付

持续交付通常意味着开发人员对应用程序的更改会自动进行错误测试并上传到存储库（例如 GitHub 或容器注册表），然后运营团队可以将它们部署到实时生产环境。这是对开发人员和业务团队之间可见性和沟通不佳问题的答案。为此，持续交付的目的是确保以最少的努力来部署新代码。

在 CI 中实现构建、单元和集成测试的自动化之后，持续交付会自动将经过验证的代码发布到存储库。因此，为了拥有有效的持续交付流程，将 CI 内置到您的开发管道中非常重要。持续交付的目标是拥有一个随时可以部署到生产环境的代码库。

在持续交付中，每个阶段——从代码更改的合并到生产就绪版本的交付——都涉及测试自动化和代码发布自动化。在此过程结束时，运营团队能够快速轻松地将应用程序部署到生产中。

3.2 持续部署

持续部署（另一种可能的“CD”）可以指自动将开发人员的更改从存储库发布到可供客户使用的生产环境。它解决了手动流程导致运营团队超载、减慢应用交付速度的问题。它通过自动化管道中的下一阶段来构建持续交付的优势。

成熟的 CI/CD 管道的最后阶段是持续部署。作为持续交付的扩展（自动将生产就绪版本发布到代码存储库），持续部署自动将应用程序发布到生产环境。由于生产前的流水线阶段没有手动关口，因此持续部署很大程度上依赖于精心设计的测试自动化。

实际上，持续部署意味着开发人员对云应用程序的更改可以在编写后几分钟内生效（假设它通过了自动化测试）。这使得持续接收和合并用户反馈变得更加容易。总而言之，所有这些相互关联的 CI/CD 实践降低了应用程序部署的风险，从而更容易以小块方式发布对应用程序的更改，而不是一次性发布全部更改。不过，还需要大量的前期投资，因为需要编写自动化测试来适应 CI/CD 管道中的各种测试和发布阶段。

四、使用 GitHub 操作在 Android 中构建 CI-CD 管道

4.1 步骤

1. 打开Android Studio
2. 将您的应用程序文件结构切换到项目模式。

3. 创建新目录并将其命名为.github/workflows

4. 在文件夹内创建新文件workflows。将其命名为AndroidBuild.yml

# This is a basic workflow to help you get started with Actions
name: Android Build

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "master" branch
  pull_request:
    branches: ["master"]
  push:
    branches: ["master"]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: Checkout
        uses: actions/checkout@v4.1.1

      - name: Setup Java JDK
        uses: actions/setup-java@v4.0.0
        with:
          java-version: '17'
          distribution: 'adopt'

      - name: Change wrapper permissions
        run: chmod +x ./gradlew

      # Runs a single command using the runners shell
      - name: Build with Gradle
        run: ./gradlew build

      - name: Upload a Build Artifact
        uses: actions/upload-artifact@v3.1.3
        with:
          name: AndroidCICD.apk
          path: app/build/outputs/apk/debug/app-debug.apk
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

5. 推送您的代码，它将使用 GitHub 操作进行检查，如果您的工作流程通过，那么它将标记为绿色复选图标。

6. 更多信息。
   如果您想创建新的工作流程，则可以单击“新工作流程”按钮

选择预定义的模板或使用简单工作流程创建您自己的工作流程。

如果您选择“简单工作流程”，那么单击“配置”后您将看到这样的页面。

左侧显示基本工作流程示例，右侧显示市场，您可以根据需要添加操作。

设置 Java JDK 操作的示例，探索它并根据您的需要进行选择。

演示项目： GitHub - KaushalVasava/AndroidCICD：这是一个使用 GitHub 专注于 Android 中 CI-CD 的项目… 这是一个使用 GitHub Actions 专注于 Android 中 CI-CD 的项目。

五、什么是 GitHub 操作？

由于需要一种更好的方法来使 GitHub Actions 术语变得超级容易理解，我将对此进行过度简化。

在 CI/CD 管道中，GitHub Actions 是自动化无聊工作的实体。将其视为与您创建的每个 GitHub 存储库捆绑在一起的某个插件。

该插件存在于您的存储库中，可以执行您告诉它的任何任务。通常，您可以通过 YAML 配置文件指定插件应执行哪些任务。无论您添加到配置文件中的命令是什么，都将翻译为简单的英语：

“hey GitHub Actions, each time a PR is opened on X branch, automatically build and test the new change. And each time a new change is merged into or pushed to X branch, deploy that change to Y server.”

GitHub Actions 的核心有五个概念：jobs, workflows, events, actions, and runners。

5.1 Job

Job 是您通过 YAML 配置文件命令 GitHub Actions 执行的任务。作业可能类似于告诉 GitHub 操作来构建源代码、运行测试或将已构建的代码部署到某个远程服务器。例如，

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: Checkout
        uses: actions/checkout@v4.1.1
1
2
3
4
5
6
7
8
9
10
11

5.2 Workflow

Workflow本质上是包含一项或多项逻辑相关作业的自动化流程。例如，您可以将构建和运行测试作业放入同一工作流程中，将部署作业放入不同的工作流程中。

还记得吗，我们提到过您通过配置文件告诉 GitHub Actions 要执行哪些作业，对吗？GitHub Actions 将您放入存储库某个文件夹中的每个配置文件视为工作流程。

因此，要为部署作业创建一个单独的工作流程，然后创建一个结合构建和测试作业的不同工作流程，您必须将两个配置文件添加到您的存储库中。但是，如果您要将所有三个作业合并到一个工作流程中，那么您只需要添加一个配置文件。

5.3 Event

Event 实际上是触发 GitHub Actions 执行作业的事件。还记得我们提到过通过配置文件传递要执行的作业吗？在该配置文件中，您还必须指定何时执行作业。

例如，是否需要掌握 PR？它是一键掌握吗？是否正在合并掌握？当某些事件发生时，作业只能由 GitHub Action 执行。

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "master" branch
  pull_request:
    branches: ["master"]
  push:
    branches: ["master"]
1
2
3
4
5
6
7

好吧，让我赶紧纠正一下自己。在执行作业之前并不总是必须发生某些事件。你也可以安排工作。

例如，在您的配置文件中，您可以将其安排为每天凌晨 2 点发生，而不是指定应触发执行构建和测试作业的事件。事实上，您可以既安排作业又为同一作业指定事件。

5.4 Actions

Actions 是可重用的命令，您可以在配置文件中重用它们。您可以编写自定义操作或使用现有的操作。

例如，

- name: Checkout
  uses: actions/checkout@v4.1.1
1
2

5.5 Runner

Runner 是 GitHub Actions 用于执行您指示的作业的远程计算机。

# The type of runner that the job will run on
  runs-on: ubuntu-latest
1
2

例如，当基于某些事件触发构建和测试作业时，GitHub Actions 会将您的代码拉取到该计算机并执行该作业。

部署作业也会发生同样的情况。运行器触发将构建的代码部署到您指定的某个远程服务器。

让我们理解上面文件中的每一行。

• name: Android Build 这是我们工作流程的名称。当您导航到“操作”选项卡时，您定义的每个工作流程都将通过您在该列表中指定的名称来标识。
• on: 您可以在此处指定应触发工作流程执行的事件。在我们的配置文件中，我们向它传递了两个事件。我们指定主分支作为目标分支。
• jobs: 请记住，工作流程只是作业的集合。
• running-on GitHub 提供 Ubuntu Linux、Microsoft Windows 和 macOS 运行器来运行您的工作流程。您可以在此处指定要使用的运行器类型。在我们的例子中，我们使用 Ubuntu Linux 运行程序。

Job 由一系列 steps 组成，这些步骤通常在同一运行器上按顺序执行。在上面的文件中，每个步骤都用连字符标记。name代表步骤的名称。每个步骤可以是正在执行的 shell 脚本，也可以是一个 action。如果执行 action，则使用 use 定义步骤；如果执行 shell 脚本，则使用 run 定义步骤。

六、结论

GitHub Actions 是一款用于自动化 Android 开发流程的强大工具。凭借其丰富的 Marketplace 操作生态系统，您可以轻松构建复杂的工作流程，而无需编写任何代码。

但是，要充分利用 GitHub Actions，了解其工作原理以及如何使用 Marketplace actions 的基础知识非常重要。有了这些知识，您就可以快速轻松地创建自定义工作流程，以自动执行 Android 开发过程中的各种任务，例如构建、测试和部署应用程序。