相信持续集成在现今的软件行业，应该是必须具备的标准之一。你的项目还没有持续集成吗？赶紧弄一个吧！
成功的持续集成环境，在我看来包括几个重要部分：
第1、2项相信是必须的。回想在没有 Maven 之前，引用外部依赖都是透过拷贝到本地文件来应用的，Maven首先引进依赖管理的概念，加上一个中央库，让发布变得一个标准动作，也统一了Package的归属地，就是中央库。
我之前的一家公司，在推行持续集成，就花了不少力气。他们主要核心系统都是跑.NET的，没有发布的软件库，没有依赖管理，都是透过拷贝来引用其他DLL。首先我往依赖管理入手，发现.NET也开始有类似Maven的依赖管理：Nuget 。但Nuget好像没有类似Maven的SNAPSHOT版本，对来自Maven世界的我，项目的相互依赖更新比较不直观，操作起来比较麻烦。
在引入Nuget的同时，也引入了内部的Nuget库（相当于软件库），让编译后的软件发布到这个Nuget库，发布过程开始成形了。
第3项是配置管理。配置管理对当时的程序员来说，是比较陌生的。配置是什么？为什么不把配置存在数据库里？这些都是有趣的问题。在我当时的解释，当环境改变的时候需要改变的参数，就是需要配置管理的东西。如：系统在测试环境跑，是这些配置参数；在生产环境跑，是另外一些配置参数。可能的变数如：数据库的链接串，外部WebService接口的URL等。
为什么配置尽量不要放在数据库？原因简单，如上说数据库的链接串都是配置，放在数据库不是很吊诡吗？再者，放在数据库上，任何配置上的变更跟踪是很麻烦的一件事情。相反，用一个纯文件（INI）方式保存在GIT之类的版本控制，替换方便之余，版本控制也到位。
配置管理在持续集成的地位非常重要，因为一般的持续集成过程中，我们会跑一些集成测试的。集成测试的环境如果是写死在代码，不能配置的，集成测试几乎是不可能的。一个相对简单的配置方式（纯文件），对集成测试相当有利。
我在上一家公司，发布整个系统的更新，需要1－2小时。当中原因是很多东西需要一起发布，不存在单独某个部件发布。问题的核心是架构比较僵硬（J2EE的EJB／WAR），更新面不好控制，保守一点的做法就是全部发布会比较安全，结果是几个 >10MB 的 EAR 包。
由于J2EE框架比较笨重，正规标准的框架上基本不支持动态加载，要改变就需要用一些比较轻量框架。
有了轻量的框架以后，就可以用贡献式编程来作指导思想来解决，让依赖成为一些贡献，可以对系统保持持续的贡献，持续优化。每个贡献基本上可以单独测试，让集成测试的覆盖面可以下放到模块测试，降低集成测试的要求。
贡献式编程对持续集成来说，真的是如虎添翼。由于在贡献层面，对某个贡献的引用就是把这个功能部署，要去掉某个功能贡献，就不需要引用。再配合配置管理，让系统的构成变成一个配置的工作，轻松而且有效。
原文地址：http://blog.csdn.net/kmtong/article/details/39206757
