持续集成搭建心得

在公司持续集成这个弄了一年多了，最近也查了一些关于这方面的资料，现在看发现感触还是挺多的，也觉得有必要进行下总结和回顾。

一：持续集成理念

持续集成说白了目的就是在团队开发过程中可以不断去集成，不断去发布，这可以及时的得到结果和问题。这样可以尽早的规避风险，给人一种安全感，减少后期代码维护成本和上传的时间人工成本，还有对于版本的控制，保证线上问题的及时回滚。

二：持续集成架构

们这做的持续集成是基于Jenkins工具，jenkins是一款java开发的开源平台，支持多种语言的编译，使用也比较简单。众所周知，对于一个项目的集成上线一般经历的是：拉取最新项目，编译成功，线上差异文件对比，ftp或其他方式上传。这个过程非常耗时，说不定有问题，然后某个人喊，XX帮我再传下，有个BUG，这时候你就特别想揍他一顿。

jenkins是个不错的集成平台，这个有很多的插件可以集成到jenkins中，如自动化测试，sonar等等，但是，jenkins在持续集成中，主要功能还是进行代码的拉取和编译生成。

这时候，就会出现一个问题，如果仅仅是进行拉去编译，发布怎么办，难道靠调取命令复制吗？如果有多台服务器难道需要每台服务器都装个jenkins，这个绝对不现实。这时候，就需要jenkins编译生成好，然后通过脚本命令的方式生成上传包和版本号，放到制品库中，这样既方便管理，又方便发布。

版本出来了，那么下面就是发布，发布的话这块完全可以自己写成一个功能，上传包都有了，下面无非就是些上传下载什么的统一管理的功能了。

三：持续集成使用中问题

1，现阶段许多持续集成配置过于复杂，也因为中间使用了jenkins导致配置文件过多，这里完全不必要的人力浪费。

2，整理发现jenkins平台没有使用的必要，完全可以舍弃，因为总体上说，发现jenkins主要就是拉取代码进行编译，这个完全可以通过程序实现，jenkins反而会增加系统复杂度，同时需要两个系统，jenkins和发布系统，两个账号，而且jenkins需要需求不能满足我们的需求。

3，持续集成给我感觉是，只能作为系统中的一环，而不能作为一个项目，这个完全可以做成一个整套关于站点查询，服务器查询，自动站点搭建，持续集成，上传等等一套流程作为一个后台系统，而不是单独作为一个系统来进行开发和使用。

4，持续集成完全可以整合进入代码检测sonar和自动化测试这方面的。虽然不被大家所重视，有时候听见，XX，这个比较紧急，时间不够，来不及进行codeview和集成测试了，先上线以后再说  等等

四：持续集成阻碍

1，用于维护的人力等代价过高

2，构建太多的失败

3，需求的变更过快

4，有时候，因为一个小小的问题，但是要经历集成，构建，测试，部署等等工作，让人感觉更加的麻烦。

5，额外的软硬件成本