iOS紧急发布实践心得

  由于去年项目中并没有进行单元测试，加上团队成员较多，测试人员有限。后期测试，虽然经过了开发人员的自测，测试人员的测试，但仍然无法保证代码测试的覆盖率，会导致在线bug的产生，对于紧急发布，经常会存在被拒绝的情况。

一，什么时候选择紧急发布最合适？

  不知道大家有没有这样的经历，每天被邮件轰炸，被电话轰炸。往往发生线上的bug时候，公司越大，我们被轰炸的越惨，而且不过不能快速通过审核的话，又会经常影响我的KPI。根据前几次紧急发布的经历，一般情况下选择在晚上紧急发布，顺利通过审核的情况下，第二天早上就可以看到app新版本了。

二，选择什么理由最合适？

   首先我们优先选择崩溃，影响用户正常使用的理由，或者选择某些功能模块跟政府有合作关系，政府要推广某些事情，比如和政府合作缴纳养老保险，医疗保险。学生上学的学费等。基本都是OK的。另外言语要尽量的客气，礼貌。审核人员有千万个理由可以拒绝掉你的app，毕竟解释权归苹果所有。

三，尽量减少紧急发布的次数

   虽然我们这边进行了几次紧急发布，都顺利的通过了审核，但是我们并不能把所有的希望都放在紧急发布上，我们仍然要采取必要的措施来减少紧急发布的次数，首先要采取白盒测试—单元测试，来保证我们的代码质量， 保证我们的代码覆盖率。其次即使出了问题我们仍然可以用jspatch来热修复。后续我这边会分别推出单元测试系列的博客，和热修复系列的博客。