这篇基本介绍只介绍 GitLab CI，不会写具体的使用细节，旨在让新接触 GitLab CI 的同学先对它有个基本的认识，直接看官网文档可能需要多花点时间才能理清一些概念。
GitLab CI 的设计很灵活，有多种使用方案，我在接下来会针对最常用的几种情况写一系列包括实现细节步骤的文章。
前置需求
当前有 3 台服务器 develop, staging, production 分别对应代码仓库上的三个分支：develop, staging, master。
要求 push 代码到仓库时会触发 CI 的执行：
1. build app
2. testing app
3. deploy to server
代码 push 到哪个分支，就把项目部署到相应的服务器上。
GitLab CI 的重要概念
要理解 GitLab CI 的工作方式，必须要理解两个概念：
- Pipeline
- Runner
上面说的 CI 执行过程就是 pipeline，它定义了项目的构建、测试、部署等的执行过程。
我们需要在每个项目上定义一个 pipeline。
定义一个 pipeline 就是在项目代码根目录创建文件：.gitlab-ci.yml.
定义好 pipeline 后，GitLab CI 会读取并执行这个 pipeline，执行的程序叫做 Runner。
Runner 是负责执行 pipeline 的程序。
通常 Runner 需要我们自己安装并运行在自己的服务器上，当然也可以使用 gitlab.com 官方提供的免费的 Shared Runner 服务。
GitLab CI 的工作方式
- Pipeline 的触发
当开发者 Push 代码到某个分支时，如果我们定义了 Pipeline，也就是代码根目录中有 .gitlab-ci.yml 文件，GitLab 会自动触发 Pipeline 的执行。
- Pipeline 的执行
Pipeline 执行时，首先会 pull 下来被触发分支的代码，然后执行你在 pipline 中定义的 Job，Job 是你指定的一些 shell scripts，它就是你构建项目的逻辑。
小结
简单介绍一下 GitLab CI 的几个重要概念，接下来会通过实例来详细讲解 GitLab CI 的使用。
