[实习]git ci/cd概念，创建流程以及常见字段含义

1.基本概念

1.1 CI/CD

CI，Continuous Integration，为持续集成。即在代码构建过程中持续地进行代码的集成、构建、以及自动化测试等；有了 CI 工具，我们可以在代码提交的过程中通过单元测试等尽早地发现引入的错误；
CD，Continuous Deployment，为持续交付。在代码构建完毕后，可以方便地将新版本部署上线，这样有利于快速迭代并交付产品。

1.2 GitLab CI/CD

GitLab CI/CD（后简称 GitLab CI）是一套基于 GitLab 的 CI/CD 系统，可以让开发人员通过 .gitlab-ci.yml 在项目中配置 CI/CD 流程，在提交后，系统可以自动/手动地执行任务，完成 CI/CD 操作。而且，它的配置非常简单，CI Runner 由 Go 语言编写，最终打包成单文件，所以只需要一个 Runner 程序、以及一个用于运行 jobs 的执行平台（如裸机+SSH，Docker 或 Kubernetes 等，我推荐用 Docker，因为搭建相当容易）即可运行一套完整的 CI/CD 系统。

GitLab提供持续集成服务。如果添加一个.gitlab-ci.yml文件到项目根目录，并配置GitLab项目使用某个Runner，然后每一次提交或者是推送都会触发CI pipeline.

.gitlab-ci.yml文件会告诉GitLab Runner 做什么。默认情况下，它运行一个pipeline，分为三个阶段：build，test，deploy。你并不需要用到所有的阶段，没有job的阶段会被忽略。

如果一切运行正常(没有非零的返回值)，您将得到与commit关联的漂亮的绿色标记。这使得在查看代码之前，很容易就能看出是否有一个提交导致了测试失败。

大多数项目使用GitLab CI服务来运行测试套件，这样如果开发人员发现问题就会及时得到反馈。

下面针对 Gitlab CI 平台的一些基本概念做一个简单介绍：

Job

	Job 为任务，是 GitLab CI 系统中可以独立控制并运行的最小单位。 
	在提交代码后，开发者可以针对特定的 commit。完成一个或多个 job，从而进行 CI/CD 操作。

Pipeline

	Pipeline 即流水线，可以像流水线一样执行多个 Job. 
	在代码提交或 MR 被合并时，GitLab 可以在最新生成的 commit上建立一个 pipeline，
	在同一个 pipeline 上产生的多个任务中，所用到的代码版本是一致的。

Stage

	一般的流水线通常会分为几段；在 pipeline中，可以将多个任务划分在多个阶段中，
	一般只有当前一阶段的所有任务都执行成功后，下一阶段的任务才可被执行。

注：如果某一阶段的任务均被设定为“允许失败”，那这个阶段的任务执行情况，不会影响到下一阶段的执行。

2. CI/CD 流程配置

2.1 完整定义

GitLab 允许在项目中编写 .gitlab-ci.yml 文件，来配置 CI/CD 流程。

下面，我们来编写一个简单的测试→构建→部署的 CI/CD 流程。

首先，可以定义流程所包含的阶段。我们的流程包含三个阶段：测试、构建和部署。
在 .gitlab-ci.yml 的开头，定义好所有阶段、以及执行每个任务之前所需要的环境变量以及准备工作，然后定义整个流程中包含的所有任务：

stages:
  - test
  - build
  - deploy

variables:
  IMAGE: docker.registry/name/${CI_PROJECT_NAMESPACE}-${CI_PROJECT_NAME}

before_script:
  - IMAGE_TAG=${IMAGE}:${CI_COMMIT_SHA:0:8}

test_all:
  image: "pymicro"
  stage: test
  services:
    - name: mysql:5.6
      alias: mysql
  veriables:
    MYSQL_DATABASE: db
    MYSQL_ROOT_PASSWORD: password
  before_script:
    - pip install -U -r requirements.txt
  script:
    - flake8 app
    - pytest tests

build_image:
  image: "docker:17.11"
  stage: build
  services:
    - name: "docker:17.12.0-ce-dind"
      alias: dockerd
  variables:
    DOCKER_HOST: tcp://dockerd:2375
  only:
    - master
  tags:
    - build
  script:
    - docker build -t ${IMAGE_TAG} -f Dockerfile .
    - docker push ${IMAGE_TAG}

deploy_production:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  only:
    - master
  when: manual
  tags:
    - deploy-production
  script:
    - kubectl set image deploy/myproject "app=${IMAGE_TAG}" --record

在每个任务中，通常会包含 image, stage, services, script等字段。

其中，stage定义了任务所属的阶段。比如你命名了deploy_production，用作说明这里是要干嘛的，然后在下面写了stage: deploy，就知道属于初始定义的三个阶段的deploy阶段。

image字段指定了执行任务时所需要的 docker 镜像；

services指定了执行任务时所需的依赖服务（如数据库、Docker 服务器等）；

而 script直接定义了任务所需执行的命令，一般就是脚本指令。

2.2 测试

在测试任务中，我们启动了 MySQL 服务，并通过环境变量注入了 MySQL 的初始数据库以及 Root 密码，在服务启动后，Runner 会运行 before_script中的命令来安装所需依赖；安装成功后就会运行 script属性中的命令来进行代码风格检查以及单元测试；
可以注意到，我们的 MySQL 服务下有一个alias属性标识服务别名。如果你的 Runner 运行在 Docker 平台下，你可以直接通过服务别名访问到该测试环境中对应的服务。比如在这个任务中，我们就可以用 mysql://root:password@mysql/db来访问测试数据库。

2.3 构建

在构建任务中，我们会用Dockerfile注入依赖，将工程打包成 Docker 镜像并上传；

我们为这个任务定义了一些额外的属性：tags属性可以标记这个任务将在含有特定 tags的 CI Runner 上运行；

而 only属性表示只有这个 commit 在特定的分支下（如 master）时，才可以在此 commit 上运行这个任务。换句话说就是指明了job的执行场景，可以是分支名，表明只有 某个分支可以执行build，如果要用排除法反向指定，可以用except。

另外，我们在 before_scripts 中，通过环境变量拿到了项目所属的组，以及项目名称。GitLab 会在运行任务前，向环境中注入很多环境变量，来表明运行环境以及上下文。所有的环境变量列表可以看文档。

2.4 部署

在部署任务中，我们会用kubectl set image命令将我们刚刚构建的镜像发布到生产环境。
这个任务中的 when 表示运行该任务所需要的必要条件，如前一阶段任务全部成功。when: manual表示该操作只允许手动触发。该属性具有四个选项，具体请见文档，很常见的还有on success。

至此，我们在 .gitlab-ci.yml 中定义了一套完整的测试→构建→部署流程。

原文链接： https://blog.stdioa.com/2018/06/gitlab-cicd-fundmental/