由于不可抗力 /(ㄒoㄒ)/~~国庆学习了 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功能。