移动应用开发中的发布日：本质、阶段与准备
发布日（release day）——计划发布移动应用新版本的日期，包括构建准备、商店审核、分阶段发布和监控。对于iOS应用，由于必须经过Apple审核，该过程从计划发布日期的24-48小时前开始，将构建上传到App Store Connect。对于Android——构建并上传到Google Play Console，审核过程通常需要1-4小时。根据Apple Developer Guidelines (2025)，90%的构建在24小时内通过审核。分阶段发布可以在发布后发现错误时最小化影响。
要点
- 发布日——从构建制作到发布后监控的一系列措施
- 分阶段发布——逐步推出：1%、10%、50%、100%
- 冒烟测试——构建发送到商店前的最终检查
- 回滚计划——为关键错误预先准备的撤回方案
- 发布回顾——在100%发布完成后分析过程
什么是发布日以及如何准备
发布日——不仅仅是按下发布按钮的那一刻。这是一个协调的过程，涉及开发人员、QA、运维、产品经理，有时还有支持团队。准备工作在发布日前2-3周开始：确定范围、代码冻结、回归测试、准备发布说明和营销材料。准备越充分，发布日本身就越顺利。
发布日的准备清单包括：在发布构建上执行最终QA运行（回归+冒烟测试套件）；检查商店中的元数据（名称、描述、截图、关键词）；与产品经理确认分阶段发布百分比；准备回滚计划（重新部署哪个标签，需要多长时间）；通知团队和相关服务即将进行的发布。发布检查清单应通过CI/CD自动化——例如，以GitHub Actions工作流的形式，在创建发布标签前检查所有项目。
准备的一个重要元素——封锁期（禁止部署到生产环境的时期）。通常在发布日48小时前引入封锁，并在成功100%发布后24小时解除。这可以防止可能干扰发布的意外部署。变更冻结在封锁期间适用于所有与发布相关的服务。
构建准备：代码冻结、标记和构建
在发布日前24-48小时引入代码冻结——完全停止代码更改。开发人员转向准备文档和发布说明。运维从固定的标签（例如v2.6.0-rc1）构建发布构建。构建经过完整的回归测试套件（自动+手动测试）。如果发现关键错误——在代码冻结前修复或延期发布。发布候选版本（RC）——通过QA并准备发送到商店的构建。
在Git中标记：创建带注释的标签（git tag -a v2.6.0 -m "Release v2.6.0"）。CI/CD管道为Google Play构建AAB（Android App Bundle），为Apple App Store构建IPA（iOS App Store Package）。构建附带：校验和文件（SHA256）、变更日志和已知问题列表。可重现构建——从相同标签重新构建产生二进制相同结果的理想实践。
bash
# 发布管道——创建标签和构建
# 假设代码冻结已激活
# 从develop创建发布分支
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# 代码冻结：分支保护规则阻止新的PR
# 在CI/CD中运行回归测试套件
./gradlew clean testReleaseUnitTest connectedReleaseTest
# 成功QA后创建发布标签
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# 通过CI/CD构建发布二进制文件
# fastlane build_release生成AAB + 通用APK
fastlane build_release重要：版本更新（更新version code和version name）在代码冻结前完成。代码冻结后版本不变。对于Android：versionCode——单调递增的整数；versionName——语义版本（2.6.0）。对于iOS：CFBundleVersion（构建号）和CFBundleShortVersionString（语义版本）。版本管理应在gradle/xcconfig中自动化。
上传到商店并通过审核
对于iOS：通过Xcode、Transporter或fastlane将构建上传到App Store Connect。上传后，构建经过Apple自动检查（处理），然后提交给人工审核。平均审核时间——24小时，但可能因Apple审核员的工作负荷和合规要求而异，从1小时到7天不等。加急审核——关键错误修复的加速审核请求（每月最多一次，不保证）。
对于Android：通过Google Play Console上传构建。Google采用组合方法：自动测试（可访问性、恶意软件、政策合规）+选择性人工审核。平均审核时间——1-4小时。内部测试轨道和封闭轨道允许在发布到生产轨道前进行最终测试。建议：内部测试1-2天→封闭测试1天→逐步生产发布。
对于两个平台，在上传构建前检查元数据至关重要：应用名称、描述（简短+完整）、每个支持设备的截图（iPhone 6.5英寸、5.5英寸、iPad、Android手机、平板）、关键词（iOS）或商店列表实验（Android）。元数据中的错误可能使审核延迟额外一天。应用元数据应本地化为所有支持的语言。
分阶段发布：如何无风险地推出发布
分阶段发布（逐步推出、分阶段部署）——新版本不立即对用户可用，而是分阶段逐步推出的策略。成熟团队的典型方案：1%用户（前2-4小时）→10%（24小时）→25%（24小时）→50%（24小时）→100%。每个阶段包括指标监控和检查无关键错误。分阶段发布——发布时最小化风险的主要工具。
Google Play Console提供内置的分阶段发布：可以指定用户百分比并计划逐步增加。iOS App Store Connect没有这样的内置功能——分阶段发布通过分阶段发布（在7天内自动增加覆盖范围，可暂停）或通过具有地理分布的服务器端功能标志实现。分阶段发布在App Store Connect中允许在发现问题时暂停发布。
进入下一阶段的关键指标：无崩溃率（新发布≥99.9%）、ANR率（Android，≤0.1%）、后端API错误率（≤0.5% 5xx）、用户评分（不低于上一版本）、apdex得分（≥0.94）。如果任何指标超出阈值——发布暂停，直到查明原因。继续/停止门控在每个阶段——发布经理或值班工程师的责任。
发布后监控：最初几小时关注什么
发布后的前4小时——最关键的时间。团队监控崩溃率（Sentry、Firebase Crashlytics、App Center）、后端5xx错误率、自定义事件（成功支付、登录、注册）、App Store和Google Play中的用户评分、社交媒体提及（Twitter、Reddit）。监控仪表板应提前准备好，并在办公室的大屏幕上或专用Slack频道上可用。发布仪表板——发布所有指标的统一窗口。
特别关注——回归指标：与上一版本在类似时期的崩溃率比较。如果崩溃率增加超过0.1%——这是一个需要立即分析的红旗。同样重要的是比较关键API端点的中位数和p95延迟：即使没有崩溃，响应时间减慢200ms可能表明存在问题。指标比较（基线vs当前）在Datadog或Grafana中自动化。
用户反馈——与数字指标同样重要。发布后的最初几小时，用户积极在商店留下评论并联系支持。测试未捕获的错误很快在评论中出现。团队负责人或指定的QA工程师在前4小时内每30分钟监控评论并分类：误报、已知问题（已在已知问题列表中）、新错误。P0/P1新错误——暂停发布的触发器。
回滚：何时以及如何撤回发布
回滚——在发现关键问题时回退到上一个稳定版本。回滚决定由发布经理与技术负责人共同做出，如果：新发布的无崩溃率降至99%以下、发现数据泄露、关键功能（支付、授权）对超过5%的用户不可用、或商店（App Store审核）在发布后拒绝了构建。回滚触发条件应在发布前确定，以便决策基于事实而非情绪。
对于Android：在Google Play Console中回滚——停止分阶段发布并切换到先前版本。如果当前构建已在100%用户中——将先前版本作为新发布发布。对于iOS：通过App Store Connect——分阶段发布→暂停发布→发布带有修复的新版本（App Store不允许回退到先前版本）。iOS回滚更复杂：开发人员需要使用还原提交构建新构建并重新通过审核。
回滚后，团队进入事件模式：根本原因分析、热修复或带有修复的下一个版本、事后分析。回滚——不是失败，而是标准程序。从未执行过回滚的团队可能没有注意到问题，而不是发布无错误版本。回滚率——DORA指标之一：高绩效团队在不到10%的发布中执行回滚，并在不到1小时内恢复。
常见问题
发布移动应用最好选择哪一天？
最好的日子——周二、周三或周四。周一——周末后流量高，周五——带着有问题的发布进入周末的风险。避免周五：如果部署后发现有问题，团队将在周末修复或等到周一。
如果App Store审核拒绝构建怎么办？
在Resolution Center中阅读拒绝原因，修复并重新上传构建。常见原因：链接无效、字段未填写、没有订阅的内容（如果需要）、过时的截图。App Store审核拒绝会延迟发布24-48小时，因此首次构建上传应在计划发布日期的3-5天前进行。
开始时最优化分阶段发布百分比是多少？
对于大型发布（重大变更）——1%。对于补丁发布——5-10%。第一阶段应该足够小，以便在发生错误时影响最小，但足够大以获得统计显著的指标。1%对于有1000万用户的应用——10万人，足以发现关键问题。
需要举办发布派对吗？
发布派对（团队庆祝）——可选，但对士气有益。最好在成功100%发布后举行，而不是在上传构建时。发布庆祝可以与发布回顾结合，讨论哪些方面做得好，哪些可以改进。
谁负责决定“发布还是推迟”？
责任在于发布经理（通常是高级工程师或技术负责人）。决定基于发布仪表板的数据，而不是基于截止日期。发布经理有权在指标未通过继续/停止门控时推迟发布。
总结
- 发布日——从代码冻结到发布后监控的协调过程
- 准备——发布候选版本、QA运行、元数据检查、回滚计划
- 分阶段发布——1%→10%→25%→50%→100%，每个阶段有继续/停止门控
- 监控——前4小时的无崩溃率、ANR、5xx错误率、用户评分
- 回滚——无崩溃率降至99%以下时的标准程序
- 沟通——发布前后通知团队和利益相关者
- 发布回顾——100%发布完成后分析过程
我们将开发一款交钥匙移动应用程序
IT Sectr自2017年以来为初创企业和企业打造iOS和Android应用程序。我们将为您提供咨询并提出最佳解决方案。
另请阅读