小步快跑的 APP 发布流程

image

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

登记班车

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

image

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

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

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

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

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

上班车

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

image

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

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

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

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

内测

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

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

1
2
> 内测阶段依然可以改 bug,改的越多说明提测质量越低
>

提审

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

image

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

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

发版流程

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

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

image

参考

感谢您的阅读,本文由 晚码工作室 版权所有。如若转载,请注明出处:晚码工作室(https://latehorse.github.io/2018/10/16/The-app-release-process-of-Quick-Run/
梦想虽晚,“码”不停蹄