1、CI/CD简介
CI/CD 是一种持续开发软件的方法，侧重于软件开发过程中的自动化，可以不断地进行构建、测试和部署代码。使用这种方法，从新代码开发到部署，可以减少人工干预甚至不用干预。
（1）CI(Continuous Integration)：持续集成，也就是当每一次更改的代码被推送到远程分支后，可以创建一组脚本来自动地构建和测试这些更改，确保这些更改可以通过一些基本的准则，减少引入错误的机会
（2）CD：(Continuous Delivery)：持续交付，在持续集成的基础上更进一步，当每一次更改的代码落库后，不仅会构建和测试，也会进行部署，但是部署需要人工干预，手动的有目的进行部署
（3）(Continuous Deployment)：持续部署，持续集成之外的另一个步骤，类似于持续交付。不同之处在于，它不是手动部署应用程序，而是将其设置为自动部署。不需要人为干预
Gitlab CI/CD 也就是 Gitlab 提供了上面的 CI/CD 能力，可以进行持续集成，持续交付和持续部署。
2、GitLab CI/CD 工作流程
（1）简单说就是开发者在push或者merge代码到指定分支的时候，会触发CI/CD，GitLab CI/CD配置文件（.gitlab-ci.yml）中的Job需要通过GitLab-Runner来执行，执行过后的产物可以直接用来部署。这里会涉及Pipeline 、Stages、Jobs几个概念。
Pipelines：流水线 (在根目录包含.gitlab-ci.yml文件的代码push | merge时候会生成对应的流水线)
Stages：阶段 (定义什么时候执行Jobs，比如：在build阶段执行代码编译打包任务)
Jobs：任务是GitLab CI系统中可以独立控制并运行的最小单位 (定义了该做什么，比如：编译和测试代码)
流水线包含一个或多个阶段，每个阶段又可以有多个任务，这就是他们之间的一个关系。每个Job可以指定用来执行它的Runner，同一个Stage的多个Job可并发执行，Job中至少要包含script元素用来编写该任务运行的脚本，only元素用来指定能触发CI/CD的代码分支，tags元素用来指定该Job用哪个Runner来执行
如果同一个Stage中的所有Job都执行成功，Pipeline就会进入下一个Stage；如果一个Stage中的任何一个Job执行失败，Pipeline就不会进入下一个Stage，提前结束。
（2）前面有说到Job是需要GitLab-Runner才能运行起来的，那么它们是怎么关联起来的呢？
上面这张图采用docker来安装GitLab-Runner，然后将GitLab的实例URL和Token在GitLab-Runner上进行注册，这样GitLab和GitLab-Runner就能够关联上。
（3）GitLab-Runner注册Runners主要有两种方式：
（3.1） 在GitLab的admin area进入Runners菜单，里面就会有GitLab Instance URL和Token
（3.2） 进到具体代码仓库，点开setting菜单，再进入CI/CD中的Runners，里面也会有GitLab Instance URL和Token
3、GitLab CI/CD完整执行过程如下：
（1）编写CI/CD配置文件.gitlab-ci.yml，GitLab会检测到它，配置文件里可指定可触发CI/CD的代码分支
（2）在push或者merge代码到上述指定的分支，会触发CI/CD流程，就会生成一个对应的Pipeline
（3）GitLab-Runner就会将代码拉进来执行Pipeline中的Job，每个Job可指定用来执行它的Runner
（4）Runner会初始化Excutor，然后通过git把GitLab的代码仓库拉过来，按照.gitlab-ci.yml里定义的任务来执行
（5）本项目把Runner执行后的产物通过挂载的方式，把打包后的代码挂载到Nginx的根目录中，这样就完成了自动化部署
4、总结
GitLab CI/CD最主要的两个步骤就是编写.gitlab-ci.yml，然后到GitLab-Runner中注册Runner，Runner可以是一个虚拟机，物理机，docker容器，或者一个容器集群。GitLab与Runner之间通过API进行通信，因此只需要Runner所在的机器有网络并且可以访问GitLab服务器即可。