1. Gitlab
GitLab是一个利用Ruby on Rails开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。它拥有与GitHub类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序（Wall）进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
2. Gitlab-CI
Gitlab-CI是GitLab Continuous Integration（Gitlab持续集成）的简称。从Gitlab的8.0版本开始，gitlab就全面集成了Gitlab-CI,并且对所有项目默认开启。只要在项目仓库的根目录添加.gitlab-ci.yml文件，并且配置了Runner（运行器），那么每一次合并请求（MR）或者push都会触发CI pipeline。
GitLab提供持续集成服务。如果添加一个.gitlab-ci.yml文件到项目根目录，并配置GitLab项目使用某个Runner，然后每一次提交或者是推送都会触发CI pipeline.
.gitlab-ci.yml文件会告诉GitLab Runner 做什么。默认情况下，它运行一个pipeline，分为三个阶段：build，test，deploy。你并不需要用到所有的阶段，没有job的阶段会被忽略。
如果一切运行正常(没有非零的返回值)，您将得到与commit关联的漂亮的绿色标记。这使得在查看代码之前，很容易就能看出是否有一个提交导致了测试失败。
大多数项目使用GitLab CI服务来运行测试套件，这样如果开发人员发现问题就会及时得到反馈。
因此，简而言之，CI所需要的步骤可以归结为：
1. 添加.gitlab-ci.yml到项目的根目录
2.配置一个Runner
从此刻开始，在每一次push到Git仓库的过程中，Runner会自动开启pipline，pipline将显示在项目的Pipline页面中。
3. Gitlab-runner
Gitlab-runner是.gitlab-ci.yml脚本的运行器，Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器（或虚拟机）。GitLab
Runner 不需要和Gitlab安装在同一台机器上，但是考虑到GitLab Runner的资源消耗问题和安全问题，也不建议这两者安装在同一台机器上。
Gitlab Runner分为两种，Shared runners和Specific runners。
Specific runners只能被指定的项目使用，Shared runners则可以运行所有开启 Allow shared runners选项的项目。
4. Pipelines
Pipelines是定义于.gitlab-ci.yml中的不同阶段的不同任务。我把Pipelines理解为流水线，流水线包含有多个阶段（stages），每个阶段包含有一个或多个工序（jobs），比如先购料、组装、测试、包装再上线销售，每一次push或者MR都要经过流水线之后才可以合格出厂。而.gitlab-ci.yml正是定义了这条流水线有哪些阶段，每个阶段要做什么事。
5. Badges
徽章，当Pipelines执行完成，会生成徽章，你可以将这些徽章加入到你的README.md文件或者你的网站。
徽章的链接形如：https://docs.gitlab.com/ee/user/project/pipelines/settings.html#badge-styles ,我们用gitlab项目的徽章作为例子：
6.Gitlab CI/CD
引用官网链接：https://docs.gitlab.com/ee/ci/README.html
Continuous Integration, Continuous Delivery, and Continuous Deployment
CI：是持续集成
CD：有2个意思一个是Continuous Delivery(持续交付)和Continuous Deployment(持续部署)
gitlab持续交付和持续部署都可以做
7.持续集成、持续交付、持续部署之间的关系
1) continuous integration 持续集成
持续集成强调对于开发人员的每个提交，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
2 )continuous delivery 持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」中进行更多的测试来更早地发现问题。
比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的自动化集成测试。如果代码没有问题，可以继续手动部署到生产环境中。
3） continuous deployment 持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
从上图可以知道持续部署比持续交付最后一步多了一个自动化部署而已。
