DoorDash移动应用发布流程总结

DoorDash的移动应用发布流程基于明确的团队分工、有效沟通、严格的测试以及处理回归和热修复的规则。虽然并非所有组织都像DoorDash一样大规模运作，但其方法中的许多方面对小型组织也很有借鉴意义。

发布周期与发布经理

DoorDash采用每周发布一次的周期。每次发布候选版本都会创建一个发布分支，经过一周的测试和修复，最终正式发布。每个发布候选版本都有一名发布经理负责监督整个过程，确保顺利进行。发布经理的数量足够多，以避免个人负担过重，但又不会过多，以确保决策一致性和发布流程的持续改进。

沟通与测试

每个发布候选版本都有专门的Slack频道，用于集中状态更新和讨论，防止生产环境中的热修复产生噪音。由于无法在一周内完成完整的回归测试，DoorDash引入了“组件负责人”（component owners），他们负责单独测试所有组件，并使用移动发布管理平台Runway跟踪测试状态。每个组件负责人在批准组件之前必须运行特定的测试，所有组件都必须经过批准后才能提交发布审查。

回归与热修复

在测试阶段，偶尔会发现回归问题。此时，发布经理与受影响的团队合作开发修复方案，并将其推送到主开发分支，但只有在回归问题影响用户体验时，修复才会合并到发布候选分支。不影响用户的错误和新功能不允许在此阶段引入，每个精选修复都必须由团队说明理由并由发布经理批准。

如果在应用提交审查后发现错误，规则更加严格，因为实施热修复可能会导致发布延迟。尽管更新尚未公开，但可能正在等待审查或已获批准；实施修复需要拒绝构建并重新提交应用。因此，DoorDash会根据具体情况评估是否值得修复以及如何实施。

发布与监控

在获得苹果公司的批准后，新版本会先向1%的用户推出，以确保没有重大问题出现。几天后，再扩展到所有用户。在此阶段，团队使用关键指标来了解新版本中组件可能出现的问题。发布经理则使用Sentry跟踪更高级别的指标，如崩溃率和任何趋势性问题。

通过这一系列严谨的流程，DoorDash确保了其移动应用的高质量和稳定发布。