发布后的验证
提到这个话题，可能有些同学感到比较奇怪。我们开发完成，测试也测试了，产品也验收了。发布上线后还需要进行验证？
以前我也曾经经历了一些不做上线后验证的项目，每次发布完成就收工大吉。但结果往往不如人意，上线后被告知功能看不见，被告知权限有问题，甚至出现界面报错，更严重的一次是app崩溃。
我们大多数项目的开发测试环境都是和生产环境不一致的，而且数据库数据也是不一致的，我们无法一一穷举这些可能出现的情况。当然为了解决这些问题，我们做了预发布环境，甚至有些项目做了持续集成。去把环境做到基本一致和最大化避免人为操作。
但是还是不能百分之百保证不出问题，所以我们再给上线后加了一道防线，上线后验证。
方式方法
上线后验证的方式方法很多，我们需要根据每个项目的不同采用不同的手段。
举例一：
我们有个项目是以城市为区分的，但是我们不希望在正常城市去做一些测试，于是我们建立了一个测试城市，并且该城市对外隐藏，对内也不作用于计算统计一类。每次功能上线我们都可以进入隐藏的测试城市上去进行一些简单测试。
举例二：
有的项目实在难以创建角色进行测试验证，但是这个项目为内部项目，于是我们给上级部门和需求方进行了申请，添加一小部分测试数据并做好标示，分配了几个权限允许范围内的账号，这部分数据永远存放在这里，每次上线我们都可以拿这部分数据进行验证。
举例三：
我们有些项目比较看重稳定性，于是我们做了灰度发布，这样能很好的让一部分指定用户先试用，在没有问题后再进行全部正式开放。
举例四：
针对一些c端产品其实更加方便从容一点，我们完全可以正常的注册用户，登陆进入app系统去进行普通的功能测试验证，去查看功能是否存在问题。
看了上面几个例子你应该有一些想法了，为了保证上线发布后能简单验证一下功能我们想了一些办法，所以针对不同的项目我们往往会有不同的方法。
注意点
线上验证本来就是一件危险的事情，而且会造成一些垃圾数据，所以我们需要下面一些注意事项：
- 线上验证一定不要随意乱造数据，不然被用户看到这个影响是非常大的；
- 验证不一定要非常全面，能验证一些基本主流程即可；
- 如果有条件做预发布环境那是一件非常好的事情；
- 如果可以开启内测或者灰度发布那就更好；
- 线上验证不等于本地修改了代码直接发布在线上去看结果，千万不要曲解；
- 是否需要发布后验证视项目团队而定。
总结
我们知道，往往一些中小项目，几乎是没有什么灰度发布或者预发布环境的，所以发布后验证是一个保险的手段。
