写点什么

腾讯 Now 直播前端工程化的实践之路

  • 2019-07-26
  • 本文字数:6642 字

    阅读完需:约 22 分钟

腾讯Now直播前端工程化的实践之路

在百花齐放的前端圈,层出不穷的组件框架已让前端开发者应接不暇,另外,再加上业务和开发团队的不断发展,前端开发人员面临的问题越来越多。日渐突出问题主要为:如何高效的与团队成员进行合作开发?项目越来越多,不同技术栈的项目如何统一维护?如何制定和践行统一的开发规范?如何高效的部署和发布产品?


这个时候前端工程化概念的出现,解决了上面让开发者头痛的问题。它旨在制订规范化的前端工作流,并规范统一项目的模块化开发和前端资源,让代码的维护和互相协作更加容易更加方便。同时,让大家能够释放生产力,提高开发效率,更好更快地完成团队开发以及项目后期维护和扩展。


但是前端工程化具体是如何实践的呢?带着这样的问题,我们采访了参加本次 ArchSummit 全球架构师峰会的腾讯 Now 直播产品 IVWEB 团队社区、工程化的负责人——程柳锋,程老师与我们分享了腾讯 Now 直播在前端工程化上的具体实践方案。以下是本次的采访内容:

InfoQ:请您先做下自我介绍吧。

程柳锋:我是程柳锋,来自腾讯,先后参与腾讯 NOW 直播、NOW 语音交友、手 Q 群视频、群送礼等与直播相关的的泛娱乐产品的开发。另外我还是整个腾讯 IVWEB 团队社区、工程化的负责人。现阶段主要关注团队的工程化建设,包括新技术的预研和落地,另外也积极探索行业前沿技术比如:WebAssembly、PWA 等。

InfoQ:一线开发人员参与前端项目过程中需要关注哪些因素?

程柳锋:在产品迭代过程中,前端的定位往往是处于应用层,负责 UI 开发和用户交互体验的工作。大家日常开发时接触的 To C 的产品居多,比如 BAT、美团、滴滴等大厂的产品。这类产品的量级比较大,基本上日均 DAU 能达到几百、几千万,甚至过亿。因此,这类产品对用户体验要求非常高,一个微小的 JS 脚本错误很容易引发血案。


以我们团队为例,对于每一位开发者都有较高的专业能力要求,通常归纳为三个要素。按照重要性顺序如下:


  • 首先,是质量,开发者做出来的项目,其质量必须得到良好的保证,我们也会在项目上线前通过完善的监控手段保障质量。比如:JS 脚本错误监控、接口成功率监控、测速监控、HTML/CSS/JS 加载成功率监控等等。

  • 其次,是产品的性能。我们希望页面加载时首屏的白屏时间尽可能短,至少达到秒开的加载体验。另外,还需要保证在弱网络的情况下,页面也能够很好的展示。

  • 最后是研发效率,就是如何在较短的时间内,快速地进行业务需求的开发和上线。

InfoQ:现在腾讯上线前端项目,或者说升级项目版本,大概需要多长时间呢?

程柳锋:上线时间会根据具体的项目类型地变化而变化。我们内部整体采用敏捷开发模式,通常一个项目从启动到上线在 2~3 周,其中一周为开发时间,一周为测试上线的时间。


另外,对于重点攻坚项目我们之前也有大胆的尝试。举个例子,在 2018 年年初时,直播领域里的答题玩法特别火爆。各家直播平台比如:花椒、映客、熊猫直播,包括腾讯、高德地图、支付宝等都在做直播答题的应用。我们当时做这种攻坚项目,第一个版本从产品方案设计到最后上线发布仅仅花费两周时间。相对来说时间还是非常紧凑的,对一线开发人员作战能力有着较高的要求。

InfoQ:前端工程化是您负责的重要工作之一,它都包括哪些内容呢?

程柳锋:前端工程化是一个团队的基础设施之一,它更加偏向工程架构、研发流程相关的内容,主要有这样几个目的:


  • 随着业务的快速发展,产品需求爆炸式增长,团队成员不断扩充,前端工程化的首要目的就是满足快速发展的业务需要。前端工程化需要标准化研发方式、研发流程(开发、测试、发布、线上监控),让大家从创建项目到最终项目上线、监控使用相同的开发习惯。这个是前端工程化的主要目的。

  • 第二个目的,把团队的经验(比如做项目时踩的坑、经过试验得以验证的新特性等)沉淀到脚手架和开发套件中,使其他同学在开发新项目时可以复用这些经验。

  • 第三个目的是关注新技术的前端工程化落地场景,比如最近比较火的 Serverless、Flutter、小程序等技术。通过工程化的方式把新的技术与现有项目结合进行试验,试验成功后抽成脚手架和开发套件,其他同学后续开发这类工程也特别简单,节省了其他同学再次探索新技术的时间。让整个开发体验更加顺畅。

InfoQ:前端工程化是什么时候提出来的?背景是什么?

程柳锋:大约在 2010 年左右前端工程化的概念开始萌芽。前端工程化的提出,主要有以下两个原因:


  1. 业务场景的不断的复杂,很多事情需要前端去承载。像 H5、跨端应用,以及现在 WebAssembly、PWA 等新技术,他们的出现都让浏览器端可以承载的事情更多了,很多业务逻辑由服务端、客户端迁移到了前端。

  2. 2009 年 Node.js 的兴起给前端工程化提供了工具层面的支持,现在大家写的构建工具、脚手架工具、代码规范检查,以及我们做的 Pre Render,都是在 Node.js 的基础之上做的。前端工程化的概念还需要通过工具来加以践行和佐证,我们通过 Node.js 编写 CLI 或基于 nw.js/Electron 的 GUI 工具,在项目的创建阶段,大家可以使用统一的命令来创建项目、页面或组件;在项目的开发阶段,针对不同技术栈的项目可以使用不同的开发套件进行本地开发、调试、和规范检查。

InfoQ:从 2009 年到现在也有 10 年的时间了,你觉得现在前端工程化大概发展到什么阶段了?

程柳锋:前端工程化的价和团队规模成正相关的关系,团队规模越大,工程化的价值就更高。可以分为几个阶段:


  • 第一个阶段:初创的团队,团队人数大约在十人之内,这时候前端工程化的主要作用是规范开发、协作规范。这个阶段团队人数相对比较少,大家通过简单的规范约束基本可以满足需求。

  • 第二个阶段:团队规模在快速扩大,内部员工流动比较大,这个时候让大家都遵守之前制订的规范是比较困难的。通过工程化的 CLI/GUI 工具、脚手架、开发套件和插件,保证项目从创建到本地开发、测试,再到最后的发布、监控都能够正常的运转。

  • 第三个阶段:团队如果达到一定规模(大约在 100 人以上),或者多个部门共同参与前端工程化的建设,从而有效的避免不同部门重复造轮子的现象。

InfoQ:在前端工程化的趋势下,CLI 和 GUI 这两个工具开发的背景是什么?解决了什么问题?

程柳锋:如果把前端工程化分层的话,CLI 和 GUI 就是在最顶层。它们是直接和开发者进行交互的,最核心功能是规范开发流程。CLI 是命令行的形式,GUI 是图形界面的形式。中间层即是工具平台和规范,开发者通过 CLI 或 GUI 即可调用工具平台,快速打通与工具平台、开发规范的联系。底层为基础设施。我们目前已在五个业务场景应用了 CLI 工具,分别是五个不同技术栈的业务场景:商业化的运营活动、APP 内嵌的 H5 页面、ReactNative、Serverless、组件。

InfoQ:前端工程化的脚手架能为开发人员缩短构建项目的时间,同时提高开发的效率,请您说一下前端脚手架的构建现状。可以从腾讯的构建现状或者业界的构建现状来讲一下吗?

程柳锋:这两个都可以说一下。我们先来聊一聊整个行业的形态,现在市场上比较流行的前端框架主要是有以下几个:React、Vue、Angular、Weex。这些框架各自所对应的脚手架都只能开发自己技术栈的项目。而实际开发中,我们需要面临不同技术栈的开发场景,单一技术栈的脚手架无法满足需求。


其次,使用的官方脚手架所包含的功能是最基础、最通用的。在腾讯的实际业务场景中,针对一些细粒度化的业务仍需要做二次定制。比如日常中需要上报的各种数据:监控信息、JS 数据、VIP 白名单日志、接口接口调用成功率、首屏渲染时间、HTML/CSS/JS 加载成功率等,用行业通用的脚手架完全不能满足我们的要求。我们在行业脚手架的基础上进行维护,二次定制具有我们业务特色的脚手架。


我们团队目前在这个背景下做了一个更加通用的技术方案。该技术方案基于 Yeoman,在 CLI 里面的集成了 Yeoman 的 Runtime。截止到现在为止,我们公司内部总共有十个脚手架左右,大家可以共同维护这些脚手架,并进行二次定制。通过上层统一的 CLI 命令在创建项目时就可以选择使用哪个脚手架。

InfoQ:现在前端使用 Webpack 构建工具比较多,与之前使用过的构建工具相比,Webpack 的优点是什么?

程柳锋:我个人之前用了很多种构建工具,如 YUI Compressor、Grunt、Gulp、Fis3 和 Rollup 等,目前我们已经完成大部分业务从 Fis3 切换到 Webpack4,其中他们的区别主要有以下几点:


  1. 从插件生态上来看,Webpack 相对 Fis3 拥有更高的维护频率(即发版节奏快)。从 Webpack1 到 Webpack5,基本上每年出一个新版本。目前 Webpack4 已经正式发布了,Webpack5 也已经在 alpha 阶段,整个社区 Webpack 贡献者也很多,当大家遇到问题并提交 issue 至社区,问题都可以得到解决。

  2. 另外,Webpack 可以做的事情有很多。整个社区的 Loader、插件十分丰富。比如 HappyPack,其多进程多实例打包方案可以实现快速打包,相对 Fis3 来说,其打包效率是非常高的。包括现在 Webpack 官方也原生提供了 thread-loader,也可以通过它进行多进程多实例的快速打包,从而让打包时间得到极大的优化。

  3. Webpack 和其他构建工具的差别在于 Webpack 打包理念是革命性的。Webpack 把所有的资源都当做模块(比如 JS、CSS 图片、字体,或富媒体的文件等)。与其他构建工具相比,Webpack 最显著的特征是它通过各种 loader 去处理模块,这也是大家为什么一直叫 Webpack 模块打包器的原因。Grunt 和 Gulp 的构建过程都是以 Task Runner 的方式去做的。Gulp 是流式的构建,而 Grunt 每次的构建产物会存储到本地的 tmp 目录中,Gulp 是直接放到内存里,构建的时候相对 Grunt 更快一点。

InfoQ:腾讯把构建工具从 Fis3 迁移到了 Webpack4?在切换的过程中有没有遇到什么困难呢?又是怎么解决的?

程柳锋:我们当时切换的时候确实遇到了很多困难。第一个困难是 Fis3 里面支持了一些比较好的特性,而在 Webpack 却没有。这里面也可以举一些我们在实际迁移过程中遇到的例子,比如说 Fis3 支持 inline 语法,可以将 HTML 片段引用到另外一个 HTML 中,也可以将一个图片 inline 过来自动 Base64,还可以合成雪碧图,总的来说它可以精细化的控制资源。但在 Webpack 中是不支持 inline 语法、雪碧图的合成。我们解决的方案是实现相关的 Loader,比如 inline Loader。对于雪碧图的 sprites-loader,在项目迁移的过程中我们把 Fis3 的资源内联语法(?__inline)和合成雪碧图语法(?__sprite) 做了下兼容,新旧项目中都支持了。


其次,Fis3 中支持资源引入时的绝对路径写法,在迁移至 Webpack4 的过程中也需要对它做兼容支持。


还有一个比较大的差别就是打包方式的不同。用 Fis3 打包时是以 HTML 为入口,但在 Webpack4 中是以 JS 为入口,打包的入口发生了很大的变化。这时候,我们也需要对之前的逻辑做些适配。

InfoQ:各个项目中使用的技术栈大不相同,这对项目组件化带来了什么样的影响?

程柳锋:这其实会带来的一个最大的影响是,不同技术栈项目的组件无法复用到另一个项目。所以针对于组件化的复用,我们也做了一些适配,当然,不是所有的组件都适配,我们只是对基础的组件做同构。上层的业务组件可以复用同构好的基础组件。同构相对来讲比较难,但为了之后维护的便利性也是值得的。最好还是根据各自的技术栈实现不同的业务组件,并统一维护。

InfoQ:腾讯 NOW 直播产品在团队工具链、规范等开发配套设施的建设过程中遇到了哪些问题?

程柳锋:这里面我们也是遇到了不少问题。我先从规范说起吧。


  1. 我们团队成立之初,是从腾讯的 IMWEB 团队孵化出来的,这时我们的工具链大多延用他们的工具链。随着这业务的快速发展,暴露出很多业务自身的痛点,原来的工具链无法满足现有需求。为了解决这个问题,我们建立了新的工具链和规范。我们首先建立了 Git 提交规范、Git 工作流规范、分支规范、README 规范、监控规范等。但是规范建立之后又面临另一个巨大挑战:如何将这些规范落地实施呢?我们在这方面做了很多尝试:


  • 将 ESLint 的检查规则集成到我们的基础设施上,就是将 ESLint 集成到 CI 和 CD 的流程中。当大家提交代码后,第一步会通过 ESlint 来检查代码是否通过,如果没有通过的话,就会拒绝本次构建,当然这个 ESLlint 检查只是增量检查。如果通过才会进行构建流程。这就是我们 JS 规范的落地执行过程。针对 Git 分支规范和提交规范,我们每天通过邮件扫描,查看前一百条的 Git 提交记录格式是否正确,若有问题,我们会邮件知会相关同学。

  • 业务监控告警的规范执行,主要是靠技术负责人 Review,在项目每次发布上线之前,技术负责人会 Review 监控上报的项有无缺失。同时我们根据业务的重要性、访问量等指标将业务分为 3 个级别:重要业务、常用业务、普通业务。不同级别的业务的监控要求也是不一样的。

  • 除此之外我们还需要强制地将重要业务加到我们的 CI 和 CD 流程里,就是单元测试和端对端的测试,每次代码 Commit 都会异步的通过腾讯的蓝盾进行单元测试和端对端测试,如果测试用例不通过,则不允许发布上线。


  1. 另外在工具建设的落地方面,我们会做很多工具平台,比如监控平台、移动测试代理、组件平台等,但这些平台怎么落地?我们也做了一些操作。以监控平台为例,我们会把每个业务对应的 JS 错误 ID、JS 报错率统计出来,并做一下排名。对于排名靠后的项目,会把相关人员、业务的名单展示出来,并通知相关的技术负责人、业务老板等。这个做法还是比较好的,有利于大家及时发现问题和解决问题,同时也帮助整个团队改进工具平台。

InfoQ:在前端工程化的发展过程中,腾讯 Now 直播产品经历了怎样的技术架构变化?

程柳锋:一开始腾讯前端工程化的建设与其他公司还是有一定的差距,甚至说是落后的。最开始我们团队的前端工程化局限于 Fis 构建的工程化。Fis 可以很好支持本地开发,但不支持创建项目、单元测试、端对端测试、代码检查的工程化。所以我们第一阶段做的事情就是换掉 Fis,使用 Webpack 作为我们的构建工具。


之前,整个腾讯 CI 这块的建设比较落后,CI 做得事情也比较有限。在做了脚手架和构建工具切换后,我们团队搭建了 Jenkins,以便于代码的可持续集成。


搭建了 Jenkins 之后,接下来慢慢的迁移到整个公司,并接入了橘子 CI(Orange CI),借助 Orange CI 把很多 CD 的事情也一起做了。因为之前接入的 CI 还不彻底,我们 CI 完成之后,开发者仍然需要在平台上面手动的点击发布,预上线发布还是有很多的人工操作。但我们 CI 完成之后,每次 CI 完成之后它会自动构建出一个包。


  • 如果是正常的 push,默认情况下,构建出来的包会自动的部署到测试环境,完成测试环境的部署任务。

  • 如果打了一个 tag(就是运行 Git tag),或者在 CLI 运行了 deploy 的命令,这时它会自动的帮我们把构建出来的包发送到线上。对于离线包,它也会发一个灰度离线包,我们只需要验证没问题之后,自己再手动的发一个离线包即可。在有了 CI、CD 做支撑后,前面提到的规范和端对端的测试用例、单元测试等,都可以很好的集成进来了。


这就是我们 Now 直播产品整个前端工程化的技术架构,接下来,我们也会去重点探索一下小程序、Serverless 的前端工程化要怎么做,这也是目前腾讯开源协同的 Team 在关注的事情。

InfoQ:那现在腾讯这边的前端的发布系统已经可以实现项目自动部署了吗?

程柳锋:现在已经完全实现自动发布了。CI 和 CD 的过程很大程度上提升了我们的开发效率。之前如果手动发布项目,你需要做很多操作。但是现在只需在不同的发布系统里面点击一下就可以实现项目发布,发布时间从之前 15 分钟优化到仅仅一条命令就完成。

InfoQ:您认为前端工程化在未来有哪些机遇和挑战呢?

程柳锋:我认为有以下几个机遇:


  1. 前端工程化可以做很多事情,前面提到了有三个阶段,那么第四个阶段就是中台化,我们可以联合多个部门共建前端工程化,让它的生态和体系更加完善,从而有效的避免重复造轮子的事情,这是每个公司未来都要重点实践的事情。

  2. 前端技术发展异常活跃,新的技术和框架不断的出现。对于新的技术方案,我们要及时的把它们整合进来,并探索它们的工程化,比如说像小程序、Flutter、Serverless 等这些新技术的工程化方案。

  3. 我们认为前端工程化未来的定位将更加超前。新技术的预研有很大一部分是放在前端工程化中来做的。举个例子,之前我们的项目是 React 16.2.0 版本,这个版本我们用了一年多,但随着 React 框架不断的发布,当 React 发布到 16.8.0 的时候,React 会带来很多新特性,如果再用之前的 16.2.0 版本,开发者将无法感知 React 的新特性。这时候,通过前端工程化的方式,可以帮助大家快速的体验新特性。另外,还包括一些技术方案的尝试,比如像 WebAssembly、PWA 等,通过前端工程化的方式,能够更好的赋能我们业务。


2019-07-26 18:453123

评论

发布
暂无评论
发现更多内容
腾讯Now直播前端工程化的实践之路_大前端_程柳锋_InfoQ精选文章