近两年，前端复杂度持续攀升，从框架到开发模式都衍生出了无数的技术方案。单点的小规模尝试，导致团队内部技术栈以及实现方案出现分化，间接造成了知识库之间的隔离、项目之间模块复用率下降，人员在不同项目中的学习成本大大增加，技术管理成本被大量转嫁到人员管理上。
例如，同一种平台因为技术方案管控问题，导致执行路径产生偏差，细节复用艰难。
那么，如何实现人与工程的规模化管理，并优雅的驱动项目？本文将详解阿里文娱的实践及思考，尤其是整合各业务方向、技术实现拉齐、能力复用方面。
我们该怎么做？
经过详细的技术及收益评估，我们决定在阿里基础前端工程服务的基础上，搭建文娱自己的前端工程研发系统，用以高效承接及处理在前端工程领域上所遭遇的挑战。
1. 收敛 & 聚焦
大部分问题的诱因是缺乏统一的工具入口，而工具作为工程开发模式的重要指导急需统一的工具开发规范。
在此之上以“收敛 & 聚焦”为目标，我们开启了“终端 + 服务”的执行思路，落地了两个工具：
1) 工具集成工具 Hub Cli：集成其他二次开发工具，提供统一的工具接入接口；
2) 工具服务平台 Hub Service：提供工具依赖的基础服务。
2. 强化 & 赋能
通过工具服务平台对一些能力型问题进行针对性增强，如用户身份校验，从而将通用型能力赋能到各业务开发场景。
1) 自动接入云构建
基于 Hub Cli 开发的工具默认支持开启云构建，采用阿里集团云构建方案，进行统一的数据采集。
2) 用户识别
基于 Hub Cli 开发的工具自带用户识别接口，用以快速识别用户针对性下发配置。
3) 工具灰度控制
传统工具版本控制基于 Npm 管理，无法快速的进行回退或者废弃版本；基于 Hub Cli 开发的工具，则可以通过工具服平台，快速实现对人 / 系统 / 特定环境的快速灰度 (对云构建同样生效)。
4) 日志采集
基于 Hub Cli 开发的工具自动识别工具上报错误信息，帮助工具开发者快速定位工具问题。
为什么不使用集团前端工程工具
我们通过比较后决定下沉集团前端工程工具相关服务能力，以期在文娱层面达到更深的管理能力、灵活的方案定制能力。同时通过入口的收敛，降低各子团队对于集团基础前端工程服务的直接诉求，降低集团基础前端工程服务团队直接对接诸多一线业务团队的压力。
1) 大部分工程诉求不再依赖集团基础前端工程服务团队支持，方案制定更加灵活；
2) 对文娱前端工程状态首次有了可观测的可能；
3) 系统化的工具研发方案，大大加强工具能使用的能力，比如用户信息的获取，比如更新控制；
4) 自上而下的流程管控，便于随时增加工程卡口。
工程抽象
为了更好的实现一个工具集成平台，则需要对整个工程流程进行定义与抽象。
1. 工程生命周期
在工具入口层面定义了五个基础的工程生命周期，覆盖整个开发流程，降低工具间的学习成本，解决开发流程的规范问题。
1) 初始化项目：hub init
2) 将代码部署至日常：hub daily
3) 将代码部署至线上：hub publish
4) 构建项目：hub build
5) 启动开发服务：hub server
6) 启动代码测试：hub test
2. 可编排流程
对于发布流程的抽象，可帮助工具开发者更好的定义工具用户的发布行为，下图展示了对与 Assets 发布流程中的流程定义，实现了对分支的自动维护；工具开发者可自行定义流程从而降低使用者的操作成本。
3. 流程钩子
从生产到完成发布，整条流程线上分为三部分，分别提供流程钩子，用于做中间状态的校验。钩子校验采取阻断式。
4. 质量卡口
通过增加生产发布前的强制卡口。
流程管控
1. 工程方案下放
Hub Cli 会在执行命令时启动，启动会经过一轮 Check 流程，包含两部分内容更新:
1) 主程序更新检测
2) 工具更新检测
当发现存在新版本时，会通过 Hub Cli 内置更新模块进行自动更新，确保所有模块的运行版本为最新版本。
更新流程为强制更新，不可手动关闭是出于对工程方案覆盖率的考虑。及时覆盖就意味着版本断层的问题会被削弱，集中更新，集中处理。
2. 自动化发布流程
以改动提交场景为例，传统流程操作下，至少需要三步操作：
$ git add .$ git commit -m '提交信息'$ git push origin daily/0.0.1步骤越多，出错的可能性越高。我们通过流程编排，将操作完全自动化：
$ hub daily -q3. Commit 规范化
通过内置的 commit 管理模块，简化的同时取规范化 commit 提交数据，实现开发数据的有效沉淀，培养技术同学的优质编码习惯。
4. 平台联动
基于钩子的多平台联动，通过 hook 设置的方式，实现发布后对其他平台的调用通知。
5. 代码质量检测 &Code Review
使用 Hub 自动接入发布系统的项目将默认开启以下门神检测插件：
- HTTPS 协议检查
- 文件元信息检查
- 内部域名检查
- 代码注释检查
- NPM 模块 License 检查
发布的代码需要经过自动校验通过后才可发布至生产环境。除开自动检测外，还可以选择打开 Code Review 流程，只有经过 Code Review 流程后才可进行发布至生产的操作。
特定场景
1. 自动化更新
工具多是全局安装，因为全局环境权限问题，导致全局工具不能自更新，所以目前主流终端方案是只进行版本检查提示更新。
这种方案虽然解决了新版本通知的问题，但是弊端是依旧要人主动更新。
为此我们设计了一套基于全局环境的更新流程。主程序启动过程中会进入一个预先检查环节，预检查过程中会先检测存在的程序副本，若副本存在则启动子进程执行副本，而副本中会先进行自生版本检查，如果存在版本更新则通知主进程进行副本版本更新，当自身版本检查通过后，才会进入程序正式执行阶段。
通过对副本储存目录的控制，绕过了全局的权限校验，实现了任意环境下的自更新操作。
2. 模板引擎
对于模板引擎，我们简化了相关设计，基于 Gitlab 托管，结合 Ejs 模板引擎，实现了一套轻量化的模板引擎系统。
3. 终端用户识别
基于阿里基础前端工程服务的终端授权模式，实现了 hub 的终端用户授权能力，并实现了与阿里基础前端工程服务登录状态的完全拉通。
4. 千项(目)千面
通过对项目内配置文件.hubrc 的识别，自动挂载对应的工具；根据工具的不同改变 Hub Cli 的能力。
垂线领域沉淀
通过基础工程平台的沉淀赋能特定领域工程方案，加速特定领域研发效率，让工具开发者更专注于工程需求本身以及领域内的工程诉求。
1. 中后台场景
基础平台完善后，中后台技术方案开始聚焦，开始系统化设计 / 解决中后台场景下的提效问题。
- 物料平台(用于沉淀通用型物料)
- 中后台研发中心(用于沉淀开发 / 设计规范)
- API 网关服务(用于前后端解耦，接口快速编排)
- 应用托管平台(用于联动发布链路自动化部署)
2. 搭建平台场景
文娱活动运营搭建平台的工程诉求基于 Hub 孵化出的工程体系。
- 物料平台(用于沉淀通用型物料)
- 依赖分析服务(用于在线搭建动态渲染)
- 构建服务(用于平台特殊场景部署下的动态构建)
经验复用
- 采集：将在日常开发中产生的错误收集起来，并统一解答归类存档。即可自动归类生成一个错误的知识库。
- 消费：在错误发生时即可从错误的知识库中查找出对应结果处理。
工程数据化 (图形化示例)
通过流程收敛，使得整个团队的工程状态可以被监控，让数据的沉淀产生价值，优化 / 指导工程迭代，让每个技术人的努力可以被量化。
小结
上面是我们对前端工程如何规模化管理的思考与实践，整体来说就是工程入口的收敛 & 管控，加上领域方案的优胜劣汰，通过领域内经验的横向复用实现整体前端工程能力的提效。
)
