作者 | Sergio De Simone
译者 | 明知山
策划 | 丁晓昀
DoorDash 公司的移动应用发布流程 基于团队间明确的分工职责、有效的沟通、测试以及严格的回归问题处理和紧急修复规则。DoorDash 工程师 Manolo Sañudo 解释说，尽管并非所有的企业都具备 DoorDash 这样庞大的规模，但他们的解决方案的许多方面对规模较小的企业也有所帮助。
DoorDash 遵循的是相对简单的周发布周期。每个新的发布候选版本都会有一个发布分支，经过为期一周的测试和修复过程，最终正式发布。
每个新的发布候选版本都会分配一个发布经理来监督整个过程，确保一切顺利进行。发布经理的人员池要足够大，不会出现有人被工作量所拖累的情况，但也不至于过大，以至于无法跨各个发布版本做出一致的决策，或者危及发布流程的发展和改进。
每个发布候选版本都有自己的 Slack 频道，便于将状态更新和会话集中到一个地方，防止生产环境的漏洞热修复产生噪音。
对于测试，Sañudo 表示，由于无法在一周内进行完全的回归测试，因此“组件所有者”会单独负责测试所有组件，并使用移动发布管理平台 Runway 来跟踪测试状态。
每个组件所有者需要在批准组件之前执行特定的测试任务。在提交评审之前，每个组件都必须得到批准。
Sañudo 表示，在测试阶段会不时地发现回归问题。在这种情况下，发布经理与受影响的团队合作修复问题，并推送到主开发分支，只有当回归影响用户体验时，这个修复才会被合并到发布候选分支上。在这个阶段，既不允许出现对用户没有影响的 bug，也不允许添加新特性，每个精心挑选的修复都必须经过团队的论证，并由发布经理批准。
如果在流程的后期发现了漏洞，即在应用程序提交审核之后，甚至会采取更严格的规则，因为实施热修复可能会导致发布延迟。
虽然更新还没有发布，但可能正在等待评审或已经获得批准，要实施修复，我们将不得不拒绝构建并重新提交应用程序。因为这可能会导致延迟发布，我们会根据具体情况评估修复是否值得以及如何根据具体情况进行修复。
在获得苹果公司的批准后，新版本将向 1% 的用户发布，确保没有出现重大问题，并在几天后推向整个用户群。在这个阶段，团队使用一些关键指标来了解新版本的组件可能出现的问题。同样，发布经理使用 Sentry 跟踪更高级别的指标，如崩溃率和趋势性问题。
英文原文：
https://www.infoq.com/news/2023/12/doordash-mobile-release-process/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
