以下內容轉載自 http://blog.csdn.net/yazhouren/article/details/7356746
現在研究CI(持續集成）鏈，公司要使用jenkins,剛開始接觸很多不懂，現在經過一個多月的查找資料，終於明白了一些
現在網上的資料特別的混亂，有的特別的基礎，學了還是什麼都沒搞明白；有的是很深，一點基礎都不講，怎麼也看不明白，中間層很欠缺。也許使用這些技術的公司，對於員工都進行了很好的培訓，基礎的東西一聽都明白了，但是對於自學使用這些工具的人來說，如果不能提綱挈領，抓住要領，學起來真費勁。下面，我就給根據我的理解，來說一說，希望對看到這篇文章的人有幫助，錯誤之處，敬請指正。
1. Make工具
這個工具是最最原始的工具了，在linux下編過程序，看過比較大的c/c++代碼的人應該都聽說過這個工具（Windows下對應的工具爲nmake)。它負責組織構建的過程，也就是負責指揮編譯器如何編譯，連接器如何連接，最後生成一個可用的文件。
2. Ant工具
但是有人覺得make工具的很難使用，他的語法很難理解，就發明了ant
3. Maven工具
Maven工具是對ant工具的進一步改進（這麼說不太準確，但是可以這麼理解)。
在make工具中，如果我們要編譯某些源文件，我們肯定首先要安裝編譯器等工具。但是有時候需要不同版本的編譯器，在java的編譯器需要不同的各種包的支持，如果把每個包都下載下來，在makefile中進行配置制定，當需要的包非常多時，很難管理。
- 例如一個web項目，可能使用到很多技術，面向對象、泛型、or-mapping、依賴注入（spring-framework）、全文檢索（lucene）、數據庫、集羣、工作流、web service等等。
- 由於使用了多種技術，這些技術可能是JDK提供的，也可能是第三方開源組織提供的，或者不同的商業公司提供的。
- 於是出現了一個新的難題，就是包依賴複雜性。以前，你很難想象你的代碼依賴數十個不同開源組織、商業公司提供的庫。例如，我們經常使用的log4j、junit、easymock、ibatis、springframework，每個組件都有悠久的歷史，存在不同的版本，他們之間版本還有依賴關係。
- 項目依賴的複雜性，經常的，一個較大部門有10-30個項目是常事，項目之間有不同版本的依賴關係，部門與部門之間的項目也存在複雜的版本依賴關係。
- Eclipse本身提供Project的依賴，但是簡單的依賴顯然解決不了問題。例如Project B依賴Project A，Project A依賴第三方的jar包abc-1.0.jar，那麼需要在兩個項目的lib下都存放abc-1.0.jar，這產生冗餘，當Project數量多起來，這個冗餘就產生了管理問題，如果需要將abc-1.0.jar升級爲abc-1.1.jar，則需要在兩個Project中同時修改，如果Project數量達到10個以上，而且是不同項目組維護的項目，這個就是非常麻煩的事情。而且Project A修改依賴，爲啥需要Project B也作相應的修改呢？
- 需要解決此問題，就需要在Project A的包中描述其依賴庫的信息，例如在META-INFO記錄所以來的abc-1.0.jar等。Eclipse的plug-in擁有類似的方案，但是這樣一來，就使得開發Project B的項目組，需要把Project A的代碼從源代碼庫中check out出來。在依賴鏈末端的項目組是很慘的。
- 由於Project數量衆多，關係複雜，dailybuild的ant腳本編寫成了很麻煩的事情，使用Project依賴的方式，更加使得編寫dailybuild ant script是非常痛苦的事情。
- 參考:http://www.cnblogs.com/jobs/archive/2007/09/24/903731.html
這樣，於是人們發明了Maven工具。Maven使用配置文件pom.xml對環境進行配置，例如設定編譯器的版本，設定所需支持包的URL,這樣maven就可以自動去下載所需的包。這樣如果需要對構建環境進行改變時，直接改變pom文件就可以了，maven會自動網絡上下載配置的包。
Maven像make一樣，是個構建(build)工具，它如何調用各種不同的編譯器連接器等呢？ 這就是Maven plugin (maven 插件）。maven插件是爲了使maven能夠實用各種工具。不同的工具有對應的插件。
Maven比make的更加大的地方是，可以利用一些別的工具，實現對編譯結果的統計，對源代碼的檢查，對於代碼的測試等。例如checkstyle,cobertura等，都有對應的Maven插件。
4. Jenkins工具
Maven已經很強大了，那Jenkins是個什麼東西？
其實Maven還是不夠強大。Maven可以控制編譯，控制連接，可以生成各種報告，可以進行代碼測試。
可是如何控制這個流程呢？ 編譯還是先連接？先進行代碼測試，還是先生成報告？？
可以使用腳本來對maven進行控制，實現這些流程的控制。但是，很不方便。即使能夠走完整個流程，但是查看結果（例如代碼靜態分析的結果）時，也不方便。設想我們查看了代碼覆蓋率的結果，又想查看代碼style的結果，又要對這些結果進行評價，還要發送給開發人員........太羅嗦了，有沒有自動化圖形界面實現這些過程的工具？？？？
有，這個工具就是Jenkins。
Jenkins能夠對流程進行控制，對能夠對各個階段生成的各種結果進行綜合，以圖表的形式呈現出來。
但是，不同的工具生成不同格式的結果，Jenkins如何讓這些結果呈現出來？？
這就是jenkins插件，Jenkins插件使maven中用到的各種工具生成的結果能夠在Jenkins中呈現出來。
5. 一些特殊的東東
有些工具，不能被maven使用，卻可以通過Jenkins調用腳本來生成結果，並有對應的Jenkins插件，將結果Jenkins中顯示出來，例如cppcheck,CCCC等工具
6. Jenkins項目中對於項目配置中工具的配置與workspace中pom文件的該工具的配置的關係
例如，使用該cobertura工具，需要在jenkins中安裝對應的插件，在項目設置中，制定cobertura-result所在的目錄
但是使用cobertura工具的哪個版本？obertura如何找到需要檢查的源文件？cobertura工具會把檢查的結果放到哪個目錄？
這些設置需要使用pom文件來配置的。
7. pom.xml與makefile
maven中使用的pom與make中使用的makefile作用差不多
但是在maven中，如果想編譯某個文件夾下所有文件（包含子文件夾的文件）該怎麼辦呢？
我現在的方法是使用aggregation 和 inheritance ,詳見pom reference(http://maven.apache.org/guides/introduction/introduction-to-the-pom.html )
Inheritance:
If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.
Aggregation:
And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.
8. 總結：怎麼樣，看了這篇文章是不是思路逐漸的清晰起來了！！！
我講的可能不是很嚴謹，但大體是這麼個意思。
再說，明白這些也沒有多大的意義，我們的終極目的是使用這些工具，來對代碼進行分析，提高代碼的質量。
如果您通過讀這篇文章，明白了這些工具大體的框架，那麼剩下的就是仔細研究各個分析工具的具體使用，希望能夠通過使用分析工具提高大家的代碼質量。
忙了一個月，看了好多的英文html,才學到這點知識，希望能給後來人一點點幫助!
