1. 初识持续集成与持续部署系统
这里说的持续集成与持续部署系统范围比较广，其功能包括代码管理，版本控制，自动编译打包以及自动部署等等，当然，如果服务按照docker镜像来部署，则还包括自动打包成镜像文件以及自动push到镜像仓库等步骤。
不管是在微服务架构中，还是在传统的单体架构中，搭建一套持续集成与持续部署系统都是非常必要的，因为这回大大减少人力工作，如果没有持续集成与持续部署系统，我们需要自己管理代码，进行版本控制，如果一个服务的版本很多，或者代码量很大，就变的非常不好管理如果没有持续集成与持续部署系统，我们需要手动将代码打成jar包，手动上传到一台服务器，手动关掉之前的服务，手动启动jar包进程，如果按照Docker镜像来部署，我们还需要手动将服务打成镜像，手动将镜像文件push到镜像仓库，手动将镜像文件从镜像库pull下来，手动将镜像运行起来。这一切都是手动的！效率极低，并且容易出错。所以，搭建一套持续集成与持续部署系统是非常有必要的！下面我们开启持续集成与持续部署之旅。
2. 系统总体架构
在整个架构中，主要包含三大组件：GitLab,Jenkins以及Docker-Registry.还有一个webhook,这是用来轻松链接Gitlab和Jenkisn的纽带。它可以非常方便的实现持续集成与持续部署。如果不使用docker部署，则不必要搭建Docker-Registry。下面依次介绍各个组件。
2.1. 初识gitlab
GItlab是一款代码管理的工具，是目前最受企业欢迎的代码管理工具，其中非常好用的webhook工具，使得与jenkisn的集成非常简单。
2.2. 初识Jenkins
jenkins主要用于管理版本，进行代码的编译和部署，使用webhook插件可以实现与GitLab的集成。jenkisn的安装最多还是使用docker镜像。、
2.3. 初始Docker-Registry
Docker-Registry是存放Docker镜像的仓库，可以类比GitLab.
3. 持续集成与持续部署系统工作原理
介绍完各个组件之后，来看一下整套持续集成与持续部署系统的工作原理。
3.1使用Jar包部署项目的整体流程
- 第一步， 开发人员使用git客户端，将代码推送到GitLab
- 第二步， GitLab的webhook插件会通知jenkins进行工作
- 第三步， Jenkins从gitLab上拉去代码并使用Maven进行编译打包
- 第四步， jenkins调用服务器上的shell脚本停止之前的服务，并启动jar进程
3.2 使用Docker镜像部署项目的整体流程。
- 第一步， 开发人员使用git客户端， 将代码push到GitLab
- 第二步， GitLab上的webhook插件通知jenkins进行工作
- 第三步， jenkisn从gitLab拉去代码并使用docker-maven－plugin进行编译打包，最后将jar包打成镜像。
- jenkins将镜像推送到Docker-Registry
- 第五步， jenkisn调用服务器上的shell脚本从Docker-Registry拉去镜像，然后停止之前的服务，最后重新启动Docker镜像。
