Gitlab-ci:从零开始的前端自动化部署

发布网友发布时间：2024-09-29 08:56

共1个回答

热心网友时间：2024-11-12 10:15

以gitlab-ci为例，通过在项目根目录下配置.gitlab-ci.yml文件，可以控制ci流程的不同阶段，例如install/检查/编译/部署服务器。gitlab平台会扫描.gitlab-ci.yml文件，并据此处理ci流程。ci流程在每次团队成员push/merge后触发。每当你push/merge一次，gitlab-ci都会检查项目下有没有.gitlab-ci.yml文件，如果有，它会执行你在里面编写的脚本，并完整地走一遍从intall => eslint检查=>编译 =>部署服务器的流程。gitlab-ci提供了指定ci运行平台的机制，它提供了一个叫gitlab-runner的软件，只要在对应的平台(机器或docker)上下载并运行这个命令行软件，并输入从gitlab交互界面获取的token,就可以把当前机器和对应的gitlab-ci流程绑定，也即：每次跑ci都在这个平台上进行。gitlab-ci的所有流程都是可视化的，每个流程节点的状态可以在gitlab的交互界面上看到，包括执行成功或失败。不同push/merge所触发的CI流程不会互相影响，也就是说，你的一次push引发的CI流程并不会因为接下来另一位同事的push而阻断，它们是互不影响的。pipeline不仅能被动触发，也是可以手动触发的。

自动化部署的好处体现在几个方面。首先，提高前端的开发效率和开发测试之间的协调效率。在项目上线前的测试阶段，前端同学修复bug之后，通过gitlab-ci，可以直接部署到测试或集成环境的服务器，节约了开发时间，同时，测试同学可以随时把握代码部署的情况，并通过交互界面手动启动pipeline进行部署测试，节约了与开发之间的沟通时间。其次，从更细的粒度把握代码质量。可以将eslint或其他的代码检查加到pipeline流程中，每当团队成员提交和合并一次，pipeline都会触发一次并对代码做一次全面检测，控制代码质量。

gitlab-ci的基本概念包括pipeline & job、runner、executor、stages & stage、script、tags等。pipeline是gitlab根据项目的.gitlab-ci.yml文件执行的流程，由许多任务节点组成，每个节点都是一个独立的job。runner在特定机器上执行pipeline的程序，有specific runner和shared runner两种类型。executor指的是在特定机器上执行的平台。stages定义了pipeline的不同流程节点，stage表示当前的pipeline节点，script是当前pipeline节点运行的shell脚本，tags是当前job的标记，用于判断runner是否执行当前job。

编写gitlab-ci的"hello world"包括下载并安装gitlab-runner、初始化runner、注册runner、梳理和规划pipeline的不同阶段和过程、编写.gitlab-ci.yml配置文件。在编写配置文件时，需要考虑pipeline的阶段，如install、eslint、build和deploy。deploy阶段又分为服务器的申请和安装web服务，以及部署资源。编写配置文件后，通过提交项目代码，pipeline即可开始运行，最终将项目代码部署到服务器上。

在使用gitlab-ci过程中遇到的典型坑点包括runner未激活问题、job一直挂起、specific runner被share runner抢占job等。解决方法包括重新启动runner、给job添加tags、删除旧的runner并使用更新后的token重新注册runner等。

gitlab-ci的进阶功能包括YML的片段复用和模块化，通过YML的include关键字可以导入外部的YML文件，实现配置的复用和模块化。cache关键字可以缓存node_moles包，避免重复安装，提高pipeline性能。artifacts关键字可以将生成的资源作为pipeline运行成功的附件上传，并在gitlab交互界面上提供下载。image/services关键字可以使用Docker的镜像和服务运行Job。only/except关键字可以设置job在特定tag或分支名下运行。allow_failure和retry关键字可以设置job是否允许失败以及失败重试次数。timeout关键字可以设置job的超时时间。When关键字可以设置job在何种状态下运行。