持续集成

index:
1，持续集成有什么好处
2，怎么搭建一个持续集成
3，持续集成的最佳实现

一，持续集成有什么好处？

持续集成是敏捷开发中的一种实践，它通过对代码不间断的跟踪,来检查代码的变化。

 

可以让团队在持续的基础上收到提示，我们就可以根据提示来修改代码，那么就不用等到开发后期来手动寻找和修复代码的

 

缺陷。也就是说程序员的每一次代码提交，持续集成都会自动的从版本控制中把代码check out到一个空目录里，并且自动

 

运行所有的单元测试。它不是减少Build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。

二，怎么搭建一个持续集成？

我们使用持续集成，需要用到CC服务器 ，CC服务器是执行持续集成的一种服务器，CC服务器只会更新我们提交的代码，

 

而不会去改动我们的源代码。把要使用持续集成的项目下载到CC服务器的工程目录下面(这里不能通过编译到构建中)。然

 

后CC服务器通过配置config.xml文件。这里配置包括定时构建的时间，来找到项目中build.xml文件，它是一个构建文件，

 

持续集成会自动使用内置的Ant对它进行构建。在这里我们就可以对build文件进行一些配置：如你想持续集成自动为你进行

 

单元测试，我们就要在这里配置一些测试工具，如junit。(在build.xml文件中，用target节点里的junit来配置junit)你想

 

让它自己检查你的代码规范，你就要配置检查代码工具，如PMD。通过这一系列的配置，我们就可以让持续集成做我们想做

 

的事。

三，持续集成的最佳实现？

以前在我们公司里，同事教了一些持续集成的最佳实践，再加上自己去图书馆阅览了相关的书籍，总结了下持续集成的最佳

 

实践，这些最佳实践能大大的提高持续集成的效率。如

要经常提交代码：
经常提交代码，能最大限度减少版本冲突。所以要早提交，常提交。

不要提交无法构建的代码：
提交之前要把错误搞定才能提交代码。

立即修复无法集成的构建：
立即修改发现的错误，先解决失败的问题，然后再继续你的手头工作。避免出现破窗理论。

执行私有化构建，避免迁出无法构建的代码：
在提交服务器之前，先在本地运行一次build文件。这样如果出现错误，就可以及时解决错误。

避免迁出无法构建的代码：
如果已发现错误了，就不能再更新代码了，让出错的那个人更新下来，把错误解决掉，然后再提交上去。