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/BangumiBangumi 是一个用 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 出包,脚本打成 IPAiOS 侧由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 自带年度统计功能,能看到用户的追番分布和活跃度:这类数据加上商店评分,构成判断这次发布是否成功的基本依据。发布流程的价值不在某一次发版,而在它被重复一百次之后依然稳定。把版本号、测试、构建、分发都固化成配置,人只做决策不做搬运,项目才能持续以每周一个版本的节奏往前走。接下来值得做的,是把侧载渠道的签名环节也自动掉,让整条链路彻底无人值守。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考