做地推的网站,阿里云虚拟主机做wordpress,易语言做网站客户端,网站设计与网页配色实例精讲近两年#xff0c;前端复杂度持续攀升#xff0c;从框架到开发模式都衍生出了无数的技术方案。单点的小规模尝试#xff0c;导致团队内部技术栈以及实现方案出现分化#xff0c;间接造成了知识库之间的隔离、项目之间模块复用率下降#xff0c;人员在不同项目中的学习成本…近两年前端复杂度持续攀升从框架到开发模式都衍生出了无数的技术方案。单点的小规模尝试导致团队内部技术栈以及实现方案出现分化间接造成了知识库之间的隔离、项目之间模块复用率下降人员在不同项目中的学习成本大大增加技术管理成本被大量转嫁到人员管理上。例如同一种平台因为技术方案管控问题导致执行路径产生偏差细节复用艰难。那么如何实现人与工程的规模化管理并优雅的驱动项目本文将详解阿里文娱的实践及思考尤其是整合各业务方向、技术实现拉齐、能力复用方面。我们该怎么做经过详细的技术及收益评估我们决定在阿里基础前端工程服务的基础上搭建文娱自己的前端工程研发系统用以高效承接及处理在前端工程领域上所遭遇的挑战。 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 init2) 将代码部署至日常hub daily3) 将代码部署至线上hub publish4) 构建项目hub build5) 启动开发服务hub server6) 启动代码测试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 孵化出的工程体系。物料平台(用于沉淀通用型物料)依赖分析服务(用于在线搭建动态渲染)构建服务(用于平台特殊场景部署下的动态构建)经验复用采集将在日常开发中产生的错误收集起来并统一解答归类存档。即可自动归类生成一个错误的知识库。消费在错误发生时即可从错误的知识库中查找出对应结果处理。工程数据化 (图形化示例)通过流程收敛使得整个团队的工程状态可以被监控让数据的沉淀产生价值优化 / 指导工程迭代让每个技术人的努力可以被量化。 小结 上面是我们对前端工程如何规模化管理的思考与实践整体来说就是工程入口的收敛 管控加上领域方案的优胜劣汰通过领域内经验的横向复用实现整体前端工程能力的提效。
