安卓持续集成与交付#

#Android持续集成与交付

本文档概述了 Android 部署项目的持续集成 (CI) 和持续交付 (CD) 流程。我们使用 GitHub 操作 作为我们的 CI/CD 平台，配置了许多工作流程以确保代码质量、自动化构建和简化。

#概述

我们 CI/CD 流程的主要目标是：

• ✅ 验证一切都按预期运行。
• 🚨如果出现问题，通知相关人员。
• 🚀 实现应用程序的持续交付。
• 🔄通过将公共代码提取到.github/actions下的可重用本地中操作来避免重复。

#版本控制

我们遵循与核心项目相同的版本控制规定，使用CalVer（日历版本控制）。这确保了所有版本的一致性。

#工作流程

#根据拉取请求

当拉取请求(PR)打开或更新时，pr.yml工作流程将被触发。其目标是：

• 🧹验证代码是否符合我们的linters。
• 🔨确保代码构建成功。
• ✅ 运行所有测试以验证正确性。
• 📦 将生成的 APK 保留在 GitHub Actions 选项卡中以供审核。

如果步骤任何失败：

• CI 通知 PR 业主。
• 在问题得到解决之前，PR 将被阻止合并。
• 必须提交修复，这会自动重新启动工作流程。

#调试版本

为了在 CI 上调试应用程序，我们使用位于 /.github/mock-google-services.json 的模拟 Google 服务文件。

#从拉取请求下载 APK

有关如何从拉取请求下载和安装APK的说明，请参见Testing pull request builds提示。

#工人到main

当提交被主动到main分支时，onPush.yml工作流程被触发。其目标是：

• 🌐来自Lokalise 下载翻译。
• 📝生成发行说明。
• 🔧 构建所有应用程序的发布变体。
• 📤 将应用程序部署到 Firebase。
• 🛒 部署到 Play 商店的内部轨道。
• 📦将生成的APK保留在GitHub Actions选项卡中。
• 🔐注入发布所需的机密和文件。

我们使用Fastlane来简化到不同商店的部署。所有Fastlane配置都可以在fastlane文件夹中找到。

#每周构建

每个星期日凌晨 4:00 UTC，weekly.yml 工作流程都会自动触发。其目标是：

• 🛠创建每周 GitHub 预发布。
• 🚀 调用onPush.yml 工作流程，并将beta 标志设置为true。

这确保了每周都会将新版本的应用程序主动程序到 Play 商店的测试版本中。

#每月版本标签

每个月的第一天，monthly.yml 工作流程都会运行以创建 YYYY.MM.0 格式的初始版本标签。这符合我们的 CalVer 版本控制策略。

#发布

release.yml 工作流程是手动触发的，只有将最新的测试版本升级到生产环境。这确保了稳定性并且经过测试的版本才会发布给最终用户。

#在F-Droid上发布

当我们积极参与 GitHub 版本时，F-Droid 商店会自行构建应用程序。此过程使用metadata。

每个 GitHub 版本都包含 F-Droid 使用的以下文件：

• version_code.txt - 用于应用程序的版本控制（在main分支的版本每个上创建）
• strings.zip - 包含构建时 Lokalise 的所有应用程序翻译
• locales_config.xml - 从下载的应用程序翻译生成locales configuration

#在预发布或每月标签上

当在pre-release状态下创建发布或每月每月标签时，会触发prepareNextRelease.yml工作流程。此工作流程创建一个拉取请求，更新changelog_master.xml以文件反映新版本。需要手动批准此拉取请求。此过程有助于保持变更日志版本与应用程序版本一致。

#工作流程摘要

---

#观点和最佳实践

• 🛠 将公共代码提取到.github/actions 下的可重用操作中，居民重复。
• 🕒 注意工作流程消耗，占用的资源使用。
• 🔒确保机密和敏感文件在工作流程中得到正确的管理和输入。