持续集成、持续交付环境的搭建过程

  首先，此文没有完结，一边补充功能一边写内容；另外，文章主要写CI的思路过程，而不是详细的命令

  持续集成、持续交付、持续部署的区别网上有说明，持续部署有点远(难）,理想化，并且一家研究院在做持续交付的国内标准，环境搭建好了可以认证，一举两得，所以按持续交付搭建环境

  为什么要建立持续交付环境？其实IDE就是一个单人持续交付环境，比如eclipse，通过插件可以实现版本管理、代码静态检查、单元测试，部署，和系统测试，直接就完成持续交付了，但是，但是，团队的持续交付就有点力不从心了！（多年前我做C开发时，几百人的开发团队，用SVN做版本管理，都是靠人促发编译，部署的，单元测试也是本地用VC跑的，每个人的环境都可能存在差异），就是说持续交付能让团队修改代码以后，快速看到系统跑起来的样子；

  这里选的搭建JAVA WEB的持续交付环境，因为和公司的业务相关，以java web服务为主(最主要我会些JAVA，这家单位不用C)，其它应用可以参考思路，部分工具不同

  网络上有DevOps的文章，关于持续交付的工具链，主要是以gitlab为主，因为gitlab既有版本管理功能又有持续集成的能力，其它工具围绕gitlab开展，java的IDE就用eclipse，在本地也可以验证javaweb程序，

   1、提交代码到版本管理系统：在centos上建立gitlab环境(linux下的开源环境比较好)，和tomcat环境，java用系统自带的就行，然后用eclipse的git插件把整个项目push到gitlab的某个分支上，

  2、编译打包javaweb程序：由于开发环境是windows下的eclipse，而持续集成是linux环境，需要在linux也能build项目，这时选用的是ant工具(maven感觉没ant灵活，而且要建maven的项目，手上的程序每用maven，所以先用ant，没准以后会换成maven)，ant参照build.xml的定义批量执行各种操作，关键是项目的build.xml怎么做？用eclipse的export功能直接导出build.xml，然后将文件中的路径改成linux的路径，并且添加将编译代码打成war包的一个任务，这样用ant就能直接打成war包了，这时候打包还不完整，怎么完整呢？用我高智商的小技巧(因为我对java项目build过程也不熟：）)：用eclipse的export功能直接导出war包，与linux下用ant build的包比较(winrar打开看)，少什么文件就修改build.xml增加上，最后能用ant一次打成完整的war包就OK了，手动放到tomcat下试试是否好用

  3、让gitllab持续集成：gitlab集成了持续集成能力，就是可以提交代码以后自动执行build等任务，调用的是gitlab-multi-runner，安装它，我选的是runner执行shell命令(这个比较简单，先入手)，这样可以和ant配合，完成各种各种功能了，配置ci的yml文件，指定一个工作是调用ant就OK了

 4、让gitlab持续交付：这里再进一步，修改ant的build.xml，把build出来的war包放到tomcat的应用目录下就完成部署啦，其实呢，少了代码检查和测试的事情(都懒，单元测试让gitlab自动做，别偷懒)，后续补充到环境中，另外这个环境并行能力差，就是多个人同时提交，要一个一个来build和验证，慢一点点，这要修改部署环境，可以每个持续交付任务一个独立的服务器，这件事也要后续完善(其实小项目就不用完善啦，啦啦啦)；

      好了，先到这里，环境继续完善以后再补充文章把