Jenkins+Node+Vue 实战前端自动化部署平台

站长

2022年12月03日 22:58 · 阅读数 21

零门槛！一文揭开前端自动化部署的神秘面纱。如果你有用过发布平台，但是只停留在使用阶段，那就对了！本文从宏观层面讲解前端项目发布的必经阶段。笔者跟大家一起走进前端的基建工作，入门 Devops 领域，看看前端发布平台应该怎么做！

就前端而言，笔者认为 Devops领域还是离我们比较远的。一方面因为其中存在很多运维的工作，另一方面是参与前端的基建工作的机会少，不是所有前端都有机会参与。笔者也只是有幸找到机会，参与过前端发布平台的开发建设工作，算是入门了CI/CD的领域吧~也就是这样的机会，笔者有机会实战中使用 node server(koa)、数据库mongoDb、jenkins这些比较陌生又好玩的技术、工具。

先说明一下，因为笔者在公司内接触到的自动化部署工具是 jenkins，所以文中主要以其进行展开。业界上有很多自动化部署的实现方案，不一定非得用 jenkins ，像 gitlab-ci （笔者了解得不多...哭腔）等也是可以实现的，所以大家可以更聚焦在整体流程、实现方案上，不要过度关注技术栈、工具这种，因为百变不离其中。

接下来，笔者打算把实战经验通过文章的方式进行记录和总结。通过写一个系列，分享从前端的角度全栈开发一个前端发布平台，跟大家一起打开CI/CD的黑盒，走进前端基建的领域。当然，笔者在运维端的实力也是纸糊的，所以涉及运维方面的点主要针对实现阶段，原理层面还望大🔥指点指点！

系列大纲：

总览前端自动化部署流程，如何实现前端发布平台？
前端发布平台 node server 实战！文章链接
前端发布平台 jenkins 实战！如何实现前端自动化部署？文章链接
前端发布平台全栈实战（前后端开发完整篇）！开发一个前端发布平台。文章链接
websocket 全栈实战，实现唯一构建实例 + 日志同步。文章链接

本文是第一篇，将围绕 前端自动化部署流程 进行展开，核心讲解整个前端发布的所有阶段，从宏观掌握前端发布核心流程，为后续发布平台实战奠定基础（要做一个产品，首先要知道整个产品要解决什么问题，满足什么需求）。话不多说，赶紧进入主题！

一、为什么需要自动化部署？

回想起之前的经历（惨痛的发布场景），笔者甚至经历过最原始的前端发版的方式...

最开始。毫不夸张的说，就是本地打包、再压个zip包、通过工具手动上传、找到leader帮忙解压到对应的服务器上...每一个环节都是人工操作，发个版非常的繁琐，直到leader被更版冲走大量时间开始优化流程...
直到后来。发版流程有所缩减，但还是纯纯人工操作。开发者在下游分支 rebase 完 master 后找到leader，leader进行 merge master、构建项目、同步文件服务器、刷新CDN缓存...依然是纯手工活～

以上均是真实场景，每次发版都特别麻烦，特别是发上线还有问题要立马修复再发那种。还好笔者脸皮厚，可以疯狂找大佬发版（也就是平时买多几杯奶茶）～要是是个稍微有点社恐的开发同学，这场景还真是难熬。

这里笔者画了个图大家感受下，可以看到圈黑色虚线部分是纯人工介入，整个前端部署流程非常耗费人力资源，而这一块，恰恰就是本文要讲的重点，将其从人工变成自动化。 Jenkins+Node+Vue 实战前端自动化部署平台

可能有些同学到现在依然会面临着纯人工发版的场景。毕竟基础建设这玩意不如业务值钱，很多团队其实在业务优先的情况，也就只能这样了。所以，我们可以尝试性的去搞基建，一方面自己可以进阶，另一方面也可以为团队提效作出贡献。接下来，跟着笔者一起看看搞一个前端发布平台实现自动化部署要从何搞起？

二、如何着手发布平台？

既然要实现一个前端发布平台，首先要知道整个前端项目的发布链路，也就是我们先得有个大概的产品形态。只有有了模型，才能把实物制作出来，不是吗~在此，笔者先提出一个问题：如果是你需要实现一个发布平台，你会如何下手？

这里，笔者决定反其道而行，不从正面抛出整个前端发布的链路，而是从用户端（终端）进行反推，这样可能更能帮助大家理解。

一个问题：倒推用户是如何访问到我们撸的web应用的？

啊，首先在地址栏输入URL，然后浏览器根据URL做域名解析，DNS解析会从浏览器缓存、本机host、到DNS节点、到根DNS服务器找到域名对应的ip地址，然后发起TCP链接，进行三次握手......啊呸，果然还是八股背多了，对不起，我们重新来一遍~

CDN。用户通过地址访问到某CDN，获取 html 文件，下载并解析 html 文件内容，并加载相应的其他资源。（CDN中的资源怎么来？）
文件服务器（代指资源所在的源服务器，下文统称“文件服务器”）。CDN根据用户访问，回源到我们的文件服务器中获取资源。（我们的文件服务器中的资源怎么来？）
文件传输。打包后的dist产物通过一定手段传输到文件服务器中，如 rsync 。（dist产物怎么来？）
项目打包。以SPA项目为例，通过一定的前端打包工具对代码进行打包，获得产物。（代码怎么来？）
代码仓库。开发者本地进行业务开发后，将代码提交到代码仓库。如 git 、 gitlab 等

上面这5点反推的内容，大概就是我们要实现前端自动化部署所要做的工作了。我们所需要实现的前端发布平台就是要完成以上这些步骤的自动化过程，我们将需要实现的功能点进行梳理：

提供前端界面供用户配置项目、触发构建等
数据库保存用户的项目配置信息、构建记录等
构建自动化。包括拉代码，执行打包命令等
文件同步到文件服务器（文件上传）
刷新 CDN 缓存（一般是index.html），让用户能访问到最新的web应用

笔者自己撸了个图，大家可以参考一下，加深理解 Jenkins+Node+Vue 实战前端自动化部署平台

如上图所示，这基本就是我们要做成一个前端发布平台的最基本的功能点了。紧接着，我们对每个环节进行展开讲解。

三、实战前端发布平台技术准备

1. 前端

前端项目准备

前端项目就没什么好说的，相信大家撸前端都比笔者要6了~这一部分就简单带过了。

笔者就直接用 vite 新建一个 Vue3 项目吧～
```
pnpm create vite cicd-fe
```
跑一下项目，搞定~
前端要实现哪些功能：
- 提供项目部署的配置操作。如：
  - 代码仓库地址
  - 需要构建的分支
  - 项目打包命令
  - 上传到对应的文件服务器路径
  - 生产环境的访问域名映射关系
- 提供构建控制操作。如：
  - 开始构建
  - 停止构建
  - 回滚操作
- 显示构建信息。如：
  - 构建日志输出（jenkins的控制台输出）
  - 构建进度提示

ok，前端的项目准备和前端需要实现的功能大概介绍到这里了。具体的前端实战详情可以等笔者该系列的最后一篇文章："前端发布平台全栈实战！开发一个前端发布平台"，笔者将在那篇文章里面针对这些功能点进行展开讲解~

2. 后端

后端项目准备

首先定好整个后端的目录结构。虽然不是专业的后端，但也得照猫画虎套个架构模式 MVC 一下！
```
| -- cicd-node # 项目名称
    | -- package.json
    | -- pnpm-lock.yaml # lock文件
    | -- src # 项目代码目录
        | -- config # 项目配置
        | -- controller 　# 接口实现层
        | -- model # 数据模型层，定义数据的 schema 
        | -- routes # 路由层
        | -- services # 接口、数据嫁接层         
```
这是实战最基本的后端目录结构定义了，当然后续还会新增一些目录（比如 jenkins 、gitlab 、 中间件 的），这些笔者会在用到的时候再详细说，本文只需要搞个雏形，能跑通项目就行！详细的后端实战可以关注笔者的专栏系列第二篇！

那么，整个后端的每个分层的关系如下图所示：

简单来说就是： 用户发起请求 -> route层 -> controller层 -> service层 -> db
跑通后端项目

这里我们只需要跑通流程即可，详细的后端实战会放在专栏的第二篇文章中进行展开（包括数据库那那部分也是）。如何算是跑通？在 postman 搞一个请求，能正常处理、返回就算准备完成！
- 先搞个 koa ，把程序运行起来。
  
  cv大神出手，去官方文档拷一份代码。
```
const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello World';
});

app.listen(3000);
```
  再配置一下 package.json，启动方便一点。
```
"scripts": {
  "dev": "node ./src/index.js" // 执行入口文件
}
```
  直接 pnpm dev，打开 localhost:3000 看看效果。
- 实现路由层。
  
  这里使用 koa-router，先 install 一哈。详细了解这个库可以直接看看它的 github 。
  
  接着上面的 Koa 例子，根据 router 的文档说明进行一定的改造，搞个 get 、 post 的上去测试一下
```
const Koa = require('koa')
const Router = require('@koa/router')

const router = new Router()
const app = new Koa();
// get 请求
router.get('/test', (ctx, next) => {
  ctx.body = {
    code: 0,
    data: { name: '井柏然-get' }
  }
})
// post 请求
router.post('/test', (ctx, next) => {
  ctx.body = {
    code: 0,
    data: { name: '井柏然-post' }
  }
})

app
  .use(router.routes())
  .use(router.allowedMethods())

app.listen(3000);
```
  启动服务后，通过 postman 看看效果，首先是 get 请求：然后是 post 请求：可以看到都请求成功了，那后端项目准备这块就差不多完了。当然，实战中并不会把所有路由都如案例中一样堆在入口文件中，实战会通过一个入口 initRoute 方法包装，在 index 入口中执行这个 initRoute 方法。并且还要搞个 中间件 去统一包装返回数据的外壳，如错误处理时返回什么样的 code ，未登陆时返回怎么样的 code 。详细的大家关注笔者第二篇文章吧！我们接着往下看看后端需要实现什么功能
后端要实现哪些功能：
- 实现跟前端交互。
  - 处理前端发起的配置保存、构建、回滚等动作
  - 返回前端需要的数据
- 实现跟 gitlab交互。
  - 获取 gitlab 仓库信息、分支信息等
  - 获取 gitlab 的 commit 记录等
- 实现跟 jenkins交互。
  - 发起构建
  - 停止构建
  - 获取构建时状态、构建日志等
- 实现跟 数据库交互。反正就是各种 crud 操作～

3. jenkins

jenkins 这块可能是前端er们最陌生的东西了，毕竟谁有空没事回去搞这玩意呢？所以在开始讲 jenkins 相关的东西时，有必要去介绍一下 jenkins 是个啥。为此！笔者也是询问了一些运维大佬，看看怎么讲 jenkins 比较好让大家理解。总结了几点：

是一个流水线工厂，集成了大量主流打包编译插件。
原生提供UI界面交互，通过界面完成项目构建的配置，让用户在一个地方实现 CI/CD 流程。
从拉取代码、代码分析、编译、归档到部署全自动化实现。
支持多种脚本式构建（如脚本式pipeline），提供了极高的自由度。

好吧，说了这么多可能也很难讲明白，毕竟没接触过很难有那种概念。没关系，往简单了说，我们只要知道用 jenkins 来帮助我们实现 git pull 、npm ci 、 npm run build 这一串操作的自动化就行了。对 jenkins 的浅层了解并不影响我们实现一个前端自动化部署的发布平台。

具体的 jenkins 初始化、0-1搭建笔者就不再展开了，已经有很多大佬的手把手教学的搭建案例了，随便一搜都能找到好多精品文章分享。直接进入 job 的了解吧

了解 freestyle job

其实就是一把配置就完事的～我们可以把上述的：拉代码、装包、构建等一系列步骤配置到 freestyle job 中，然后我们再去运行这个 job ，那 jenkins 就会按照配置，帮助我们自动地执行这些我们配置好的前端部署操作，以此来完成前端的自动化部署。

这里，我们大致了解下 freestyle job 的配置都有哪些：

基础配置：项目名称、构建时使用的 jenkins 节点（打包机）...
源码管理：也就是拉代码时对应的代码仓库、分支
构建触发器（钩子）：配置构建的处罚钩子，比如：可以监听到 gitlab 代码提交时进行构建
构建环境：
构建：我们可以在这里添加我们需要执行的 shell 脚本，如 npm ci 、npm run build 这些。如果需要在这个阶段处理一些业务逻辑，我们还可以通过 curl 通知到我们的 node server 形成一个 jenkins 跟 node server 的交互。
构建后操作：我们可以在这个节点，通过邮件、飞书、企微啥的通知一些信息。

整个配置下来，直接保存就大功告成了！到部署的时候，直接构建这个 job 就行了，整个 job 的执行都是按顺序执行的，并且一个 job 被多次调用的时候会排队执行。当执行完 job 时，我们的项目就打包完成了，产物会放在 jenkins 的工作空间（Workspace）中。如图所示：

Jenkins+Node+Vue 实战前端自动化部署平台

讲到这里，整个前端自动化部署的工作也就接近尾声了，最后就是要把这个 dist 包，传到我们的文件服务器中，并且刷新对应的 CDN 缓存。当然，最后的这一个步骤大概率是不需要我们直接介入的，因为这一块一般都是由公司的运维同事去负责。不过，刷新 CDN 缓存这个动作也是可以在开发侧去触发的。但是有一个问题，文件同步一般是同步好几个机器，刷新 CDN 缓存的时间节点一定是在同步完全部的文件服务器触发才是最稳妥的，那这个钩子一般还是得由运维那侧提供，所以由他们去做刷新的动作也是比较合理的。也就是说，从开发侧来讲，完成一个完整的前端发布平台大概就如笔者上述介绍的了。

那秉承着“可以不会，不能不学”的初心，笔者也还是要提一嘴！文件同步这个前文中也有提到过，可以通过 rsync 去帮助我们完成。那最后，我们再了解一下 rsync ～

4. 了解 rsync

当然，用来做文件上传、同步的工具不只有 rsync ，只是笔者见识短浅了解得不多，只能把自己知道的拿出来说。不过还是那句，实现方式千千万万，但是整个流程却是八九不离十，所以更聚焦在整个流程中会更好。

首先看看 wiki 对 rsync 的描述：

rsync is a utility for efficiently transferring and synchronizing files between a computer and a storage drive and across networked computers by comparing the modification times and sizes of files

划重点：

比对文件修改时间和大小；
机器之间传输、同步文件；

关于 rsync 详细的用法笔者也不在这里详细展开了，毕竟我也是看其他大牛的博客来学习的，说不定屏幕前的你比笔者还要了解～笔者在这里放 2 个老师的链接，感兴趣的伙伴可以点进去详细了解

笔者大概总结一下怎么在前端自动化部署中使用 rsync ，一句话：敲命令就完事了。使用阶段，不需要特别深入了解一想工具、技术便可以用它来解决我们的需求点。

结合到 jenkins 中使用，我们可以大概这样，在构建中添加一个构建步骤执行 shell 命令（注意是要在项目构建完成后添加同步命令）：

Jenkins+Node+Vue 实战前端自动化部署平台

也就是说，当我们执行完前面那一串 jenkins 自动化流程后到 npm run build 结束（这个阶段我们已经可以在工作空间中得到最新的dist包），我们就可以通过 rsync 来帮助我们完成前端产物的同步工作了。只要把最新的构建产物同步到我们的文件服务器后，整个前端项目的部署流程就算是走完了，剩下最后一点就是刷新 CDN 的缓存了。

四、总结

到最后啦，相信看到这里，应该能对整个前端自动化部署流程有大概的认识了。如果已经平常使用过发布平台、自动化部署的童鞋肯能对文中提到的一些阶段有更深的理解。

笔者撸了个详细的图，全面看整个前端自动化部署的过程：

Jenkins+Node+Vue 实战前端自动化部署平台

核心点：

通过用户配置信息生成 job（可配置是否监听 git commit 触发构建全自动化）
jenkins 构建，执行 job（项目打包）
rsync 产物文件传输至文件服务器
刷新 CDN 缓存（调open api实现），核心资源（index.html）回源

接下来，笔者还会展开写：

Koa + mongoDb 实战发布平台后端开发 ；
jenkins实战详解，freestyle job 、 pipeline job 相关；
前端 + 后端 + jenkins 全栈开发前端发布平台的实战总结篇

大家敬请期待～

写在最后！笔者自己从发布平台的用户、到成为其开发者，最后打开这个CI/CD黑盒，中间是走了很多路子的。从前端、到后端、数据库、到jenkins 、到运维侧 很多都是新知识、新技术、新工具。虽然文章只讲了一些浅显内容，列出了前端自动化部署的阶段，但了解这些阶段，基本就从流程层面掌握了如何自动化部署，了解 CI/CD。当然，最后选择什么样的工具、技术来实现得根据自己的团队、公司来决定。总而言之，进入一个新的领域，拓展一下知识面，掌握一些前端基础建设的知识也是挺香的，毕竟技多不压身，一起加油吧！