Gitlab的CI/CD[0]

Gitlab的CI/CD[0]

CI/CD的出现改变了原有的软件的开放模式,使得现代软件的交付和变更更加迅速,相对于传统的软件的开发测试等流程,采用CI/CD的方式,使得一次配置软件的编译环境,即可实现自动化的编译和测试发布,将由人为因素导致的错误降到最低。

此部分的介绍和DevOps内容部分重合。

  • 概念

企业使用Gitlab作为工作仓库进行代码发布及版本控制,Gitlab内置了CI/CD的工具,这些工具可以用于代码提交的同时完成镜像构建、自动化测试、自动化部署等连续的工作

基本概念:
CI: Continuous Integration(持续集成)
CD: Continuous Delivery(连续交付)
CD: Continuous Deployment(持续部署)
  • Gitlab-CI/CD工作流

  1. 你当前的代码库托管在Gitlab上, 且已经为代码仓库配置了gitlab-runner服务, 它是用来实际执行CI任务的服务器;
  2. 提交代码,且根目录中包含一个名为.gitlab-ci.yml文件,该文件是用来指定构建、测试和部署流程、以及CI触发条件的脚本,其概念类似于docker-compose.yml文件;
  3. Gitlab检测到.gitlab-ci.yml文件,若当前提交符合文件中指定的触发条件,则会使用配置的gitlab-runner服务运行该脚本进行测试等工作;
  4. .gitlab-ci.yml中定义的某个自动化脚本运行失败,将判定为此次CI不通过,则需要提交者修复问题代码后重复提交,直至自动化CI通过。
  5. 没有问题的提交才能被项目负责人merge到主分支,进行后续的部署工作(此文暂不涉及CD自动化部署)
  • Pipeline说明

一个.gitlab-ci.yml文件触发后会形成一个pipeline任务流由gitlab-runner来运行处理,pipelinestagejob概念如下,需要按照项目实际情况定义不同stagejob:

参考资料:
  1. https://juejin.cn/post/6921581836426706957
  2. https://juejin.cn/post/6963927908444274718
  3. https://segmentfault.com/a/1190000037748013
  4. https://github.com/yangpeng14/DevOps/blob/master/ops/gitlab-ci-%E6%90%AD%E5%BB%BA%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90%E7%8E%AF%E5%A2%83.md
Comments are closed.