敏捷開發 -- 持續集成

        軟件集成並非一個新的問題或者概念，當一我的獨立開發一個產品的時候，好比作畢業設計的時候，根本就不存在軟件集成，更不用去考慮持續集成！可到了三五我的、七八條槍，進行團隊開發的時候，這個問題就不得不去考慮了！特別是在傳統的瀑布式開發中，模塊開發是獨立進行，當各個模塊都完整開發完了以後，再進行模塊間的整合，不少噩夢都發生在這個時候：接口不統一，模塊間對需求的理解不一致 …… 每每要磨上十天半個月才能搞定！
       Martin Fowler （ ThoughtWorks 公司的那個「大鬍子」）對持續集成的註解以下：
      Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
    我以爲能夠這樣簡單理解：及早地將開發人員的代碼集成起來，經過各類工具來及時地發現代碼中存在的問題，以確保代碼質量的穩定性和準確性，讓 Agile 第二宣言 Working Software 得以實現！
  下面咱們按照 Martin Fowler 的思路來介紹持續集成：
     1）Maintain a Single Source Repository
　　通常來講，工程都是以團隊的形式進行開發的。一個工程的文件都是以千百計算的，若是須要手工去跟蹤、同步這些文件，那無疑是天方夜譚。因而源代碼管理工具應運而生。開源的源代碼管理工具備 CSV ， Subversion 等，我的感受 Subversion 比較好用，另外由 IBM Rational 出品的 Clearcase 功能更是強大，不過不是很便宜。咱們能夠在這些源代碼管理工具上面建立一個工程的 Stream ，而後你們即可以在這個 Stream 上面創建本身的 Child Stream, 在代碼進行改動以後，咱們就將這些代碼 Deliver 到代碼庫，代碼的管理工具會爲咱們作代碼的同步工做。這樣你們就能夠基於最新的代碼進行開發。
　　2)Automate the Build 　　
　　從拿到源代碼到變成一個可運行的系統，這中間要通過一個複雜的過程。一個簡單的過程大概有：編譯 / 打包源代碼，將打包好的包拷貝到服務器下面，而後啓動或者重啓服務器，這是簡單到有點「 HelloWorld 」的感受。即便在這麼簡單的過程當中，還得開啓 IDE 才能讓編譯源代碼方便些，可在集成的服務器中，通常是不會使用 IDE 的。開發人員「懶惰」的特性迫使他們開發新工具來完成這一煩人的過程。 Java 社區開發出 Ant ， .NET 社區開發出 Nant ，如今還有 MSBuild 。經過這些工具，咱們能夠將這些複雜、重複、單調、無聊的工做經過一些配置交由工具去完成。因爲 Ant 的功能確實很強大，之後再找時間補充 Ant 的使用。
　　3)Make Your Build Self-Testing 　　
　　在傳統的開發模式中，當 build 一個版本出來以後，咱們每每須要叫上全部的人（由於是分模塊開發），花上幾個鐘頭，在系統上進行人工測試。而鬱悶的是：即便進行了人工測試，表面上看似沒有問題了，可保證不了後臺邏輯的正確性。咱們不是有 Automake the Build 嗎，那咱們就能夠往裏面加進一些自動化測試的任務。這些自動化測試在 build 的過程當中，檢測代碼的邏輯的正確性、分析代碼的複雜度、指出代碼潛在的危險性，測試系統功能的完整性和準確性，測試系統的行爲等等。固然，不是說咱們往 Ant 腳本里面加進幾條命令就能夠完成這些功能，而是須要咱們在寫功能代碼的同時或者以前，編寫相應的測試代碼，這就是前面說的 Test Driven Development （ TDD ，測試驅動開發） , 先寫測試，再寫實現！通常來講，測試包括了後臺邏輯測試 ( 通常用 NUnit), 測試前臺腳本邏輯（ Javascript 的腳本通常用 JsUnit ），測試頁面功能行爲正確性（通常用 Selenium ），分析代碼的複雜度（能夠用 PMD ），分析代碼潛在的危險性（用 FindBugs ）。
　　4)Everyone Commits Every Day 　　
　　集成不少時候是爲了溝通，告訴其餘開發人員本身已經作了那些代碼的改動。及時的溝通在團隊開發中的重要性是無可置疑的。因此咱們要儘快地將本身代碼的改動提交。但代碼提交以前，必定要確保本身代碼的正確性，至少讓系統能夠跑起來。而不是說代碼一有改動，就無論三七二十一，把代碼弄上去就好了，這樣對整個團隊來講， cost 會更大！因此是否每一天都要提交代碼呢，我以爲要具體問題具體分析！
　　5)Every Commit Should Build the Mainline on an Integration Machine 　　
　　前面說到天天都提交代碼，這就會帶來一個問題：在提交代碼以前，未必有去拿到最新代碼，即便拿到最新代碼，因爲開發環境的不一樣，也可能沒發現什麼問題。因而代碼上去了，另外一位同事去拿最新代碼，有可能整個系統都跑不起來。因此，咱們還須要一個集成的機器，它負責在每次代碼提交以後，去獲取最新的代碼，而後根據設置去運行相應的測試，看看此次提交的代碼有沒有什麼問題。這樣，即可以在下一個同事拿到新代碼以前發現問題，並相應的 owner 去處理，減小更多額外的工做。 CruiseControl （由 Thoughworks 公司開發的，並貢獻給開源社區）這個工具即可以作到這一點：它可以監聽代碼庫有沒有代碼變動，若是有的話，即可以拿到最新代碼，而後去運行相應的測試任務。關於 CruiseControl 的使用，能夠看看官網上面的說明，後面可能會獨立介紹一下。
　　6)Keep the Build Fast 　　
　　前面咱們說了，持續集成就是爲了更快、及早地發現問題。因此若是一次集成須要耗費幾個小時，甚至一天（據說 Microsoft 一個 build 就要一天，仍是分佈式的），那就失去了持續集成的意義了。因此要讓每次提交代碼觸發的集成動做越快越好， XP （極限編程）的大綱說每次 build 在 10 分鐘之內是最理想的。但其實不少時候很難作到的，一個 UAT 都每每要佔據幾分鐘的時間，重啓服務器的時間也是不可或缺的，因此我以爲這個快得根據不一樣的項目而論。
　　7)Test in a Clone of the Production environment 　　
　　測試就是爲了檢查產品的使用狀況，因此集成機器的環境搭建最好是跟最終產品的環境一致，好比說：相同的數據庫，相同的服務器，相同的操做系統等等。
　　8)Everyone can see what’s happening 　　
　　持續集成就是一種溝通，那咱們應該讓全部的人實時地、方便地看到持續集成的狀況。一種比較簡便的辦法是安裝一個 JCCTray( http://jcctray.sourceforge.net/ ) , 配置響應的參數，啓動它以後，能夠在桌面的右下方看到一個圓球的圖標，當圖標是綠色的，說明最近一次的持續集成是成功的，當圖標是紅色的，說明最近一次的集成是失敗的，而當它是×××的時候，說明持續集成正在進行中。下面的圖標顯示最近一次的集成是有問題的：

還有一種就是用一盞燈來顯示，紅綠黃的意思跟上面同樣，具體能夠看 http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc
　　9)Automate Deployment 　　
　　當拿到新代碼，通過測試，發現沒有問題，這時應該進行自動部署。好比自動部署到 QA 環境等，不少服務器的自動部署均可以用 Ant 任務來完成的，因此具體的服務器得去查看相應的 Ant 任務。

    前面按照 Martin Fowler 的思路，介紹了持續集成的整個過程。我的以爲持續集成不只僅在 Agile 是必須的，在傳統的開發模式中，有了持續集成，也是對整個開發有不少的幫助，特別是提升代碼的穩定性和正確性。     後面應該會陸續就本身在使用持續集成的一些工具過程當中的一些想法記錄下來。