来学学gitlab ci自动化部署项目

最新推荐文章于 2024-08-13 13:43:24 发布

阳阳C

最新推荐文章于 2024-08-13 13:43:24 发布

阅读量431

点赞数

文章标签： git

本文链接：https://blog.csdn.net/qq_40409143/article/details/115280413

版权

.gitlab-ci.yml文件配置

1.通过在项目根目录下配置.gitlab-ci.yml文件，可以控制ci流程的不同阶段，例如install/检查/编译/部署服务器。gitlab平台会扫描.gitlab-ci.yml文件，并据此处理ci流程
在这里插入图片描述
2. ci流程在每次团队成员push/merge后之后触发。每当你push/merge一次，gitlab-ci都会检查项目下有没有.gitlab-ci.yml文件，如果有，它会执行你在里面编写的脚本，并完整地走一遍从install => eslint检查=>编译 =>部署服务器的流程
在这里插入图片描述
3.gitlab-ci提供了指定ci运行平台的机制，它提供了一个叫gitlab-runner的软件，只要在对应的平台(机器或docker)上下载并运行这个命令行软件，并输入从gitlab交互界面获取的token,就可以把当前机器和对应的gitlab-ci流程绑定，也即：每次跑ci都在这个平台上进行。
4.gitlab-ci的所有流程都是可视化的，每个流程节点的状态可以在gitlab的交互界面上看到，包括执行成功或失败。如下图所示,因为它的执行看上去就和多节管道一样，所以我们通常用“pipeLine”来称呼它.

大致流程

本地代码推到master  => 触发钩子服务器自动执行脚本  => 拉代码，自动装依赖，打包，编译，上线(部署）deploy
1，第一步准备你的服务器公钥
2，在服务端安装gitlab runner
3，注册runner
4，编写一个简单shell脚本去操作我们的前端文件

在这里插入图片描述

5，我们还需要一份**.gitlab-ci.yml(这是建立连接的关键)**
我们的项目一级目录添加一个.gitlab-ci.yml，里面内容大概就是我们runner定义的，意思是在我们master分支有变动时，触发钩子自动执行deploy脚本
GitLab-Runner
这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。

中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。

在这里插入图片描述

GitLab-CI
这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。
GitLab-Runner
这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件之后，**根据里面的规则，分配到各个Runner来运行相应的脚本script。**这些脚本有的是测试项目用的，有的是部署用的。
.gitlab-ci.yml
这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。

除了web前端的项目可以使用gitlab自动化部署，小程序也是可以的。可以进行到审批阶段，不过审核结果通过或者不通过还是得自己手动去操作。

当服务器上安装的微信开发者工具未登录账号时，执行CI命令会返回权限错误的错误，此时则需要用户去手动扫码，成功登录后才可进行后续操作。此处我们选择了将登录二维码转为图片格式的钉钉机器人消息，并在输出控制台中打印的方式，通知和引导用户快捷扫码，完成登录操作。并且在成功的回调函数重试前一步执行失败的相关命令。
上面提到的在 Puppeteer 中登录公众平台后台系统，也可以通过这种机制来实现。

当我们在后台中选择体验版/送审版时，需要知道本次操作对应的版本号，当为选择送审版本时，还需得知送审的相关备注信息。这些内容我们是通过在本地代码的 push 操作之前，手动地填入这些信息，生成一份 JSON 格式的配置文件，最终在部署脚本执行时读取这份配置来实现。

虽然需要每次扫码，但是省去了操作浏览器，点击页面的操作，一定程度上提高了效率，并且降低人工发布的出错率。尤其是在做一些 Saas 类小程序部署时，一次代码 push 需要触发多个小程序的上传和发布，这种半自动化的机制还是可以省去不少时间的。