以Spring boot项目为例。传统方式是本地生成jar包，FTP上传服务器，重启服务；如果是内网测试服，也可以在服务器上安装git，在服务器上编译打包。但这都需要人为干预，于是CI/CD就出现了。
CI：Continuous Integration（持续集成）。自动构建和测试每次提交的代码，以确保所引入的更改符合所有测试、准则和代码合规性标准。
CD：Continuous Delivery（持续交付）和Continuous Deployment（持续部署）。基于CI，前者侧重于交付给客户或质量团队（比如决定是否对新版本进行压测），而后手动部署/自动部署，如果是自动部署的话就是持续部署了。
CI/CD的工具有很多，最流行的当属jenkins。不过以笔者为数不多的经验来看，作为后起之秀的gitlab更简单一点，也更灵活，不会像jenkins那样笨重。当然，两者的概念都是挺多的，没有师父，光靠自己入门都不容易。
GitLab-CI/CD流程示例
从左往右看，首先研发人员完成需求提交代码到 GitLab。GitLab 触发一次 Build，构建好服务，然后开始跑单元测试、集成测试。等待测试结果通过后，再由负责该项目的同事进行 CodeReview，灰度发布，正式部署到线上。
概念本文基于GitLab 13.7版本
PiplinePipelines comprise:
Jobs, which define what to do. For example, jobs that compile or test code.
Stages, which define when to run the jobs. For example, stages that run tests after stages that compile the code.
Jobs are executed by runners. Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.
StagesManage：项目周期或团队周期的各项数据统计分析。主要是各环节耗时统计，比如对于典型的Issue（提出问题）->Plan（列入计划）->Code（编码）->Test（测试）->Package（打包）流程，每个环节的耗时决定了整体问题处理的响应速度。
Plan：借助诸多工具进行有效的项目管理。
Create：代码管理。
Verify：代码质量分析、代码合并（持续集成）、单元测试等。
Package：将代码打包，并作为依赖库对外提供。
Secure（ULTIMATE版提供）：检查应用程序是否存在可能导致未经授权访问、数据泄漏或拒绝服务的安全漏洞。GitLab可以对应用程序的代码执行静态和动态测试，查找已知的缺陷并在合并请求中报告它们。然后可以在合并之前修复缺陷。安全团队可以使用仪表板获取项目和组的高级视图，并在需要时启动修正过程。
Release：持续交付。
Configure：配置[文件]参与DevOps各环节。
Monitor：GitLab收集并显示已部署应用程序的性能指标，以便您可以立即知道代码更改如何影响生产环境。
Defend：若干用于服务安全防御的中间件。
上述包含了GitLab-DevOps整个流程的所有环节，CI/CD只是其中的一部分。
GitLab Runner可以安装在任意机子上，通过它可以[在一台机子上]注册多个runner实例到gitlab服务器。每个runner用于执行一个或多个具体任务（如build、test）。
runner有以下三类，可用范围从大到小
Shared runners are available to all groups and projects in a GitLab instance.
Group runners are available to all projects and subgroups in a group.
Specific runners are associated with specific projects. Typically, specific runners are used for one project at a time.
我们可以直接安装GitLab Runner到宿主机，也可以使用docker方式安装。注意这两种方式会影响到后续.gitlab-ci.yml中对pipline的定义。比如要编译maven项目，如果executor设为shell，那么若宿主机中安装有mvn命令，前者可以在scripts中直接使用mvn，而后者并不能，只能通过定义Dockerfile，在其中定义搭建mvn环境到编译代码的整个流程。
采用docker方式安装的话，可以参考Docker搭建自己的Gitlab CI Runner
docker pull gitlab/gitlab-runner:latest docker run -d --name inkscreen-api-runner --restart always \ -v /srv/gitlab-runner/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latest注册runner实例
docker exec -it inkscreen-api-runner gitlab-runner register会让我们填一系列配置项，如下：
Enter the GitLab instance URL (for example, https://gitlab.com/): :9980/ Enter the registration token: cJMXGJWx7qx9AmpSc6ee Enter a description for the runner: [a0debaaf80a9]: runner for InkScreen-API project Enter tags for the runner (comma-separated): InkScreenAPI Registering runner... succeeded runner=cJMXGJWx Enter an executor: docker-ssh, shell, docker-ssh+machine, kubernetes, custom, parallels, ssh, virtualbox, docker+machine, docker: docker Enter the default Docker image (for example, ruby:2.6): maven:3-jdk-8