前端持续集成
先来讲下前端持续集成的流程吧，我画了一个简图。
我的目标是构建一个工程化的全自动环境，使得开发者在不改变现有工作方式的前提下（无痛）完成代码集成等一系列工作。影响的角色：开发，测试，产品经理，领导。
（图中实线代表需要手动进行，虚线代表自动执行）
1.1开发者首先提交代码到中央仓库，中央仓库触发钩子通知CI Server有代码提交。（开发者不需要为此做任何改变，和以前一样提交代码就可以了）
1.2.收到通知后CI Server会自动执行一段脚本（checkout->build->lint->test）.完成之后会发邮件（调用Mail Service）通知开发者和代码维护者（比如tester等）构建信息（全自动）
2.1开发人员给代码打tag，中央仓库触发钩子通知CD Server有tag生成。（开发者不需要为此做任何改变，和以前一样打tag就可以了）
2.2收到通知后CD Server自动执行一段脚本（checkout->build->deploy）（全自动）
2.3项目上线后出现问题（报错）会邮件（调用Mail Service）通知开发者（图中也通知了维护者，视情况而定）报错的函数和上下文信息，方便开发及时发现问题并快速排查。（全自动）
3.1开发者首先提交代码到中央仓库，中央仓库触发钩子通知package analyser（开发者不需要为此做任何改变，和以前一样提交代码就可以了）
3.2analyser server 对代码的pakage.json文件进行比对，如果发生变化，则分析应用的依赖包，列出当前包的信息（比如依赖的包更新了一个bug，我们能及时知晓并更新修复）。（全自动）
4.1代码检查通过后，开发者发起pull request。（开发者不需要为此做任何改变，和以前一样提交pull request就可以了）
4.2维护者看到CI发过来的信息，进行代码审查，根据结果合并或者拒绝。（有了自动集成结果的支持，不需要维护者自己运行去检查了）
5.对于用户，可以提供一个dashboard。 展示CI CD 以及Package Analyser的结果（全新产品，就是上述各个系统的运行信息上报给呈现出现，并进行适当加工。）
当然这张图不仅仅是前端使用，基于docker CI CD 完全可以通用。但是对于package Analyser我们可能需要做一些变通。 因为package Analyser 作为前端的话分析的是node package 作为后端则是maven repository。
1.transformer 负责从不同来源（node package 和 maven repository）转化为标准输出
2.fetcher拿到信息之后去请求不同仓库获取版本信息和版本CHANGLOG
正规开源软件都是遵循语义化版本的。也就是传说中的主版本，次版本和修订版。
另外正规开源软件都是有更细日志CHANGLOG的，根据这些我们可以得到一些信息。
对于公司内部私有项目，希望也遵循这样的规范
3.reducer过滤掉不需要显示的，汇总成标准输出格式
4.view层拿到标准输入，展现给user
5.user可以查看对应项目的包分析结果。
前端开发工程化
下面这张图描述了我目前开发的流程，这套流程可以很好的完成前后端解耦。另外一些前端工程化的东西我没有涉及（比如liveload，less处理，合并压缩等），这些都可以实现自动化。并不是说那些不重要，只是网上例子太多，自行google就好了。
1.开发拿到设计，约定接口，记录到api server
2.本地开发 host 改成本地ip
比如程序中fetch('www.ltcrm.com/a')
host 增加一行： 127.0.0.1 front.ltcrm.com3.联调 host改成 后端开发者ip
host 增加一行： 10.33.88.144 front.ltcrm.com10.33.88.144是后端开发者ip
4.用户可以查看项目接口信息
来源：oschina
链接：https://my.oschina.net/u/2267438/blog/737139