持续集成学习笔记－入门篇（4）持续集成自动化（一）：所谓“关键”问题
搭建好持续集成环境后，接着就该学习各个工具的具体用法了。因为网上这些工具的入门级教程实在太多，笔者推荐几个自己学习时用的主要参考吧，省得板门弄斧了。其实，笔者感觉，分别学习这些工具的用法虽然比较难，但好歹有路可依。最令人头疼、感觉麻烦的是如何将它们整合起来、相互配合一起使用：不仅要知其然，而且还要知其所以然啊。
1、SVN
l 官方在线文档（英文）：http://svnbook.red-bean.com/nightly/en/index.html
l 官方在线文档（中文）：http://svnbook.red-bean.com/nightly/zh/index.html
2、Maven
l 官方在线文档（英文）：：http://maven.apache.org/users/index.html
l 中文指南下载：http://download.csdn.net/detail/fugary/844511
3、Jenkins
l 官方在线文档（英文）：：https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins
l 中文入门在线教程：
http://www.ibm.com/developerworks/cn/java/j-lo-jenkins/?cmp=dwskl&cpb=dw&ct=dwcon&cr=cn_CCID&ccy=cn#major3
一、持续集成该自动化了
1、、持续集成需要自动化吗？
答：废话。不然每个步骤都手工操作，跟以前作坊式的开发有啥本质区别。
2、实现持续集成自动化的思路是什么？
答：把开发、源代码仓库、构建无缝整合起来，能实现自动化的步骤都给实现自动化，程序员只要更新、提交代码就好了。---当然，这也是废话
3、利用Elicpse、SVN、Maven、Jenkins这些工具，如何具体地实现自动化的持续集成呢？
答：这个，这个。。。。。。
二、实现持续集成自动化的所谓“关键”问题
首先澄清一下，如果笔者一开始学习的是Ant而不是Maven，可能就不存在所谓“关键”问题了。之所以存在，是因为笔者一开始就没有真正弄明白Maven“约定优于配置”中的“约定”究竟是怎么回事。而很不幸的是，由于笔者的愚笨，一个多月的学习时间中，有近一周的时间都是为了搞清楚这个“关键”而浪费掉了。
那么，所谓的“关键”问题究竟是什么呢？
笔者一开始用Maven建立项目工程，因为目录结构是符合Maven自己的默认规定的（实质上，默认的目录结构就是所谓的“约定”之一），所以相应的POM配置文件不用显性地考虑从哪里找源代码，把输出文件放置到哪里等问题。结合一下Jenkins就可以实现自动的项目构建工作了（不包括从SVN提取源代码的过程，仅仅是构建工作）。可是笔者嫌Maven自己生成的Webapp项目工程的目录结构不好看，就用Elicpse建立了一个Tomcat工程，然后打算进行自动构建。
然后笔者突然就木了----因为不知道如何针对这个Tomcat工程生成POM文件----因为Maven没有专门针对Elicpse的Tomcat工程的默认目录结构（Maven有自己默认的Tomcat工程目录结构，但与Elicpse的Tomcat工程目录结构相差甚大）。开发工具和构建工具针对同一类型项目自动生成的工程目录结构完全不同，而Maven不认识Elicpse的！！连pom配置文件都没有，何来持续集成的自动化呢？对别人来说，这也许是个小问题，但笔者确实是为此曾经极其困惑。
如何统一项目的目录结构，让不同工具都能认得，就是所谓的持续集成自动化“关键”问题。无缝整合，其实质就是让开发工具和构建工具都能认识项目，而这也是持续集成自动化得以实现的前提之一。
对于了解Maven的人来说，可能会对笔者鄙视一番：自己在POM中规定各种SourceDirectory和OutDirectory不就好了。可问题是：笔者当时根本不知道还可以自己设置这些目录呢！笔者只是在遇到上述问题后，才开始琢磨并寻找与Maven默认的目录架构及设置相关的材料，最后才搞明白。
笔者在网上看过好些个Maven的入门教程（甚至包括官方的），没有教程一开始就介绍Maven默认的目录结构（Directory Layout）究竟是怎么一回事，也没人说明如何设置SourceDirectory和OutDirectory，只是告诉我们Maven采用“约定优于配置”的原则，让我们遵循Maven默认的目录结构就好了。在Maven默认生成的POM.xml文件中，你是找不到跟目录结构相关的内容的。要想继续下去，就得搞明白Maven那些默认的规则。（一般的Maven教程，总是将大篇幅的内容放在依赖、多级POM上了。虽然这些非常重要，但是对于初学者来说，讲清楚“约定”究竟是什么可能更重要。而这个对于初学者来说恰恰是难点）
反之，Ant则要求在配置文件中，明确的告诉构建工具去哪里找源代码和工具，哪里放置输出。比如下面的build.xml中就有一段：
haltonfailure="false"
failureproperty="tests.failed"
showoutput="true">
***********************************************************
**** One or more tests failed! Check the output ... ****
***********************************************************
虽然写起来比较麻烦，但实际上，Ant的这种写法才是比较符合一般初学者的思维习惯的：毕竟，你要做一件家具，得先知道去哪儿拿到木材吧。而Maven，则需要适应一下了。我想，“目录结构”的“约定”规则，也是造成很多Ant使用者刚开始转向Maven后不太适应的原因之一吧。
三、持续集成自动化：解决思路
搞明白产生所谓“关键”问题的原因后，要想实现持续集成自动化，就有两种基本思路了：
1、以Maven为主，将其生成的默认Directory Layout作为项目的目录结构，让其他工具围着这个项目目录结构转。这种思路适合比较简单的项目，毕竟更省事。
2、以开发工具为主，以其生成的项目的目录结构（或者开发者自己规定的目录结构）为核心，调整Maven的POM配置文件（具体的操作就不说了，后续的学习笔记会提到，或者直接看Maven的教程），并让其他工具围着这个项目目录结构转。这种思路更适合比较复杂的项目，毕竟Maven默认的项目目录结构不可能应对所有需求。
通过对比，我们也可以发现，两者之间的区别其实就是在于如何建立项目的目录结构，而其他方面的持续集成工作内容则是一模一样的（具体可以见后5、6两篇学习笔记）。
附：Maven默认的目录结构
前面说了半天目录结构是无缝整合的关键问题，那这个目录结构究竟是怎么一回事呢？我们先看一下Maven默认的目录结构吧（具体的生成操作步骤就不说了，后续的学习笔记会提到，这里就专注于目录结构的说明。关于Maven默认的目录结构，详细说明请见：http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html ）
一个简单的默认目录结构如下：
my-app
|-- --pom.xml
|-- --src
|-- --- main
| |-- java
|---- test
|--java
其中，src/main/java是java主程序源代码所在目录，src/test/java是测试用例源代码所在目录，相关的构建步骤包括：
l 从src/main/java提取主程序源代码，经过编译，将生成后的class文件放置到target/classes目录下
l 从src/test/java提取测试用例源代码，经过编译，将生成后的class文件放置到target/test-classes目录下，并针对主程序的java类进行测试
构建完成后，形成的目录结构为：
my-app
|-- --pom.xml
|-- --src
|-- --main
| |-- java
| `-- test
| |-- java
|`-- target
|-- classes
`-- test-classes
可见，如果不知道Maven的默认规则而随意放置源代码（不在默认的目录下），而且如果还不在pom.xml中明确地指出源代码所在目录的话，Maven将无法进行构建工作。
象本文前面所述，Elicpse生成的Tomcat工程目录结构就不符合Maven的默认目录结构规则，于是构建没法进行下去。要么pom.xml变，要么按照Maven的默认规则走。其实，把这关想通了，其他的持续集成步骤就都可以按照教程说明一步步进行了。于是乎，就可以称之为“简单的”持续集成工作了。