谈一谈前端工程化

前端持续集成

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

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

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

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.用户能够查看项目接口信息