敏捷需求分析，敏捷專案管理，敏捷軟體開發已經被大家炒的很熱了。在當今商業專案複雜多變的情況之下似乎「敏捷」都已經成為了不二之選了。的確，無論從理論還是在無數的案例證明，對於當今的這種商業環境下的軟體專案，大部分都是適合的。
就像一門優秀語言的出現會影響乙個軟體開發人員職業生涯的5年，10年，甚至更長時間一樣。一門優秀的軟體專案管理思想和最佳實踐的的出現和普及對軟體從業人員的影響都將是更深遠的。
敏捷軟體開發可能是其中討論的尤為激烈的。這與涉及的群體較大有關。
敏捷軟體開發中我們一般除了要求參與的個體需要具有足夠的「敏捷」性以外，還需要借助於一些工具提公升組織的敏捷性。這裡我們來談談敏捷開發中常常提到的持續整合的概念。
在沒有應用持續整合之前，傳統的開發模式是專案一開始就劃分模組，然後等所有的**都開發完成之後再整合到一起進行測試，隨著軟體技術的發展，各種軟體方法百花齊放，軟體規模也在擴大，軟體需求越來越複雜，軟體已經不能簡單地通過劃分模組的方式來開發，需要專案內部互相合作，劃 分模組這種傳統的模式的弊端也越來越明顯，由於很多 bug 在專案
的早期就存在，到最後整合的時候才發現問題，開發者需要在整合階段花費大量的時間來尋找 bug 的根源，加上軟體的複雜性，問題的根源很難定位，甚至出現不得不調整底層架構的情況，在這個階段的除蟲會議（bug meetings）特別多，會議的內容基本上都是討論 bug 是怎麼產生的，最後往往發展成為不同模組的負責人互相推諉責任。持續整合最大的優點是可以避免這種傳統模式在整合階段的除蟲會議。持 續集成主張專案的開發人員頻繁的將他們對原始碼的修改提交(check in)到乙個單一的原始碼庫，並 驗證這些改變是否對專案帶來了破壞，
持續整合包括以下幾大要點：
1， 訪問單一原始碼庫，將所有的源**儲存在單一的地點（原始碼控制系統）， 讓所有人都能從這裡獲取最新的源** （以及以前的版本）。
2 支援自動化建立指令碼，使 建立過程完全自動化，讓任何人都可以只輸入一條命令就完成
系統的建立。
3 測試完全自動化，要求開發人員提供自測試的**，讓 任何人都可以只輸入一條命令就
執行一套完整的系統測試。
4 提供主建立，讓任何人都可以只輸入一條命令就可以開始主建立。
5 提倡開發人員頻繁的提交（check in）修改過的**。
持續整合的關鍵是完全的自動化，讀取源**、編譯、連線、測試，整個建立過程都應該自動完成。對於一次成功的建立，要求在這個自動化過程中的每一步都不能出錯，而最重要的一步是測試，只有最後通過測試的建立才是成功的建立。
在持續整合裡面建立不再只是傳統的編譯和連線那麼簡單，建立還應該包括自測試，自測試的**是開發人員提交原始碼的時候同時提交的，是針對原始碼的單元測試（源自 xp 的實踐），將所有的這些自測試**整合到一起形成測試集，在 所有的最新的原始碼通過編譯和連線之後還必須通過這個測試集的測試才算是成功的建立。這 種測試的主要目的是為了驗證建立的正
確性，m cconnell 稱之為「冒煙測試」，在 持續整合裡面，這 叫做整合驗收測試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，從根本上消除傳統模
式的弊端，這就已經值回它的開銷了。
敏捷開發 如何持續整合
持續整合是十二種極端程式設計 xp 實踐之一 n0.6 持續整合背後的基本思想是始終保持每個人的 整合，並與應用程式的其餘部分一起構建發布基礎結構。無論採用何種方法，這都是一種很好的做法，在scrum等敏捷方法中尤為重要，因為隨著 的開發，我們需要快速反饋新開發是否會影響應用程式的任何其他領域。為確...
CI CD持續整合 持續部署 敏捷開發
持續整合 continuous integration 是一種軟體開發實踐，即團隊開發成員經常整合它們的工作，通過每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建 包括編譯，發布，自動化測試 來驗證，從而盡早地發現整合錯誤。持續部署 continuous dep...
保持敏捷 持續整合
敏捷的乙個要點就是 快速反饋。從最早的每日構建，到現在的持續整合，都是開發者為了迅速獲得系統反饋而採取的一系列措施。而且反饋資訊越來越快速，資訊要求越來越高。一次整合的過程步驟大概如下 自動更新 編譯構建 自動測試 報告整合結果。需要使用者寫好各過程命令 比如更新版本 並在整合伺服器的支援下，把各過...