1. .gitlab-ci.yaml

这两天工作上在研究Gitlab的CI/CD，根据目前了解到的知识点来看。Gitlab的CI/CD是从一个代码仓库根目录下的.gitlab-ci.yaml文件作为入口。在这个文件中定义了CI/CD的各个阶段以及在每个阶段中要做的各种工作。

先给出一个示例文件的内容，然后根据示例文件的内容来说一下这个文件的组织结构：

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

上面是gitlab官方给出的一个示例文件，整个文件分为两个部分：

• 第一部分stages:，定义这个CI/CD流程有几个阶段
• 第二部分，即下面三个任务（job），在每个任务中使用关键字stage:来标识它是属于哪个阶段的任务。而下面的script:关键字定义的内容就是这个任务实际要做的事情。

对于一个完整的CI/CD来说应该包含4个阶段，即：

• build，构建阶段，在这个阶段会执行代码编译工作。
• test，测试阶段，在这个阶段中会使用各种自动化测试用例来测试你的代码是否正常工作。
• staging，我的理解是预部署阶段，即将测试通过的代码部署到预发布环境，进行正式发布前的回归测试。
• production，即生产环境阶段，将预发布环境测试通过的代码发布到正式环境上。

而实际的使用中，则是会根据你自己的环境来进行取舍。例如对于一些小公司，根本没有预发布环境，那么测试通过就会直接发布到正式环境上。而有些公司可能根本没有测试的岗位，在 build完毕后，就发布到测试环境，由开发直接进行调测，调测通过后就发布到正式环境。

流水线的阶段和每个阶段的任务定义好以后，在默认情况下，如果有开发人员往这个仓库里提交代码，就会触发对应的流水线。之后就按照定义的阶段依次执行各个阶段里的任务，目前知道的执行任务的规则是：

• 同一个阶段里的任务会并行执行
• 可以通过设置让任务按照顺序来执行（例如下一个任务是根据上一个任务的结果来执行）
• 只要有一个任务失败，整个流水线就会执行失败。（可以通过一些设置来跳过单个失败任务）
• 每个阶段是按照顺序执行，即上一个阶段的任务全部执行完毕后，才会执行下一个阶段的任务。

流水线中的任务是被流水线关联的Runner获取并执行的，在昨天发布的文章里说到了一些Runner的基础知识，说过在流水线里是通过Runner的名称或者Tag来调用Runner的。

以上就是.gitlab-ci.yaml文件相关的基础知识，在看了这些基础东西后，留下了很多疑惑等待探索：

• 怎么定义任务所需的变量？
• 怎么根据条件来执行不同的任务？
• 每个阶段的任务结果怎么处理？

后面会继续学习这个工具的使用，并继续分享学习的笔记。