敏捷開發中的持續集成應該如何做？

　　在過去十年或更長的時間中，軟件開發團隊一直受益于敏捷開發方法。他們采用這些迭代和增量開發實踐，通過協作式開發推動解決方案的發展。傳統的、非敏捷的軟件創建方法通常依賴于一個更嚴格管制的開發流。瀑布流程就是這方面的一個示例，其中需求、設計、開發和測試的每個活動都是連續執行的。

　　雖然瀑布式開發多年來一直是大型的復雜系統開發的標準，但它有幾個明顯的缺陷。首先，即使需求會隨時間而變化是眾所周知的，但開發人員仍會努力在設計前完成文檔，在編寫代碼前完成設計，其中有大量工作被浪費。另一個缺陷是，將測試和集成一直延遲到項目結束時才執行，問題往往發現得太晚，如果要解決問題，則有可能導致錯過最后期限。這兩個因素結合起來，在以較慢速度發展的世界中，也許可以容忍。但是，隨著創建創新系統的壓力的增加，這種方法的滿足組織需求的能力在下降。

　　雖然敏捷實踐是由開發 IT 系統的團隊推廣的，但它們同樣適用于產品開發，其中的產品包括硬件、電子和軟件。嵌入式軟件開發與 IT 應用程序開發的主要區別在于部署目標資源(如處理器性能和內存)的有限可用性。嵌入式軟件往往要在這些約束條件中執行復雜的實時操作。想像一下計算機控制的系統，例如汽車里的安全氣囊。您需要他們立即部署，但需要的是可靠的部署。敏捷方法最初專為不受管制的行業中的在同一地點工作的較小型項目團隊而設計。我們花了很多年對它們進行擴展，使敏捷方法可以容納更大、更復雜的開發項目。

　　當應用為基于架構的方法的一部分時，持續集成(CI)和測試驅動的開發(TDD)擴展了基本敏捷實踐，使之足以同時提供高品質和項目靈活性。本文將探討在嵌入式軟件開發的上下文中如何采用敏捷方法、CI、TDD。本文還說明了這個組合的好處。

　　如何將持續集成和測試驅動的開發融入敏捷實踐中

　　現在，大多數人可能都已經聽說過敏捷方法。它們帶給軟件開發的概念改變了團隊組織的工作方式、適應不斷變化的需求的方式以及發布軟件的方式。持續集成(CI)是為敏捷開發而創建的，所以敏捷方法是任何 CI 討論的背景。它將開發組織為功能性用戶故事(user story)。這些故事按優先級分成較小的工作組，也稱為沖刺(sprint)。

　　這里的思路是不要提前嘗試解決每一個問題，相反，專注于您已經知道的東西。因此，團隊設計、構建和測試他們對預期功能所知道的內容。這將在完整產品需求的一個子集的基礎上創建一個工作產品。然后，團隊繼續到下一個最高優先級的需求集，并重復上述過程。當然，這是一個高度簡化的視圖，這個過程中有許多變化，但核心是：以增量方式構建您的產品，并嘗試在過程中做一些改進。

　　根據 ThoughtWorks 的 Martin Fowler 的觀點，持續集成(continuous integration)是一種軟件開發實踐，要求團隊成員經常集成他們的工作。每個人至少每天集成一次，這導致每天有多個集成。集成是通過自動化的構建進行驗證的，這些構建運行回歸測試，以盡快檢測集成錯誤。團隊發現，這種方法會導致集成問題大幅減少，更快地實現有凝聚力的軟件開發。

　　這導致 CI 流程的成功執行的最終細節。如果持續集成的思路是為了快速發現問題，從而向每個開發人員提供工作反饋，則必須以某種方式快速評估其工作。測試驅動的開發填補了這項空白。利用 TDD，您可以構建測試，然后等代碼通過測試后再開發功能。隨著每一個新代碼的添加，可以將它的測試添加到在構建集成工作時運行的測試套件中。這將確保新增內容不會破壞之前出現的運作中的工作，并且事實上 “破壞了構建” 的代碼的開發人員可以迅速獲得通知。在圖 1 中顯示了持續集成和測試驅動的開發的典型組合。

　　圖 1. 使用持續集成和測試驅動開發的敏捷實踐

　　回頁首

　　受益于持續集成的項目類型

　　少于 50 人，處理不太復雜的項目的團隊絕對是敏捷開發和 CI 的試驗場。但因為產品已變得 “更智能”，其復雜性也會明顯增加。

　　進入傳統產品的嵌入式軟件的數量是驚人的。如今，一輛新汽車已較少以其馬力作為賣點，而是以其嵌入式軟件技術(例如，自動泊車、先進的安全警告、燃油效率、信息娛樂系統)作為賣點。為創建一輛新汽車而編寫的代碼行數多于為 F16 戰斗機所編寫的代碼行數。

　　產品復雜性的增加，同時加速了新產品的上市時間。嵌入式軟件的普及，結合更嚴格的最后期限，這些將敏捷實踐和 CI 帶到了嵌入式開發人員的面前。

　　回頁首

　　使用敏捷方法實現嵌入式系統開發

　　敏捷方法讓軟件和系統團隊能夠快速響應變化。敏捷方法減少了與傳統的軟件工程相關聯的時間進度風險，在傳統方法中，組件的集成被視為后期階段的工作。后期階段的集成會引起對設計規范的誤解，在發現問題時，對于要解決該問題同時又要滿足其最后期限的團隊而言，已經為時已晚。

　　然而，系統團隊要生成的不僅僅是軟件組件，他們對敏捷方法的某些方面持懷疑態度。他們說，刪除過多的早期規劃，最后就會獲得糟糕的軟件和硬件集成。如果沒有早期的、經常的檢查點來根據架構藍圖驗證進度，團隊可能無法生成可在更廣泛的系統中正常運作的組件。此外，對于正在尋求設計的可重用性和可擴展至較大型項目需求的復雜系統的開發人員來說，敏捷方法看起來可能存在局限性。

　　這些擔心是可以理解的，因為建模和架構不是敏捷技術的特點。但系統開發的 CI 方法對純敏捷方法提供了多項改進。CI 幫助系統開發團隊變得敏捷，并且能夠響應快速的業務變化，在同一時間確保正在開發的實際硬件和軟件都在不斷同步。CI 使得團隊成員能夠在自己的領域組中有效地工作，集中精力于他們最擅長的任務。在每天結束時，他們知道，他們對項目的貢獻被集成，并且各組件可以一起工作。如果有哪個組件無法集成，該組件很快就會被發現。

　　讓我們來考慮復雜系統開發和交付的一些必不可少的組成部分，并探討 CI 如何有助于迎接挑戰。

　　架構

　　當您正在構建復雜系統時，如果沒有藍圖，就無法不斷添加新的特性。如果沒有藍圖，那么在利用額外的迭代時，就會遭遇更多返工的情況。不管您將它稱為藍圖、模型還是架構，它都提供一個開始迭代過程的堅實基礎。

原文轉自：http://www.ibm.com/developerworks/cn/rational/continuous-integration-agile-development/