Maven 學習總結 （五） 之 持續集成、構建web應用

持續集成的做用、過程和優點

　　簡單說，持續集成就是快速且高頻率地自動構建項目的全部源碼，併爲項目成員提供豐富的反饋信息。

　　快速：集成的速度要儘量地快，開發人員不但願本身的代碼提交半天以後才獲得反饋。

　　高頻率：頻率越高越好，例如每隔一個小時就是不錯的選擇，這樣問題才能儘早地被反映出來。

　　自動：持續集成應該是自動觸發執行的，不該該手動參與。

　　構建：包含編譯、測試、審查、打包、部署等工做

　　全部源碼：全部團隊成員提交到代碼庫裏的最新的雲代碼。

　　反饋：持續集成應該經過各類快捷的方式告訴團隊成員最新的集成裝填，當集成失敗的時候，反饋報告應該儘量第反映失敗的具體細節。

 

　　一個典型的持續集成場景是這樣的：開發人員對代碼作了一些修改，在本地運行構建並確認無誤以後，就更改提交到代碼庫。具備高配置硬件的持續集成服務器每隔30min查詢代碼庫一次，發現更新以後，簽出全部最新的源代碼，而後調用自動化構建工具構建項目，該過程包括編譯、測試、審查、打包和部署等。而後步行的是，另一名開發人員在這一事件段也提交了代碼更改，兩處更改致使了某些測試的失敗，持續集成服務器基於這些失敗的測試建立一個報告，並自動發送給相關開發人員。開發人員收到報告以後，當即着手調查緣由，並儘快修復。

　　 

　　一次完整的集成每每會包括如下6個步驟：

　　1）、持續編譯：全部正式的源代碼都應該提交到源碼控制系統中，持續集成服務器按必定頻率檢查源代碼控制系統，若是有新的代碼，就觸發一次集成，

舊的已編譯的字節碼應當所有清除。

　　2）、持續數據庫集成：在不少項目中，源代碼不只僅指JAVA代碼，還包括數據庫SQL攪拌，若是單獨管理他們，很容易形成項目其餘代碼的不一致，形成混亂。

持續集成也應該包括數據庫集成，每次發現新的SQL腳本，就應該清理集成環境數據庫，從新建立表結構，並填入預備的數據，這樣就能隨時發現腳本的錯誤，

此外基於這些腳本的測試還能進一步發現其餘相關的問題。

　　3）、持續測試：有了JUnit之類的框架，自動化測試就成了可能，編寫優良的單元測試並不容易，好的單元測試必須是自動化的、可重複執行的、不依賴於環境的、

而且可以自我檢查的。除了單元測試，有些項目還會包含一些依賴外部環境的集成測試，全部這些測試都應該在每次集成的時候運行，而且在發現問題的時候產生具體報告。

　　4）、持續審查：注入Checkstyle和PMD之類的工具可以幫助咱們發現代碼中的壞的味道，持續集成能夠會用這些工具來生成各種報告，如測試覆蓋率報告、Checkstyle報告、

PMD報告等。這些報告的生成頻率能夠下降一些，如每日生成一次，當審查發現問題的時候，能夠給開發人員反饋警告信息。

 　　5）、持續部署：有些錯誤只有在部署以後才能發現，他們每每具體容器或者環境相關的，自動化部署可以幫助咱們儘快發現這類問題。

·　　6）、持續反饋、持續集成的最後一步的反饋，一般是一封電子郵件，在重要的時候將正確的信息發給正確的人。若是開發者一直收到與本身無關的持續集成報告，

他慢慢就會忽略這些報告，基本的規則是：講集成失敗報告發送給此次集成相關的代碼提交者，項目經歷應該收到全部失敗報告。

 

　　持續集成須要引入額外的硬件設置，特別是對持續集成服務器來講，性能越高，集成的速度就越快，反饋的速度就越快。持續集成還要求開發者使用各類工具，

如源碼控制工具、自動化構建工具、自動化測試工具、持續集成軟件等。這一切無疑都增長了開發人員的負擔，而後學習並適應這些工具及流程是徹底值得的，由於持續集成的好處不少：

　　儘早暴露問題、減小重複操做、簡化項目發佈、簡歷團隊信心。

構建Web應用

　　基於java的Web應用，其標準打包方式是WAR。WAR與JAR相似，只不過它能夠包含更多內容，如JSP文件、servlet、java類、web.xml配置文件、依賴jar包、靜態web資源等。

一個典型的WAR文件會有以下目錄結構：

　　                            

一個WAR包下至少包含兩個子目錄：META-INF和WEB-INF。前者包含了一些打包數據信息，後者是WAR包的核心，WEB-INF必須包含一個Web資源表述文件web.xml，它的子目錄

classes包含全部項目的類，而子目錄lib包含全部項目依賴JAR包，classea和lib目錄都會在運行時候被加入到Classpath中。除了MET-INF和WEB-INF外，通常的WAR都會包含不少Web

資源如，html或者js文件。

　　用戶必須爲Web項目顯示指定打包方式爲war。Maven對Web項目的佈局結構也有通用的約定。

　　                                  

　　在src/main/webapp/目錄下，必須包含一個子目錄WEB-INF,該子目錄還必須包含web.xml文件。其餘文件和目錄包括html、jsp、css、javascript等。

　使用jetty-maven-plugin，測試Web頁面的作法一般是將項目打包並部署到Web容器。Web頁面測試應該僅限於頁面的層次，例如JSP、CSS、JavaScript的修改，其餘代碼修改，

請編寫單元測試。

　　jetty-maven-plugin可以幫助咱們節省時間，它可以週期性地檢查項目內容，發現項目變動後自動更新到內置的Jetty Web容器中。它幫咱們省去了打包和部署的步驟。它默認

就很好地支持了Maven的項目目錄結構。

　　

在該插件配置中，scanIntervalSeconds表示該插件掃描項目變動的時間間隔。若是不進行配置，默認值是0，表示掃描，用戶就失去了所謂的自動化熱部署的功能。webappConfig

元素下的classPath表示項目部署後的context path。

　　默認狀況下，只用org.apache.maven.plugins和org.codehaus.mojo兩個groupId下的插件才支持簡化的命令行調用，便可以運行 mvn help: system，但maven jetty： run就不行

由於他的groupId是org.mortbay.jetty。爲了能在命令行運行mvn jetty: run，用戶須要配置settings.xml 以下：

　　　　

　　啓動命令：mvn jetty:run 默認監聽端口是8080.並將當前項目部署到容器中，同時還會根據用戶配置掃描代碼改動。

 mvn jetty:run -Djetty.port=9999　　修改端口參數

　　以上僅僅展現jetty-maven-plugin最核心的配置，若是有須要，還能夠自定義web.xml的位置、項目class文件的位置、web資源目錄的位置等。standalong模式的配置樣例

　　<plugin>

　　　　<groupId>org.codehaus.cargo</groupId>

　　　　<artifactId>cargo-maven2-plugin</artifactId>

　　　　<version>1.0</version>

　　　　<configuration>

　　　　　　<container>

　　　　　　　　<containerId>tomcat6x</containerId><!--表示容器類型-->

　　　　　　　　<home>D:\cmd\apache-tomcat-6.0.29</home><!--表示容器的安裝目錄-->

　　　　　　</container>

　　　　　　<configuration>

　　　　　　　　<type>standalong</type>  <!--表示部署模式-->

　　　　　　　　<home>${project.build.directory}/tomcat6x</home><!--表示複製容器的配置到什麼位置，這裏表示構建輸出目錄，即target/下的tomcat6x子目錄-->

　　　　　　</configuration>

　　　　</configuration>

　　</plugin>

　

cargo-maven2-plugin的groupId是org.codehaus.cargo，這不屬於官方兩個maven插件groupId，所以須要用戶將其添加到settings.xml的pluginGroup元素中以方便命令行調用。

配置好以後，讓Cargo啓動Tomcat並部署應用，只須要運行：$ mvn cargo:start  

 

使用Cargo實現自動化部署

 　　部署至本地容器，Cargo是一組幫助用戶操做web容器的工具，它可以幫助用戶實現自動化部署，並且幾乎支持全部的web容器，如tomcat、jBoss等。Cargo經過cargo-maven2-plugin提供了maven集成

Maven用戶可使用該插件將Web項目部署到Web容器中。雖然cargo-maven2-plugin和jetty-maven-plugin的功能看起來很類似，可是他們目的是不一樣的，jetty-maven-plugin主要用來

幫助平常的快速開發和測試，而cargo-maven2-plugin主要服務於自動化部署。

　　Cargo支持兩種本地部署方式，分別爲standalone模式和existing模式。在standlong模式中，Cargo會從Web容器的安裝目錄複製一份配置到用戶指定的目錄，而後再此基礎上部署應用，

每次從新構建的時候這個目錄都會被清空，全部配置被從新生成。而在existing模式中，用戶須要指定現有的Web容器配置目錄，而後Cargo會直接使用這些配置並將應用部署到其對應的位置。

　　

　　部署至遠程容器，可讓cargo部署應用至遠程的正在運行的Web容器中。

　　<plugin>

　　　　<groupId>org.codehaus.cargo</groupId>

　　　　<artifactId>cargo-maven2-plugin</artifactId>

　　　　<version>1.0</version>

　　　　<configuration>

　　　　　　<container>

　　　　　　　　<containerId>tomcat6x</containerId>

　　　　　　　　<type>romote</type> <!--必須爲romote,若是不顯示指定，Cargo使用默認值installed，並尋找對應的容器安裝目錄或者安裝包-->

　　　　　　</container>

　　　　　　<configuration>

　　　　　　　　<type>runtime</type><!--表示既不使用獨立容器配置，也不實用本地現有的配置，而是依賴於一個已運行的容器-->

　　　　　　　　<properties>

　　　　　　　　　　　<cargo.remote.username>test</cargo.remote.username>

　　　　　　　　　　　<cargo.remote.password>test</cargo.remote.password>

　　　　　　　　　　　<cargo.remote.manager.url>http://localhost:8080</cargo.remote.manager.url>

　　　　　　　　 </properties>

　　　　　　</configuration>

　　　　</configuration>

　　</plugin>

　　　　　　

　　配置完成以後運行命令，$mvn cargo:deploy 若是容器已經部署了當前應用，Cargo就先將其卸載，而後再從新部署。