考虑到目前的实际情况，以及后期项目的维护。我们准备使用jenkins。
在尽量少出错的情况下将整个项目各个环节剥离开，也为了更好的定位错误发生的阶段。
首先，要去了解什么是jenkins。当我们在考虑到使用jenkins的时候，还必须要知道另外的俩个概念。CI和CD。

CI持续集成（CONTINUOUS INTEGRATION）

在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。

CD：持续部署（CONTINUOUS DEPLOYMENT）

在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团
队工程化的程度，任何修改通过了所有已有的工作流就会直接和客户见面，只有当一个修改在工作流中构建          
失败才能阻止它部署到产品线。
持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布 
日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。

CD：持续交付（CONTINUOUS DELIVERY）

它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的    
状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

持续部署和持续交付

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交    
付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

那么这个时候Jenkins也就呼之欲出了，正如他们主页所说。

image.png image.png

根据官方以及其他查阅资料我尝试在本机先部署一个简单的jenkins服务。
安装主要参考,但因为技术的发展与升级，在安装的过程中也出现了一些问题，也在一一的解决中。
现在主要做一些前期的准备工作，具体的一些命令的掌握与使用，还需要一个过程。
现在打算做的是本地Jenkins+maven+git 搭建项目自动化部署集成环境,后期也可能会引入docker容器。

参考1
参考2