前言
前端工程化中 CI 是必不可少的一环,大家的团队中或多或少都有不同的 CI 能力,有的可能由运维同学使用 JIRA 配置(前司),更多的相信已经迁移到 Gitlab 到 CI/CD 中。那么今天就来聊聊什么是 CI 以及如何在 Gitlab 中配置 CI 能力。
CI
CI(continuous integration)
持续集成是将所有代码更改尽早并经常集成到共享源代码存储库的主分支中的做法,在您提交或合并它们时自动测试每个更改,并自动启动构建。通过持续集成,可以更轻松地在软件开发生命周期中更早地识别和修复错误和安全问题。 通过频繁合并更改并触发自动测试和验证过程,您可以最大限度地减少代码冲突的可能性,即使有多个开发人员在同一个应用程序上工作。第二个优点是您不必等待很长时间才能获得答案,并且可以在必要时修复错误和安全问题,同时您还记得这个主题。 常见的代码验证过程从验证代码质量的静态代码分析开始。一旦代码通过静态测试,自动化 CI 例程就会打包并编译代码以进行进一步的自动化测试。 CI 流程应该有一个版本控制系统来跟踪更改,因此您知道所使用代码的版本。
简单点说,CI 就是对你某个版本的代码进行自动化的检查,比如代码格式,单元测试等等,让当前版本的代码保持在持续稳定的可用状态。
Gitlab CI配置
我们来看看如何从 0 开始配置 Gitlab 的 CI
前提:你已经在 Gitlab 有个项目
1. 在项目根文件上添加 .gtilab-ci.yml 文件
我们看看 Gitlab 默认生成的示例文件
# This file is a template, and might need editing before it works on your project. # This is a sample GitLab CI/CD configuration file that should run without any modifications. # It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts, # it uses echo commands to simulate the pipeline execution. # # A pipeline is composed of independent jobs that run scripts, grouped into stages. # Stages run in sequential order, but jobs within stages run in parallel. # # For more information, see: https://docs.gitlab.com/ee/ci/yaml/index.html#stages # # You can copy and paste this template into a new `.gitlab-ci.yml` file. # You should not add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword. # # To contribute improvements to CI/CD templates, please follow the Development guide at: # https://docs.gitlab.com/ee/development/cicd/templates.html # This specific template is located at: # https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Getting-Started.gitlab-ci.yml stages: # List of stages for jobs, and their order of execution - build - test - deploy build-job: # This job runs in the build stage, which runs first. stage: build tags: - xxx script: - echo "Compiling the code..." - echo "Compile complete." unit-test-job: # This job runs in the test stage. stage: test # It only starts when the job in the build stage completes successfully. script: - echo "Running unit tests... This will take about 60 seconds." - sleep 60 - echo "Code coverage is 90%" lint-test-job: # This job also runs in the test stage. stage: test # It can run at the same time as unit-test-job (in parallel). script: - echo "Linting code... This will take about 10 seconds." - sleep 10 - echo "No lint issues found." deploy-job: # This job runs in the deploy stage. stage: deploy # It only runs when *both* jobs in the test stage complete successfully. script: - echo "Deploying application..." - echo "Application successfully deployed." 复制代码
stages
stages 配置 CI 的不同 阶段
job
job 配置单个 任务
stage
stage 配置所属阶段,同个阶段下的不同任务默认是并行的(能不能设置串行打个❓)
script
script 配置当前任务所要执行的脚本
tags
tags 配置任务所属标签,和下文的 runner 标签对应
2. 安装注册 CI 的 gitlab runner
runner 就是要执行我们上面的配置文件的机器,可以是线上服务器,也可以是本地计算机
这边有两个概念
Specific runners
私有 runner
Shared runners
平台提供的共享 runner
使用平台提供的 runner 需要绑定信用卡验证,太麻烦了所以我没去弄
我使用的是本地计算机作为 runner,并且用 brew 进行安装
brew install gitlab-runner 复制代码
启动 runner
brew services start gitlab-runner 复制代码
注册 runner 按提示输入上面图片对应的 url 和 token,可选择性定义 tag
最后的执行环境可选的也非常多如 shell docker 等等,对于官方的示例配置我们使用 shell 就可以了
gitlab-runner register 复制代码
最后执行下 runner 的验证
gitlab-runner verify 复制代码
可以看到 runner 已经注册并验证成功(ps: 这里图文不符哈,正常的是绿色小球)
3. 启动 pipeline
将项目代码 push 后找到 CI 运行并观察运行结果,以后在合并代码的时候也会自动触发 pipeline
1
其他
1. 执行环境的选择
我们上面的示例是在 shell 上运行的,实际使用 docker 会好很多,特别是我们要执行 npm install
之类的脚本的时候,使用 docker 的话可以直接在 yml 配置中声明 image 就可以定义运行环境,非常方便
image: node:14.16.0 # ... 复制代码
2. 为什么本地的计算机可以注册为 runner
本地的计算机可以注册为 runner 意味着,线上仓库可以通过网络访问你本地计算机,这点我也挺迷惑的,但实践表明确实可行。对网络这方面了解不够深入,希望后面可以尝试解答。
结语
本篇文章简单地介绍一下 Gitlab CI 的配置启用,比较偏向于小白了解概念。实际上想要完整强大的 CI 还是离不开更多的学习,例如 yml 更多配置,CI 的缓存配置等。