四、上线
　　现在涉及到前端上线的，有多个地方（公司有很多发布系统）：
　　TMS发布
　　aone2发布
　　gitlab发布
　　awp发布
　　etc.
　　gitlab发布通过域名严格区分测试、预发和线上环境，操作界限明确，出错的概率还是很低的（这要求开发者对 git 命令的操作十分熟练），如果几次 reset rev** stash 之后便开始犯蒙，那出问题的概率增大了。每次打下 tag 之前，我都会很仔细地 diff 下代码，看看本次发布和上次发布之间做了哪些修改，确认这些修改点再 push tag。
　　aone2的发布，并不是每个人都用过，它的靠谱在于有三种发布方式：
　　全网发布，半小时完成
　　小淘宝环境灰度发布，两小时完成
　　分三次发布，小流量上线，完成
　　同时也提供了十分方便的回滚机制，只要拥有应用的权限，可以随时回滚代码，效率极高。
　　TMS 的发布，我觉得是问题多的。首先，前端和运营都会拥有发布权限，运营喜欢“瞎搞”，部分页面（如JSON输出）并没有提供页面预览，运营填完之后也不会跑到页面查看效果，于是出问题了。。TMS发布每次修改只发布一个文件，CDN 发布一个文件的速度是很快的，当你点击发布的那个瞬间，整个同步基本完成了。可是，当某个节点同步出错，TMS 并没有给出提示，这是第二个隐患。第三个点，TMS坑爹的没有灰度，对一些重要的发布，没有灰度需要十分十分的谨慎，虽说出错可以及时回滚，但万一没有看到隐性的错误，那悲惨了。
　　五、回滚
　　没人可以保证自己写的东西不出问题，因为有太多的环境因素是我们想也想不到的，比如近某类控件在小淘宝环境下全挂了，试问，前端怎么会想到这是Nginx 的灰度系统出问题了，在灰度发布的时候文件没有同步成功，导致整个灰度环境出错。
　　所以，一定要给你的程序想一套快速回滚方案。尤其是在做 ABTest 的时候，新版的效果不好需要回滚到之前的状态，这种事情经常有。
　　回滚需要注意两点：
　　要快。
　　上一个状态要保证无错误。
　　只要我们能够保证发到线上的每一个版本都是稳定版，那回滚是 0 风险的事情。
　　六、监控
　　程序开发三板斧的第三板，监控。前端对测试不太重视，更不用提监控了。没有监控只能提心吊胆的过日子。
　　其实我们使用自动化工具测试、每天用肉眼顶着自己的页面看，这些都属于监控，但是深入到用户的监控，我们做的太少！
　　七、小结
　　看到老大在群里发了几条研发相关的红线：
　　1、禁止代码未经测试发布;
　　2、禁止代码发布后不进行线上验证;
　　3、禁止核心应用发布没有对应的回滚方案。
　　毫无疑问，这些都是必须严格遵守的。规范会先把坏习惯压住，进而被理解，后被消化吸收。