持续集成

　　代码编译不过去是前面的java EE场景中开发人员和构建经历共同面对的问题，开发人员经常处理提交到svn上的有问题的代码，构建经理也花费了很多时间在编译问题解决上。

　　第一眼看上去，这个开发团队需要进行更好的训练来保证不提交有编译问题的代码到svn中，但是，问题是人非圣贤。

　　谁能确保代码可以随时可编译的？在描述的场景中，全都是手工过程，检出代码、执行构建。。经常发现代码不能被编译。构建太晚了以至于发现了问题也不能让开发人员及时修改。这些问题是由于将集成放到了软件开发周期的后一步导致的。那么，为什么不每天集成多次呢？在持续集成环境中，每次集成都被自动化构建验证，包括尽可能早的通过测试用例发现问题。持续集成，或者CI，提供了很好的发现问题的方式。

　　CI servers

　　在大项目中，手工检查不能发现所有的这些因为开发人员或者构建经理引起的问题。修复本身是一项很大的任务。难道你不觉得自动化这些过程会更好吗？下面是一些像CruiseControl 的持续集成服务器。CruiseControl 自动化执行很多琐碎的任务。看看这些：

 

　　每次有人提交代码到svn中，它检出那些代码执行构建。它有一些等待周期设置，可以针对一个人提交多个文件，在这些文件提交期间不启动。每次构建失败，它将检查谁后提交的代码，然后通过email发送一个编译错误日志。这个团队成员应该立刻采取行动来修复这个构建问题。

　　CruiseControl提供了一个web用户界面，用户可以随时查看构建的状态。

　　如果构建失败，CruiseControl并不会再次执行构建，除非又有人提交代码。

　　各种构件像EAR、WAR、Junit reports、PMD reports。。。可以通过web界面下载。

　　准备好了吗?

　　即使想采用这些解决方案和工具，开发人员和构建经理仍然可能遇到一些基本的组织结构问题需要解决。重要的，开发人员和构建经理都需要检查提交到svn的代码的可编译和可随时构建。

　　这个项目是典型的企业开发项目，它所包含的内在java项目或者功能组件存在着错综复杂的关系。每一个都依赖于一个或者多个其他项目，并且每个项目都依赖于提供的功能类型分别提供一个客户端jar（仅包含客户端编译所需要的接口和必需的类）或者一个完整的jar（包含功能组件的所有内容） 文件。所有的这些jar文件都能在各自的项目lib目录下面找到，但是将他们更新到整个项目却是一个巨大的任务，像构建经理上面提到的那样。

　　很难弄清楚互相依赖的这些内部jar和第三方jar文件的版本，这可以通过在统一的位置来存放这些jar文件来解决这个问题。（听起来很像maven管理依赖包的方式）

　　现在，如果项目团队每天创建了新的内部jars，并且svn中的源代码还在更新中，这可能破坏其他组件的功能。你可能收到运行时错误（jar和源代码不一致造成的）。解决办法是统一内部jar的发布版本。首先，开发人员提交代码之前必须经过一套用例测试。源代码库不应该存在不稳定或者未经测试的代码。当每次更新代码的时候，要保证功能的稳定性，应用组件团队在一个统一的位置来发布这个更新的jar文件。每个应用组件团队都应该有专人来运行测试和确保提交代码到svn之前代码通过测试。

　　结论   

　　在这篇文章中，我并不是主张完全采用敏捷开发。即使敏捷世界提出了很多好的佳实践，我仍然尝试保持瀑布模型的主要部分的完整性。你应该在不破坏瀑布模型的主要流程上进行自动化构建和自动化测试。当你开始考虑结对编程，很少的文档或者没有文档，业务相关人员也作为开发的一部分，没有先期设计，没有角色（架构师，构建经理...）。。。。--你正在破坏瀑布模型开发的核心。

　　这些因素将直接影响利害相关人和整个IT团队的工作方式。本文中讨论的佳实践，将为瀑布模型开发团队带来如下的好处--自动化构建提供了代码的随时可构建性，自动化测试为测试代码的过程带来了可预知性、精确性以及可靠性，持续集成对于维护代码的可构建性也大有好处。整体上采用这些技术将改善项目的效率、优化团队个人的工作方式，同时这样做带来的项目的稳定性、流程的增加，也不会影响到瀑布模型的核心。