关于代码发布
发布静态资源看你们自己的部署方案吧。一般是公司内撘一个ci系统，比如jenkins，然后在上面安装运维提供的部署脚本，然后配置gitlab（通常不用github，防止泄密）的webhook，一有提交就发请求到jenkins上，jenkins拉取代码，调用fis构建，然后把产出的代码通过运维脚本推送到测试或者生产环境。大致的流程是：
- 内网搭建gitlab/svn
- 内网搭建ci系统（jenkins）
- 在ci系统所在机器上安装fis、运维推送脚本
- 配置gitlab的webhook，一有提交就发请求给jenkins
- jenkins中创建job，填写gitlab中的url，填写hook脚本
运行效果：
- 开发人员提交代码，gitlab触发webhook，推送信息到jenkins
- jenkins根据推送的信息执行对应的job
- job中的脚本clone对应的分支，调用构建工具对代码进行构建
- 使用运维脚本将构建完成的结果推送到测试/生产服务器。
上图中的SCRAT是我们基于FIS定制的自己的工具
总之效果就是【提交代码】→【自动部署】，【自动部署】包括了【构建】+【代码推送】
关于map.json回滚
其实每次发布，都可以把构建好的代码生成一份tar包存到代码库里，生产/测试/开发环境可以自由切换任意版本的包。服务端的包自然携带了map.json，切换哪个就代表了回滚哪个。静态资源不用回滚，丢在静态资源服务器就好了
angularjs
angularjs感觉对CRUD类产品比较合适，但百度的很多产品并非这种类型的，而且很多产品每天千万甚至几亿的访问量，如果放一个angularjs，不但每次研发部署后用户重新下载资源的性能大打折扣，而且很多业务的前端场景并不能很好的覆盖angular的功能，不能充分发挥它的价值，进一步浪费带宽。
所以，一般不太喜欢在页面上放一个几百K的，但只使用其中20%功能的前端框架，大家都恨不得量体裁衣。目前在业内能找到angular应用场景的项目，感觉大多集中在 ( pc端的 || 非核心功能的 || 后台管理系统类的 || 访问量小的 ) 页面上，我感觉百度也有团队在用，只是在一些我们没有很关注的某个页面的角落里而已。
