设为首页 - 加入收藏 核心网 ()- 云主机,资讯,互联网,人工智能,云计算,大赢家论坛,区块链,VR,站长网!
热搜: 2019 统一 潜艇 模式
当前位置: 主页 > 红姐论坛 > 正文

淘宝前端团队谈前端工程化的云构建

发布时间:2021-07-22 13:33 所属栏目:[红姐论坛] 来源:互联网
导读:Grunt和Gulp等基于Node.js的构建工具已经越来越被人们所熟知,而自动构建工具部署在云计算之上无疑将更多地提高生产力,这里我们就来看一下淘宝前端团队谈前端工程

通常个人在开发项目的时,都是在本地编写构建脚本对项目进行构建,这个脚本可能是 Gulp,可能是 Grunt, 可能是 webpack,也可能是其他的一些脚本,每次代码发布之前,都要对代码进行构建,代码仓库里面包含构建脚本和构建之后的代码。对于个人开发,这样做是没有问题的,但是涉及到多人开发或者团队开发就会有一定的问题。说是问题也不是问题只不过是会导致开发效率降低,构建错误的情况越来越多。

在本地对项目进行构建,通过脚手架工具来分发构建脚本对于团队开发来说有很多问题:

构建脚本的开发维护者很难去持续优化,更新构建脚本
构建脚本使用者对构建脚本的修改,改良不可复用
每次发布之前都需要对项目进行构建,如果忘记构建将会导致发布失败
同一个项目的开发者可能会有不同的构建脚本,极有可能会导致构建出错
我们把构建脚本从应用里面提炼出来,包装成单独 npm 模块,这样构建脚本(下文统称为构建器)就有了模块的一些特性:

可分享: 任何人可以很方便发布一个构建脚本模块给任何人使用
可修改: 如果你有更好的主意,可以 fork,加上自己想要的功能,并发布到 npm 平台上
易维护: 模块可以由专人维护与更新
使用云构建后,本地不需要安装任何构建环境,这个对于一些新技术的推广是有好处的, 比如大家都知道,在 Windows 下, 安装 compass 不是一件轻松的事。而且对于构建脚本的更新也是很友好的,只需要更新云构建平台上的构建脚本即可。

使用云构建后仓库里面就不需要保存构建后的代码,这样有助于保持代码整洁,同时,在多人开发的时候,再也不会出现构建脚本冲突的情况。把云构建接入发布流程,每次提交发布时执行构建,这样就再也不会在发布之前忘了构建。而且服务器的性能更强大,对于比较大的项目能够更快执行构建,节省构建的时间。一线开发人员不需要去关心构建的问题,能够把更多的时间放到业务上,提高工作效率并。

历史和现状

Grunt、Gulp 等前端构建的概念是近几年才火起来的,其实淘宝前端团队早在 2011 左右就开始大规模对前端代码进行构建了(Git 也是在这个时候引入到团队内作为版本管理工具)。最初使用的构建引擎是 ant,基于 XML 描述构建规则,后来将 ant 的 build 任务放到了服务器端执行,再后来由于 ant 的扩展性和维护性太低直接改成了 shell 脚本(那个时候压缩代码还是用 YUICompress 和 Google Closure Compiler)。

再后来 Node.js 开始流行,基于 Node.js 的前端生产力工具开始如雨后春笋般涌现。团队内部开始使用 Grunt 构建前端代码(后续慢慢被 Gulp 和 webpack 替代),但依旧是在本机电脑执行构建,然后将构建后代码提交到仓库进行发布上线。14 年底开始构思并上线了第一版云端构建平台,开始逐步将前端代码的共建工作再次迁移到云端执行。

经过一年多时间的完善,云构建平台已经完全支撑起了团队内部乃至整个集团的前端代码构建任务,日构建任务量已达 1000+。并且构建服务还集成到了代码发布流程中和本地开发工具中,使前端开发前所未有的高效和轻松。

系统架构

云构建系统由五部分组成:

1.客户端(client)
client 负责向云构建发起一个构建请求并获取构建后内容。
client 官方提供了一个已经封装好逻辑的 npm 模块,如果是基于 Node.js 的系统,可以直接使用。
client 支持将需要构建的代码直接上传给构架服务器或者仅提供一个 URL,由构建服务器自己从 URL 下载代码,官方更推荐后者。
2.构建器(builder)
builder 是构建任务的最终执行者,包含详细的构建业务逻辑
builder 是一个标准的 npm 模块
3.构建服务器(workers)
workers 是一组高性能服务器,每台服务器可以并发运 32 个构建任务。
workers 可以动态扩容;上线和下线
4.构建路由(router)
router 负责分发构建任务给 worker。
router 集成了 worker 负载监控功能,可以保证所有 worker 平均负载。
5.数据展示和管理平台(web)
web 展示所有构建过程中产生的数据
web 管理构建器和构建服务器
架构图:

2016530104904941.png (925×664)

运行一次构建任务的大概过程如下:

app(需要调用云构建的各种系统)集成 client,并使用 client 提供的接口发起构建请求
client 从 router 获取一个 worker 地址
client 与 worker 建立 socket 连接,并向这个 worker 发起构建任务
worker 实时输出构建日志信息给 client
worker 完成构建后将构建结果返回给 client
client 将构建结果返回给 app
为了减轻构建服务器的负载,整个构建过程中涉及到的文件上传下载服务都是通过文件中转服务来完成的。

abc.json

除了上面的五个部分,还有一个配置文件也是必不可少的:abc.json(a build config)。这个文件一般跟需要构建的内容放在一起发送给 worker。是一个标准的 JSON 文件,指定需要调用的 builder 和一些配置信息。

构建器(builder)

abc.json 和 builder 是整个云构建平台唯一可定制部分。

builder 是一个标准的 npm 模块,入口文件可以是一个 Grunfile.js 或者 gulpfile.js,当然也可以是你自己的 xx.js。如果是 Gulp 或者 Grunt 脚本,worker 会帮你运行这个脚本,如果是普通的 npm 包,wroker 会运行由 package.json 文件中指定的入口文件。

构建器编写注意事项

1,项目本身需要依赖一些外部的模块,例如 lodash,需要构建开始前需要自己安装相应的依赖,可以通过一个 Gulp 的 task 去执行,没有依赖则忽略。

3,针对特定项目的配置信息,可以在项目的配置文件(abc.json)中添加,然后在构建时通过读取配置文件获取。

4,云构建和本地构建有一定的区别。本地构建时,源码目录和构建好的代码的存放目录构建者都是明确的。而云端构建,构建脚本是由云构建平台来控制的,云构建也需要收集构建好的文件返回给客户端,因此待构建源码的目录(src)和构建好的代码的存放目录(dist)都是需要有云构建平台来指定,worker 在执行 builder 的时候会传递相关参数。

5,如果构建器本身需要安装依赖,package.json 的依赖需要是 dependencies,不能是 devDependencies。

构建器测试

构建器编写本身也需要一定的成本,而且在本地无法测试,如果构建器编写出错,而且已经发布,将会造成很大的问题,因此需要一个构建器的测试平台。

通过删除构建系统的大部分特性,而只保留最核心的功能,同时去除原系统的一些限制使构建器能够在上面正常运行。同时编写相应的测试命令行工具,形成整个构建器测试平台。

线上构建系统对构建器做了严格的限制,构建器必须要审核通过才能够发布上线。测试平台没有这些限制,方便构建器开发者更新测试。

遇到的问题和解决方法

1,HTTP 连接

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章