敏捷式軟體開發 (Agile Software Development)之持續整合

      敏捷需求分析，敏捷專案管理，敏捷式軟體開發 (Agile Software Development)已經被大家炒的很熱了。在當今商業項目複雜多變的情況之下似乎“敏捷”都已經成為了不二之選了。的確，無論從理論還是在無數的案例證明，對於當今的這種商業環境下的軟體項目，大部分都是適合的。

     就像一門優秀語言的出現會影響一個軟體開發人員職業生涯的5年，10年，甚至更長時間一樣。一門優秀的軟體專案管理思想和最佳實務的的出現和普及對軟體從業人員的影響都將是更深遠的。

     敏捷式軟體開發 (Agile Software Development)可能是其中討論的尤為激烈的。這與涉及的群體較大有關。

     敏捷式軟體開發 (Agile Software Development)中我們一般除了要求參與的個體需要具有足夠的“敏捷”性以外，還需要藉助於一些工具提升組織的敏捷性。這裡我們來談談敏捷開發中常常提到的持續整合的概念。

    在沒有應用持續整合之前，傳統的開發模式是項目一開始就劃分模組，然後等所有的代碼都開發完成之後再整合到一起進行測試，隨著軟體技術的發展，各種軟體方法百花齊放，軟體規模也在擴大，軟體需求越來越複雜，軟體已經不能簡單地通過劃分模組的方式來開發，需要項目內部互相合作，劃 分模組這種傳統的模式的弊端也越來越明顯，由於很多 bug 在項目
的早期就存在，到最後整合的時候才發現問題，開發人員需要在整合階段花費大量的時間來尋找 bug 的根源，加上軟體的複雜性，問題的根源很難定位，甚至出現不得不調整底層架構的情況，在這個階段的除蟲會議（bug meetings）特別多，會議的內容基本上都是討論 bug 是怎麼產生的，最後往往發展成為不同模組的負責人互相推諉責任。持續整合最大的優點是可以避免這種傳統模式在整合階段的除蟲會議。持 續整合主張項目的開發人員頻繁的將他們對源碼的修改提交(check in)到一個單一的源碼庫，並 驗證這些改變是否對項目帶來了破壞，

     持續整合包括以下幾大要點：
     1， 訪問單一源碼庫，將所有的原始碼儲存在單一的地點（源碼控制系統）， 讓所有人都能從這裡擷取最新的原始碼    （以及以前的版本）。
     2 支援自動化建立指令碼，使 建立過程完全自動化，讓任何人都可以只輸入一條命令就完成
系統的建立。
     3 測試完全自動化，要求開發人員提供自測試的代碼，讓 任何人都可以只輸入一條命令就
運行一套完整的系統測試。
     4 提供主建立，讓任何人都可以只輸入一條命令就可以開始主建立。
     5 提倡開發人員頻繁的提交（check in）修改過的代碼。
      持續整合的關鍵是完全的自動化，讀取原始碼、編譯、串連、測試，整個建立過程都應該自動完成。對於一次成功的建立，要求在這個自動化過程中的每一步都不能出錯，而最重要的一步是測試，只有最後通過測試的建立才是成功的建立。
在持續整合裡面建立不再只是傳統的編譯和串連那麼簡單，建立還應該包括自測試，自測試的代碼是開發人員提交源碼的時候同時提交的，是針對源碼的單元測試（源自 XP 的實踐），將所有的這些自測試代碼整合到一起形成測試集，在 所有的最新的源碼通過編譯和串連之後還必須通過這個測試集的測試才算是成功的建立。這 種測試的主要目的是為了驗證建立的正
確性，M cConnell 稱之為“煙霧測試 (Smoke Test)”，在 持續整合裡面，這 叫做整合驗收測試Build Verify Test，簡稱 BVT。BVT 測試是品質的基礎，QA 小組不會感受到 BVT 的存在，他們只針對成功的
建立進行測試（如功能測試）。
BVT 測試應該盡量的詳盡，詳盡的測試才能發現更多的問題，而由此得到的反饋結果也更有參考意義，測試應該全部執行完畢，這樣得到的反饋結果才是完整的，而不是遇到錯誤就
放棄測試過程。
持續整合和日建立相比還有以下特點：
    1 持續整合強調了整合頻率，和日建立相比，持續整合顯得更加頻繁，目前推薦的最佳實務是每一個小時就整合一次。
    2 持續整合強調及時反饋，日建立的目的是得到一個可以使用的穩定的發布版本，而持續整合強調的是整合失敗之後向開發人員提供快速的反饋，當 然成功建立的結果也是得到穩定的版本。
    3 日建立並沒有強調開發人員提交（check in）源碼的頻率，而持續整合鼓勵並支援開發人員儘快的提交對源碼的修改並得到儘快的反饋。
從上面列出的續整合和日建立相比的特點來看，很明顯，“ 頻率”和“反饋”這兩個詞出現的特別多，持 續整合有一個與直覺相悖的基本要點，那 就是“ 經常性的整合比偶爾整合要好”。Martin Fowler 認為對於持續整合來說，整合越頻繁，效果越好 ，如果你的整合不是經常進行的（少於每天一次），那麼整合就是一件痛苦的事情，如果整合偶爾才進行一次（一周甚至一個月）， 等到整合階段發現bug，然後找原因解決bug，會耗費你大量的時間與精力，而且這種方式有點象傳統的整合模式，這違背了持續整合的初衷。根據 Martin Fowler 的觀點，項目 bug 的增加和時間並不是線性增長的關係，而是和時間的平方成正比，兩次整合間隔的時間越長，bug 增加的數量越超過你的預期，解決 bug 付出的工作量也越大，而你越覺得付出的工作量越大，你就越想延遲到以後去整合，企圖到最後一次性解決問題，結果 bug 產生的就更多，導致下一次整合的工作量更大，你越感覺到整合的痛苦，就越將整合的時間推後，最後形成惡性迴圈。因此如果整合的結果是讓你感到痛苦，也許就說明你應該更頻繁地進行整合。頻繁的整合和及時的反饋鞭策著項目小組積極的面對問題，而 不是將問題推到最後來解決，如 果方法正確，更頻繁的整合應該能減少你的痛苦，讓你節約大量時間。因為持續整合最終是通過測試來驗證建立，所以你會發現對於持續整合的頻率的要求跟Kent Beck 提出的測試驅動的開發方法裡面測試第一的理念完全一致。
需要注意的是從項目的一開始就引入持續整合可以儘早的發現 bug，但是並不代表持續整合可以幫你你抓到所有的 bug。持續整合的排錯能力取決於測試技術，眾所周知，無法證明已經經過測試的代碼就已經找到了所有的錯誤。
前面列舉了持續整合這麼多優點，但是建立一個持續整合的環境技術上是比較複雜的，也需
要一定的時間，關鍵是在於持續整合可以“及時”抓到足夠多的 bug，從根本上消除傳統模
式的弊端，這就已經值回它的開銷了。