GitLab CI
一、CI/CD?
CI/CD 是一种通过在应用开发阶段频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,解决了重复迭代一个重要过程。
具体而言,CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期(从集成和测试阶段,到交付和部署)。这些关联的步骤一般被叫做"pipeline(管道)",由开发和运维团队相互协同支持,来维护整个应用的周期迭代。现在主要说的是其中的 CI ,也就是其中的持续集成,主要谈一谈GitLab 其中的CI。
二、GitLab CI
1. 相关概念
GitLab CI/CD官网
他是这样介绍的:考虑一个应用程序,它的代码存储在 GitLab 的 Git 存储库中。开发人员每天多次推送代码更改。对于每次推送到存储库,您都可以创建一组脚本来自动构建和测试您的应用程序。这些脚本有助于减少您在应用程序中引入错误的机会。
这种做法被称为持续集成。提交给应用程序的每个更改,甚至是提交给开发分支的更改,都是自动且持续地构建和测试的。这些测试可确保更改通过您为应用程序建立的所有测试、指南和代码合规性标准。
GitLab 本身就是一个使用持续集成作为软件开发方法的项目示例。对于项目的每次推送,都会对代码进行一组检查。
总结 其实就是一个在迭代中维护代码流水线上一个重要工具 统称的概念
2. 选择,GitLab CI特点
- 由于大部分公司代码都是在 GitLab 中完成的,因此 CI/CD 解决方案可以非常简单,自己的一套CI会更加适用,与 GitLab CI 的无缝集成
- 使用简单、快速
流程图 有个大概的了解
3.环境以及其他配置
1. gitlab-ci.yml
首先运行一整套流程他肯定有一个规则表,这就是对管道(后面的pipeline)的执行制定了一个规则,在提交代码后会按照这个规则表去执行相应的job,来管理整个CI的工作流程。
官网中的一个 eg:
stages:
- build
- test
build-code-job:
stage: build
script:
- echo "Check the ruby version, then build some Ruby project files:"
- ruby -v
- rake
test-code-job1:
stage: test
script:
- echo "If the files are built successfully, test some files with one command:"
- rake test1
test-code-job2:
stage: test
script:
- echo "If the files are built successfully, test other files with a different command:"
- rake test2
解释: 在这个例子中,build 阶段的 build-code-job 作业首先运行。 它输出作业使用的 Ruby 版本,然后运行 rake 来构建项目文件。 如果此作业成功完成,则 test 阶段中的两个 test-code-job 作业将并行启动并对文件运行测试。
示例中的完整流水线由三个作业组成,分为两个阶段,build 和 test。 每次将更改推送到项目中的任何分支时,流水线都会运行。
2. pipeline
管道是持续集成、交付和部署的顶级组件。
管道包括:
- jobs,它定义了要做什么。例如,编译或测试代码的作业。
- stages,定义何时运行作业。例如,在编译代码的阶段之后运行测试的阶段。
作业由runners执行。如果有足够的并发运行者,同一阶段的多个作业将并行执行。
如果一个阶段中的所有作业都成功,则管道将进入下一个阶段。
如果一个阶段中的任何作业失败,则(通常)不会执行下一个阶段,并且管道会提前结束。
一般来说,管道是自动执行的,一旦创建就不需要干预。但是,有时您也可以手动与管道交互。
一个典型的管道可能包含四个阶段,按以下顺序执行:
一个build stage,有一个工作叫做compile.
一个test stage,有两个作业称为test1和test2。
一个staging stage,有一个工作叫做deploy-to-stage.
一个production stage,有一个工作叫做deploy-to-prod.
总结 类似pipeline 就是我们运行货物(代码)的一个传送带(管道)。
3. GitLab Runner
首先有了 制定的规则以及管道,那肯定必须要有工人去作业与这些管道才能让管道动起来。
GitLab Runner 是一个与 GitLab CI/CD 一起使用以在管道中运行作业的应用程序。
可以选择在拥有或管理的基础设施上安装GitLab Runner 应用程序,就是在自己的服务器上安装 Runner 。如果这样做,出于安全和性能原因,您应该将 GitLab Runner 安装在与托管 GitLab 实例的机器不同的机器上。当您使用不同的机器时,可以在每台机器上拥有不同的操作系统和工具,例如 Kubernetes 或 Docker。
- 同时运行多个作业。
- 对多个服务器(甚至每个项目)使用多个令牌。
- 限制每个令牌的并发作业数。
4.gitlab-ci.yml的一些关键字
关键字 | 描述 |
---|---|
default | 工作关键字的自定义默认值。 |
include | 从其他 YAML 文件导入配置 |
stages | 流水线阶段的名称和顺序 |
variables | 为管道中的所有作业定义 CI/CD 变量 |
workflow | 控制运行什么类型的管道 |
这里列举了 最外层的几个关键字,其中有一些的关键字的使用受版本的影响,使用时注意一些版本是否引入
总结
以上就是今天要讲的内容,本文仅仅简单介绍了GitLabCI的一些介绍以及使用,在 GitLab CI/CD官网中有更加详细的一些关键字参数等的配置包括 cache缓存、定时的pipeline都是比较好用的一些功能点,更高级的版本中也会加入越来越多的关键字去适配各种不同的pipeline功能。