技术
·
5 min read
·
- Views
🅱️ 优化一下打包部署流程
Copied
前景描述
之前在轻流时，第一次接触到CI/CD流水线，十分感叹流水线的强大，极高地降低了开发者在部署流程上的负担，让我们可以重点关注在开发工作中。
现公司虽然也使用Jenkins+docker+K8s来进行部署应用，但是我发现前端应用部署还是有点繁琐。
所以想着怎么简化一下部署流程，加快开发效率
对比之前与现在的流程
现公司流程是：
1. 开发完feat后 合并到dev分支， 然后需要本地对dev分支进行打包。
- 打包完成后，需要将dist文件手动拷贝到单独的一个dist-xxx仓库，替换掉之前的dist文件夹
- 在dist-xxx仓库中替换掉dist文件后， 还需要将pom.xml中的版本号手动加一，然后需要push到远程仓库
- 接着需要到Jenkins中进行构建。
- 等待构建完成后，需要手动到K8s中切换对应的镜像版本号
前公司流程是：
- 开发完feat后，合并到dev/test分支，然后push到远端仓库
- 等待GitLab Pipeline成功跑完后，直接去Jenkins上构建
- 等待构建完成就能在dev/test环境中看到最新开发的功能。
可以看到前公司的流程相对是更加简洁的，并且现公司还不用写测试不用跑Pipeline，要是集成测试的话，流程会更繁琐。
除却巫山不是云
正所谓由俭入奢易，由奢入俭难 。在体验过简便流程后，再遇到这么繁琐的流程肯定是受不了的。就想着怎么去简化一下现有流程。
整个流程一眼看下来其实前三步都是本地文件级别的操作，直接用node写一个脚本就可以简化了。思考第三步到第四步如何简化，很明显可以使用GitLab的webhook来进行简化。而第四步和第五步就暂时不考虑了，虽然也能通过Jenkins中K8s插件配合Jenkins的shell脚本来简化，但是我觉得这样似乎并没必要，因为K8s资源有限，基本上Jenkins构建完成后，立马切换K8s中镜像版本并不会立马生效(因为后端服务很多，基本随时都有人在切版本)。并且可以留有一丝余地，防止有时误构建还得去回退。
目标
脚本实现目标是
实现
1. 实现打包
既然是自动化流程，最好的就是当我们运行脚本后，立马选择配置项，然后就可以去上厕所或者去喝水了hhh.。 所以把目标的第三点是否推送远端作为配置型让用户在运行脚本时就自行选择
2. 更新dist文件夹和pom文件
因为多人协作的原因，一定要先pull获取最新的版本，再进行后续操作
切换好分支并且拉到最新代码后，就可以进行核心的patch操作了
由于原生地node不支持直接对文件夹进行操作，所以删除和复制操作，只能递归地对文件进行操作(其实可以使用fs-extra 包直接进行文件夹的操作)
删除和复制了dist文件夹后，就只需要对pom.xml文件进行更新了,对xml文件解析和生成需要使用xml2js包
3. 根据配置决定是否推送到远端
没啥好说的 直接贴上完整的start 主函数吧
使用GitLab Webhook 自动触发Jenkins构建任务
只需要在已有的Jenkins Job的配置中找到 构建触发器 ⇒ 勾选Build when a change is pushed to GitLab ⇒
⇒ 在高级中找到Secrete token , 点击 Generate 生成Token ⇒ 打开GitLab仓库的Settings下的Webhooks ⇒ URL 就是上图中打码部分， Secrete token就是刚才生成的token ⇒ 然后勾选Push events ， 至于哪个分支就根据业务需求，因为这个dist项目就一个master分支，所以我是直接选择的All branchs ⇒ 保存后点击Test 可以进行一下测试， 如果Status是200说明配置成功了。
👋
34 篇文章
53 个话题
- 次访问