大型项目前端架构浅谈( 二 ) _前端架构

发布后分支锁死，不可再更改：指当例如0.0.1版本成功发布后，不可再更改0.0.1分支上的代码，否则可能会导致版本管理混乱。

全自动流程发布；指应避免开发者提交后，手动编译打包等操作，换句话说，开发人员发布后，将自动发布到预发布/生产环境。开发人员不和相关环境直接接触。实现这个需要参考下面的2.3 。

多版本并存；指当例如发布0.0.2版本后，0.0.1版本的代码应仍保存在线上（例如CDN），这样当出现线上bug时，方便快速回滚到上一个版本。

意义：
提高项目的可控性。
2.3、自动编译发布Jenkins
这个工具用于在代码发布后，执行一系列流程，例如自动编译打包合并，然后再从Gitlab发布到CDN或者静态资源服务器。
使用这个工具，可以让一般研发人员不关心代码传到Gitlab后会发生什么事情，只需要专心于开发就可以了。
意义：
让研发人员专心于研发，和环境、运维等事情脱钩。
2.4、纯前端版本发布
纯前端版本发布分为两步：

前端发布到生产环境——此时可以通过外网链接加正确的版本号访问到新版本的代码，但页面上的资源还是旧版本；
前端通过配置工具（或者是直接更新html文件），将html中引入的资源，改为新版本。

解决的问题是：当前端需要发布新版本时，可以不依赖于后端（根据实际情况，也可以不依赖于运维）。毕竟有很多需求并不需要后端介入，单纯改个前端版本后就要后端发布一次，显然是一件非常麻烦的事情。
这个需要专门的工具，用于配置版本发布，我最近就在写这个。
意义：
提高发布效率，降低发布带来的人员时间损耗（这些都是钱），也可以在前端版本回滚的时候，速度更快。
2.5、统一脚手架
适用场景：有比较多独立中小项目。好处：

可以减少开发人员配置脚手架带来的时间损耗（特殊功能可以fork脚手架后再自行定制）；
统一项目结构，方便管理，也降低项目交接时带来的需要熟悉项目的时间；
方便统一技术栈，可以预先引入固定的组件库；

意义：
提高开发人员在多个项目之间的快速切换能力，提高项目可维护性，统一公司技术栈，避免因为环境不同导致奇怪的问题。
2.6、Node中间层
适用场景：需要seo且前端使用React、vue，或前端介入后端逻辑，直接读取后端服务或者数据库的情况。

SEO：仁者见仁智者见智，虽然很多公司已经不做了，但通常认为，还是有一定意义的（特别是需要搜索引擎引流的时候），因此React或者Vue的同构是必须的。并且同构还可以降低首页白屏时间；
前端读取后端服务/数据库：好处是提高前端的开发效率和对业务的支持能力，缺点是可能导致P0级故障。

意义：
让前端可以侵入后端领域，质的提升对业务的支持能力。
2.7、埋点系统
强烈推荐前端做自己的埋点系统。这个不同于后端的日志系统。
前端埋点系统的好处：

记录每个页面的访问量（日周月年的UV、PV）；
记录每个功能的使用量；
捕捉报错情况；
图表化显示，方便给其他部门展示；

埋点系统是前端高度介入业务，把握业务发展情况的一把利剑，通过这个系统，我们可以比后端更深刻的把握用户的习惯，以及给产品经理、运营等人员提供准确的数据依据。当有了数据后，前端人员就可以针对性的优化功能、布局、页面交互逻辑、用户使用流程。
埋点系统应和业务解耦，开发人员使用时注册，然后在项目中引入。然后在埋点系统里查看相关数据（例如以小时、日、周、月、年为周期查看）[原创水印-作者：零零水(王冬)，微信：qq20004604] 。
意义：
数据是money，数据是公司的生命线，数据是最好的武器。
2.8、监控和报警系统
监控和报警系统应基于埋点系统而建立，在如以下场景时[原创水印-作者：零零水(王冬)，微信：qq20004604]触发：