2026/9/18 14:49:48
FEATURED · 精选文章 
Timeline Visualizer发布工作流从代码提交到APK/AAB的完整过程【免费下载链接】google-timeline-visualizerVisualize your year in travel using your Google Location History (Timeline) data项目地址: https://gitcode.com/GitHub_Trending/go/google-timeline-visualizerTimeline Visualizer 是一款将 Google 位置历史Timeline数据转化为动画旅行视频的 Android 应用。本文带你完整看懂它的发布工作流一次代码提交后自动化流水线如何测试、构建签名 APK/AAB、校验版本并最终发布到 GitHub Release 与 Google Play。即使是刚接触 CI/CD 的新手也能顺着这条主线理解一个生产级 Android 项目的发布全貌。工作流全景7 个自动化的分工所有 CI/CD 逻辑都集中在.github/workflows/目录按职责拆分为 7 个工作流工作流触发时机职责validate.yml提交到 main / PR单元测试、Lint、三渠道构建、真机冒烟preflight.yml提交到 main / PRGitleaks 密钥泄漏扫描web-validate.yml改动web/**Web 端安装、测试、构建workflow-lint.yml改动工作流文件用 actionlint 检查工作流语法pages.ymlweb 改动 / 发布完成部署 Web 应用到静态站点release.yml推送v*标签正式 APK/AAB 发布主线journal-lab.yml推送journal-lab-*标签实验版Lab不可变构建第一道防线提交即验证每次改动 main 分支validate.yml 会并行跑三组任务Android 任务JDK 17 Android SDK 环境下执行testGithubDebugUnitTest testPlayDebugUnitTest lint assembleGithubDebug assemblePlayDebug assembleJournalLabDebug覆盖 github / play / journalLab 三个渠道flavor的测试与构建Python 任务python -m pytest运行 tests/ 下的 13 个仓库级测试真机冒烟在 Android API 28 / 35 / 36 三档模拟器上跑connectedGithubDebugAndroidTest确保最低到最高支持的系统都能启动。与此同时preflight.yml 会用校验过 SHA-256 的 Gitleaks 二进制做增量密钥扫描——任何误提交的签名口令或 API Key 都会被直接拦下workflow-lint.yml 则保证工作流文件本身语法正确。这套“提交即验证”的机制让能进入发布环节的代码天然就是可信的。发布触发一个 v 开头标签就是一切正式版本由推送v*标签触发release.yml 的on.push.tags: v*。版本号不是写在流水线里的而是集中在 app/build.gradle.ktsversionCode 58 versionName 3.0.16因此发版动作就是两步改这两个值 → 推送对应标签如v3.0.16。标签名去掉v后必须与versionName完全一致这一点后续会被流水线强制校验。发布流水线签、构、验、发四步第 1 步签名密钥与构建流水线从仓库 Secrets 中还原发布签名密钥.jks然后执行核心命令./gradlew test lint assembleGithubRelease bundlePlayRelease这一条命令同时产出两个分发渠道distributionflavor 维度github 渠道→ 签名后的app-github-release.apk直接安装包play 渠道→app-play-release.aabPlay Console 应用包体积更小的 bundle。Release 构建同时开启混淆与资源压缩proguard-rules.pro并注入CARTO_BASEMAP_API_KEY地图密钥确保公开产物不含任何开发者本地密钥。第 2 步发布前强制验证Verify before Publish这是整条流水线最值得学习的设计任何产物先验证、后发布。release.yml 的验证步骤会用apksigner verify --print-certs确认定向签名有效用aapt dump badging解出包名断言等于dev.mahlernim.timelinevisualizer交叉比对 APK 内的versionCode/versionName与 build.gradle.kts 及标签名三者一致防止“版本号漂移”打印sha256摘要供用户校验。第 3 步发布到 GitHub Release验证通过后流水线生成三个产物TimelineVisualizer-tag.apk—— 用户可直接下载安装的安装包apk.sha256—— 校验文件update.json—— 内含versionCode、versionName、releaseUrl是应用内更新检测见 DistributionUpdateManager.kt读取的元数据。若标签已存在例如手动触发workflow_dispatch指定旧标签流水线会用--clobber覆盖更新该 Release而不是报错首次发布则以 docs/release-notes-*.md 作为发布说明创建 Release。第 4 步Play 渠道产物移交app-play-release.aab不会自动上传 Play Console而是以 Artifact 形式保存 30 天release.yml由开发者下载后手动提交配合 play-store/ 目录中的商店文案、截图与素材完成上架。特殊分支Journal Lab 不可变构建journal-lab.yml 服务于实验性功能分支有两个独特机制身份隔离Lab 版包名是dev.mahlernim.timelinevisualizer.journallab流水线会验证它与正式版签名证书一致但包名不同从而可在同一台设备上共存安装流水线在模拟器上真实执行了“装正式版 → 装旧 Lab 版 → 升级新 Lab 版”的完整流程不可变性Release 一经创建就拒绝覆盖already exists and will not be replaced保证实验版历史可随时回溯对比。收尾Web 端联动与“测试流水线本身”Android 发布成功后pages.yml 会重新构建 Web 版iPhone 网页应用并通过 web/scripts/resolve-apk.mjs 把最新稳定 APK 的下载地址注入网页——手机版发布网页版同步更新。更巧妙的是仓库把“流水线自身”也纳入测试tests/test_release_workflow.py 用 pytest 断言Verify signed GitHub APK步骤一定位于Publish GitHub release之前、断言update.json元数据字段齐全、断言.gitattributes将 apk/aab 等二进制按binary !eol处理避免换行符污染。流水线改坏了测试会先红。总结一张图看懂发布全流程阶段动作关键文件提交验证测试 Lint 三渠道构建 模拟器冒烟 密钥扫描validate.yml、preflight.yml版本声明修改 versionCode / versionNamebuild.gradle.kts触发发布推送v*标签release.yml构建产物签名 APKgithub 渠道 AABplay 渠道proguard-rules.pro强制验证签名、包名、版本号三方一致release.yml#L46-L64发布Release sha256 update.json支持覆盖更新release.yml#L72-L97收尾Web 端联动部署、Play 产物保存 30 天pages.yml这套工作流的核心哲学值得借鉴标签即版本、验证先于发布、产物可回溯、流水线本身可测试——四句话构成了从代码提交到用户手中 APK/AAB 的完整闭环。【免费下载链接】google-timeline-visualizerVisualize your year in travel using your Google Location History (Timeline) data项目地址: https://gitcode.com/GitHub_Trending/go/google-timeline-visualizer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Timeline Visualizer发布工作流：从代码提交到APK/AAB的完整过程
Timeline Visualizer发布工作流从代码提交到APK/AAB的完整过程【免费下载链接】google-timeline-visualizerVisualize your year in travel using your Google Location History (Timeline) data项目地址: https://gitcode.com/GitHub_Trending/go/google-timeline-visualizerTimeline Visualizer 是一款将 Google 位置历史Timeline数据转化为动画旅行视频的 Android 应用。本文带你完整看懂它的发布工作流一次代码提交后自动化流水线如何测试、构建签名 APK/AAB、校验版本并最终发布到 GitHub Release 与 Google Play。即使是刚接触 CI/CD 的新手也能顺着这条主线理解一个生产级 Android 项目的发布全貌。工作流全景7 个自动化的分工所有 CI/CD 逻辑都集中在.github/workflows/目录按职责拆分为 7 个工作流工作流触发时机职责validate.yml提交到 main / PR单元测试、Lint、三渠道构建、真机冒烟preflight.yml提交到 main / PRGitleaks 密钥泄漏扫描web-validate.yml改动web/**Web 端安装、测试、构建workflow-lint.yml改动工作流文件用 actionlint 检查工作流语法pages.ymlweb 改动 / 发布完成部署 Web 应用到静态站点release.yml推送v*标签正式 APK/AAB 发布主线journal-lab.yml推送journal-lab-*标签实验版Lab不可变构建第一道防线提交即验证每次改动 main 分支validate.yml 会并行跑三组任务Android 任务JDK 17 Android SDK 环境下执行testGithubDebugUnitTest testPlayDebugUnitTest lint assembleGithubDebug assemblePlayDebug assembleJournalLabDebug覆盖 github / play / journalLab 三个渠道flavor的测试与构建Python 任务python -m pytest运行 tests/ 下的 13 个仓库级测试真机冒烟在 Android API 28 / 35 / 36 三档模拟器上跑connectedGithubDebugAndroidTest确保最低到最高支持的系统都能启动。与此同时preflight.yml 会用校验过 SHA-256 的 Gitleaks 二进制做增量密钥扫描——任何误提交的签名口令或 API Key 都会被直接拦下workflow-lint.yml 则保证工作流文件本身语法正确。这套“提交即验证”的机制让能进入发布环节的代码天然就是可信的。发布触发一个 v 开头标签就是一切正式版本由推送v*标签触发release.yml 的on.push.tags: v*。版本号不是写在流水线里的而是集中在 app/build.gradle.ktsversionCode 58 versionName 3.0.16因此发版动作就是两步改这两个值 → 推送对应标签如v3.0.16。标签名去掉v后必须与versionName完全一致这一点后续会被流水线强制校验。发布流水线签、构、验、发四步第 1 步签名密钥与构建流水线从仓库 Secrets 中还原发布签名密钥.jks然后执行核心命令./gradlew test lint assembleGithubRelease bundlePlayRelease这一条命令同时产出两个分发渠道distributionflavor 维度github 渠道→ 签名后的app-github-release.apk直接安装包play 渠道→app-play-release.aabPlay Console 应用包体积更小的 bundle。Release 构建同时开启混淆与资源压缩proguard-rules.pro并注入CARTO_BASEMAP_API_KEY地图密钥确保公开产物不含任何开发者本地密钥。第 2 步发布前强制验证Verify before Publish这是整条流水线最值得学习的设计任何产物先验证、后发布。release.yml 的验证步骤会用apksigner verify --print-certs确认定向签名有效用aapt dump badging解出包名断言等于dev.mahlernim.timelinevisualizer交叉比对 APK 内的versionCode/versionName与 build.gradle.kts 及标签名三者一致防止“版本号漂移”打印sha256摘要供用户校验。第 3 步发布到 GitHub Release验证通过后流水线生成三个产物TimelineVisualizer-tag.apk—— 用户可直接下载安装的安装包apk.sha256—— 校验文件update.json—— 内含versionCode、versionName、releaseUrl是应用内更新检测见 DistributionUpdateManager.kt读取的元数据。若标签已存在例如手动触发workflow_dispatch指定旧标签流水线会用--clobber覆盖更新该 Release而不是报错首次发布则以 docs/release-notes-*.md 作为发布说明创建 Release。第 4 步Play 渠道产物移交app-play-release.aab不会自动上传 Play Console而是以 Artifact 形式保存 30 天release.yml由开发者下载后手动提交配合 play-store/ 目录中的商店文案、截图与素材完成上架。特殊分支Journal Lab 不可变构建journal-lab.yml 服务于实验性功能分支有两个独特机制身份隔离Lab 版包名是dev.mahlernim.timelinevisualizer.journallab流水线会验证它与正式版签名证书一致但包名不同从而可在同一台设备上共存安装流水线在模拟器上真实执行了“装正式版 → 装旧 Lab 版 → 升级新 Lab 版”的完整流程不可变性Release 一经创建就拒绝覆盖already exists and will not be replaced保证实验版历史可随时回溯对比。收尾Web 端联动与“测试流水线本身”Android 发布成功后pages.yml 会重新构建 Web 版iPhone 网页应用并通过 web/scripts/resolve-apk.mjs 把最新稳定 APK 的下载地址注入网页——手机版发布网页版同步更新。更巧妙的是仓库把“流水线自身”也纳入测试tests/test_release_workflow.py 用 pytest 断言Verify signed GitHub APK步骤一定位于Publish GitHub release之前、断言update.json元数据字段齐全、断言.gitattributes将 apk/aab 等二进制按binary !eol处理避免换行符污染。流水线改坏了测试会先红。总结一张图看懂发布全流程阶段动作关键文件提交验证测试 Lint 三渠道构建 模拟器冒烟 密钥扫描validate.yml、preflight.yml版本声明修改 versionCode / versionNamebuild.gradle.kts触发发布推送v*标签release.yml构建产物签名 APKgithub 渠道 AABplay 渠道proguard-rules.pro强制验证签名、包名、版本号三方一致release.yml#L46-L64发布Release sha256 update.json支持覆盖更新release.yml#L72-L97收尾Web 端联动部署、Play 产物保存 30 天pages.yml这套工作流的核心哲学值得借鉴标签即版本、验证先于发布、产物可回溯、流水线本身可测试——四句话构成了从代码提交到用户手中 APK/AAB 的完整闭环。【免费下载链接】google-timeline-visualizerVisualize your year in travel using your Google Location History (Timeline) data项目地址: https://gitcode.com/GitHub_Trending/go/google-timeline-visualizer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
