Bangumi 的完整发布流程:从本地构建到商店上架-育师

Bangumi 的完整发布流程:从本地构建到商店上架

【免费下载链接】Bangumi:electron: An unofficial https://bgm.tv ui first app client for Android and iOS, built with React Native. 一个无广告、以爱好为驱动、不以盈利为目的、专门做 ACG 的类似豆瓣的追番记录，bgm.tv 第三方客户端。为移动端重新设计，内置大量加强的网页端难以实现的功能，且提供了相当的自定义选项。目前已适配 iOS / Android。项目地址: https://gitcode.com/GitHub_Trending/ba/Bangumi

Bangumi 是一个用 React Native 编写的 bgm.tv 追番记录客户端,无广告、以爱好驱动,为移动端重新设计了交互。这篇文章按一次真实发布的时间线,讲清它的发布流程:发布前要备什么、怎么构建出双端正式包、如何把上架变成一键操作、发出去之后盯什么。面向想给自己的项目做版本发布、但不熟悉 DevOps 的开发者,照着走一遍即可。

发布前:版本号、补丁与商店文案一次备齐

发布翻车很少翻在打包那一步,大多翻在前置准备。把这三件事先钉死,后面的构建和上架就只剩机械操作。

1.1 版本号只认一个来源

版本号散落在多处是双端应用最常见的坑。Bangumi 的做法是把version和versionCode都写死在 app.json 里,Android 侧的 build.gradle 在构建时执行一段 node 命令动态读取它注入到 APK。改一处,双端同步,永远不会出现"Android 是 8.40、iOS 是 8.39"的错位。

1.2 第三方补丁随安装固化

项目对 render-html、tab-view 等依赖打了私有补丁,补丁文件放在packages/patches及分平台目录下,并通过postinstall钩子执行 patch-package 自动应用。这意味着任何人拉下代码装完依赖,补丁状态一定一致,不需要手动记忆"哪个包改过哪里"。

1.3 商店文案与更新日志提前落盘

商店上架需要简介、完整描述和截图,这些素材不该等审核期才赶工。项目把中英文商店文案放在 fastlane 元数据目录里,更新日志则统一记在 web/CHANGELOG.MD,按版本倒序记录优化与修复。发版时顺手把日志摘一段就是商店文案,素材永远比发布时间早一步到位。

发布前检查清单

version按语义化版本递增,versionCode同步上调
依赖补丁已随安装生效,与packages/patches目录内容一致
单元测试与 lint 全部通过
双端正式包在真机上跑通登录、追番、浏览三条主流程
商店文案和更新日志已写好待用

📦 构建第一个正式包:双端各跑一遍

拿到一个能装进手机里的 release 包。原则是:测试不绿不打包,包出来先真机验证再谈分发。

2.1 先过测试,再谈打包

运行yarn test执行 jest 全量单测。项目还配了自定义 eslint 规则(放在eslint-rules目录,专门约束样式写法与导入规范),打包前跑一遍 lint,把能在代码阶段暴露的问题挡在构建之前。

2.2 Android:一条命令出 release 包

在android目录执行./gradlew assembleRelease即可生成签名的 release APK。构建脚本里只保留了 arm64-v8a 一种 ABI,包体比全量架构小一圈;debug 与 release 使用不同签名配置,调试包不会被误传出去。

2.3 iOS:xcodebuild 出包,脚本打成 IPA

iOS 侧由build:ipa脚本调用 xcodebuild 以 Release 配置编译真机产物,再由make:ipa脚本把产物 zip 成未签名的 IPA。未签名是刻意的:它会被后续侧载工具或签名流程二次签名,构建本身不绑定任何证书,谁拿到包都能用。

把上架变成一键操作

手动传包上架又慢又容易出错,这一层的目标是让"发布"退化成敲一条命令。

3.1 EAS 三档 profile 各管一段

eas.json 定义了 development、preview、production 三档构建档位:development 给调试客户端用,preview 走内部分发,production 绑定 production 频道。正式版推送到生产频道只需执行yarn pub,它本质是eas update --channel production,一条命令完成 OTA 更新推送。

3.2 商店与侧载,两条路并行

Android 走常规商店路径,fastlane 元数据就绪后可直接提交。iOS 因审核原因长期走侧载:每打一个版本 tag,CI 自动构建未签名 IPA 并更新 alt_store.json 源文件,用户通过 AltStore 添加源即可安装,配套说明见web/ALTSTORE-USAGE.md。两条路共用同一份构建产物,只是分发渠道不同。

发出去之后:让反馈形成闭环

发布不是终点,没有反馈闭环,下个版本等于闭着眼做。

4.1 更新日志就是下一版的任务单

web/CHANGELOG.MD 里每个版本都分"优化"与"修复"两栏。商店评价、崩溃报告、issue 里的高频抱怨,都应归并进下一版的这份日志。日志写得越具体,回归测试就有据可依,版本之间的差异也能一眼说清。

4.2 用应用内统计观察真实使用

Bangumi 自带年度统计功能,能看到用户的追番分布和活跃度:

这类数据加上商店评分,构成判断"这次发布是否成功"的基本依据。

发布流程的价值不在某一次发版,而在它被重复一百次之后依然稳定。把版本号、测试、构建、分发都固化成配置,人只做决策不做搬运,项目才能持续以每周一个版本的节奏往前走。接下来值得做的,是把侧载渠道的签名环节也自动掉,让整条链路彻底无人值守。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Bangumi 的完整发布流程:从本地构建到商店上架