前端持续集成

先来讲下前端持续集成的流程吧，我画了一个简图。

我的目标是构建一个工程化的全自动环境，使得开发者在不改变现有工作方式的前提下（无痛）完成代码集成等一系列工作。影响的角色：开发，测试，产品经理，领导。

（图中实线代表需要手动进行，虚线代表自动执行）

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.com

3.联调 host改成 后端开发者ip

host 增加一行： 10.33.88.144 front.ltcrm.com

10.33.88.144是后端开发者ip

4.用户可以查看项目接口信息