保障应用顺利发布的思考

业务不断的有需求，应用则要不断的迭代发布，而线上出现问题很大的一个原因是因为变更导致。

90%以上的线上问题都是由变更引发，这也是为什么集团安全生产的重点一直是在管控“变更”。所以，先不要急着否认（“肯定不是我刚加的那行代码问题！”），相信统计学概率，好好review下近期的变更历史（从近至远）。

应用发布作为比较大的变更，一旦出现问题，造成的影响非常严重，因此应用发布一定要顺利保障。怎么保障呢？ 参考集团内已经有很多经验及要求，说一下自己的一些经验想法

原则 - 可灰度，可监控，可回滚

大家应该都听过这个要求，可灰度，可监控，可回滚，但是可能稍微有点抽象，到一线开发人员身上时，有一点点问题。

怎么灰度？

• 如何配置灰度环境？

怎么监控？

• 有什么监控工具？
• 要监控什么内容？

可回滚：

• 怎么样快速回滚？

还有在发布之前怎么做好功能测试， 确保发布没问题？有很多时候，因为人力原因，只能开发自测，那么开发对必要的测试手段还是需要了解的。

工具

集团内有很多有效的工具，一些没有开源，但是思路都类似，可以根据公司内部的一些工具做如上对照。

...

开发自测注意点

上面提到因为人力原因，有时候只能开发自测，必要的测试手段还是需要的。我发现有时候一些点还是会忘掉，或者说如果每次都是开发自测有一定的效率问题。现在就是想到三个点：

• 想一下自己的业务核心要关注的点是什么，当前支持的业务有哪些。比如说Push有哪些种类(产品，营销，订阅等)，而针对Push要测的主要点是什么？(标题内容，图片，地址)。
• 做自动化测试工具， 我觉得没有人比开发更懂代码的细节，具体的处理过程了。让测试弄一套自动化测试的脚本，一个是开发能力略弱，另外业务上的细节还是有不太清楚的地方。 让自己写的代码能有一定的手段覆盖掉，单元测试可能比较麻烦，但是集成测试对于服务端，可以试着开一些有特殊条件的接口，能把业务要测的内容完整的代码流程走一遍，然后有输出的结果，后续每次测试前跑一遍就很快，再补一些针对性的内容。
• 向测试请教方法，比较不是专业测试，多问下有什么没有注意到的点，开发有开发的思维，测试有测试的思维，试着换一种思维角度考虑问题，开发和测试都属于技术类型的职位，如果开发从运营的角度考虑问题稍微有点难，从测试的角度考虑还算是比较接近的。

最后

希望大家都代码稳定，不写bug，但是能从别人的bug中学习...