什么是持续集成/持续部署（CI/CD）？
简单理解就是把代码测试、打包、发布等工作交给一些工具来自动完成。这样可以提高效率，减少失误，开发人员只需要关心开发和提交代码到git就可以了。
CI/CD
CI，Continuous Integration，为持续集成。即在代码构建过程中持续地进行代码的集成、构建、以及自动化测试等；有了 CI 工具，我们可以在代码提交的过程中通过单元测试等尽早地发现引入的错误；
CD，Continuous Deployment，为持续交付。在代码构建完毕后，可以方便地将新版本部署上线，这样有利于快速迭代并交付产品。
CI的过程包括以下几个步骤
- 提交（合并）代码
- 编译
- 测试
- 发布
不同的项目以及公司步骤可能不同。
持续集成工具
常见的CI工具有很多，目前最为常用的是Jenkins。Jenkins包括一个master和很多个slave。master用于配置和组织节点、任务，slave则用来真正执行配置好的任务。因为用户群体的庞大，Jenkins上的各种插件，尤其是很多可视化插件都非常丰富，可以帮助很多新手快速配置所需的任务。
gitlab-ci是git官方的持续集成工具，在Git工程管理页面上，也有专门的CI配置和展示页。
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-ci是常见的CI平台。简单理解gitlab-ci是一个简易版的jenkins，git服务器兼任了Jenkins master的功能，而我们只需要准备好一个slave即可。而且，gitlab-ci的runner支持多重环境，尤其是Docker还有专属的配置支持。配置过程也非常的简便无脑，比起Jenkins的slave配置可以说是非常好用了。
Gitlab CI 的一些基本概念
job
Job为任务，是GitLab CI系统中可以独立控制并运行的最小单位。 在提交代码后，开发者可以针对特定的commit
完成一个或多个 job，从而进行CI/CD操作，每个Job都会配置一个stage属性，来表示这个Job所处的阶段
Pipeline
Pipeline 即流水线，可以像流水线一样执行多个 Job. 在代码提交或 MR 被合并时，GitLab 可以在最新生成的 commit
上建立一个 pipeline，在同一个 pipeline 上产生的多个任务中，所用到的代码版本是一致的
Stage
一般的流水线通常会分为几段；在 pipeline
中，可以将多个任务划分在多个阶段中，只有当前一阶段的所有任务都执行成功后，下一阶段的任务才可被执行。
CI Pipeline
整条流水线从左向右依次执行，每一列均为一个阶段，而列中的每个可操控元素均为任务。 左边两个阶段的任务是自动执行的任务，在commit提交后即可自动开始运行，执行成功或失败后，可以点击任务右边的按钮重试；而右边两个是手动触发任务，需要人工点击右边的“播放”按钮来手动运行。Pipeline是Gitlab根据项目的.gitlab-ci.yml文件执行的流程，由多个任务节点组成, 而这些Pipeline上的每一个任务节点，都是一个独立的Job。一个Pipleline有若干个stage,每个stage上有至少一个Job
Runner
在特定机器上根据项目的**.gitlab-ci.yml文件，对项目执行pipeline的程序**
怎么做呢？
方案一
使用webhooks,这种方式的原理就是在gitlab项目的Setting里的Integrations设置中增加一个请求url和一个secre