小步快跑的 APP 发布流程

[yuhanle]

需求评审-技术评审-开发-联调-测试-回归，我们需要在一些分支上穿梭，达到高效率、高质量完成任务

登记班车

这个周期一般为 10PD，根据节假日顺延

比如接到一个新的 featrue，你需要开出一个新的分支，如 feature/xx 。

如果有 task 号，分支名称中可包括 task 号，若无，则用较清晰的英文表述。

后面，同学们各自驰骋在自己的分支上。

* 在 feature-a 测试结束后，A 同学需要合入班车，即将代码合入到 devlop 上
* B 同学的需求还在继续，需要将代码 rebase 到 develop 最新的那次提交
* B 继续开发直到测试结束，合入班车

这个阶段，交付给 QA 的测试包，需要在分支上打好，配置是 staging，并告知相应 QA 测试

上班车

当登记到班车里所有的需求都 确认 完成后，我们会在 develop 分支上开出 release 分支，如 release/7.2.0。

这个阶段，可能有新的需求开始过来，开发需要做以下几件事情：

* 关注 bugly 上的问题
* 新的需求可能会上来
* 修复 QA 回归出的问题

从这个阶段开始，需要打 production 包给 QA，若不确认问题是否修复，建议仍在 bugfix 分支上打包，验证 ok 后再合入 release 也可以

后续 release 较为稳定后，定期会 merge 回 develop，保持 develop 的代码最新。

内测

是否需要提内测，等 QA 通知

QA 问题回归结束，需要打包提交到 testflight 上公测，公测需要 apple 审核。需要注意的是：关闭内购功能

内测阶段依然可以改 bug，改的越多说明提测质量越低

提审

内测阶段的问题不会很多，结束后，QA 会通知打最新的 release 包，QA 的职责到此结束。开发需要将代码合入到 master，并打上相关 tag 号

接着通知产品，告知版本号，产品根据这个去提审

开发打包完成后，需要在大群里周知

发版流程

开发阶段的每次打包，都需要周知到相关人员，最终的 release 包需要在大群周知。

• 回归阶段打包通知 QA 测试即可
• 回归完毕后，QA 会通知开发打内测包，有 QA 提交内测审核（内测需关闭支付）
• 最终 QA 会通知 开发打提审包
• 开发操作完成后，由产品提审

参考

• https://tech.meituan.com/2019/01/10/traffic-git-branch-management.html