作者 | 阿里文娱前端技术专家 铉咏
背景
近两年，前端复杂度持续攀升，从框架到开发模式都衍生出了无数的技术方案。单点的小规模尝试，导致团队内部技术栈以及实现方案出现分化，间接造成了知识库之间的隔离、项目之间模块复用率下降，人员在不同项目中的学习成本大大增加，技术管理成本被大量转嫁到人员管理上。
例如，同一种平台因为技术方案管控问题，导致执行路径产生偏差，细节复用艰难。
那么，如何实现人与工程的规模化管理，并优雅的驱动项目？本文将详解阿里文娱的实践及思考，尤其是整合各业务方向、技术实现拉齐、能力复用方面。
我们该怎么做？
经过详细的技术及收益评估，我们决定在阿里基础前端工程服务的基础上，搭建文娱自己的前端工程研发系统，用以高效承接及处理在前端工程领域上所遭遇的挑战。
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 -q
3. 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 孵化出的工程体系。
- 物料平台（用于沉淀通用型物料）
- 依赖分析服务（用于在线搭建动态渲染）
- 构建服务（用于平台特殊场景部署下的动态构建）
经验复用
-
采集：将在日常开发中产生的错误收集起来，并统一解答归类存档。即可自动归类生成一个错误的知识库。
-
消费：在错误发生时即可从错误的知识库中查找出对应结果处理。
工程数据化 (图形化示例)
通过流程收敛，使得整个团队的工程状态可以被监控，让数据的沉淀产生价值，优化 / 指导工程迭代，让每个技术人的努力可以被量化。
小结
上面是我们对前端工程如何规模化管理的思考与实践，整体来说就是工程入口的收敛 & 管控，加上领域方案的优胜劣汰，通过领域内经验的横向复用实现整体前端工程能力的提效。
文末彩蛋
前端技术一直在快速变化，回顾阿里技术从 PC 时代到 All in 无线，几年间新技术不断涌现 又被快速替代。与此同时，优酷前端也在不断的进化迭代中，业务从 Web 站逐步扩展到移动端 APP、OTT、小程序，以及营销系统搭建和运营中后台建设。
优酷前端团队将遇到的技术挑战以及解决过程详细展开并集结成电子书，希望由解决方案的推演抽丝剥茧，一探优酷前端团队在支撑业务过程中的技术思考和沉淀，为读者带来一些启发。在 前端之巅 公众号后台对话框回复关键词“阿里文娱”即可获取《阿里文娱大前端技术实践》电子书。