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

　　架構在最多 50 名團隊成員的較小型項目中很有幫助，但是，如果超出了這個規模，就必須做一些前期工作，以了解組件化、重用和可變性。此前期分析使您可以拆分團隊，但仍發布協調的產品。在讓硬件和軟件開發人員一起工作也是這樣，就像對包括嵌入式軟件的復雜系統一樣。

　　仿真

　　通過在仿真模型中捕獲架構，團隊可以看到系統如何響應不同的輸入。這種形式的早期測試可以驗證系統是否如預期般執行，從而滿足要求。這也使得設計人員能夠可視化設計的任何意想不到的后果。在檢查代碼文本時，很難看出這些意想不到的后果。當查看系統模型時，它們會變得明顯得多，在查看工作中的系統模型時，它們甚至變得更加明顯。

　　在這種方式中，建模和仿真讓測試和集成可以在設計工作開始時就立刻開始執行，從而消除了在嵌入式硬件尚未可用時可能遇到的延遲。它可以節省對那些不可行的早期架構原型所進行沒有必要的大量投資。即使您的確有可用的硬件，持續集成也要求不斷地構建。

　　越早需要看到結果，構建環境就會變得越昂貴。由于 CI 的主要目的是盡可能快地提供結果，仿真使您能夠在無需支付超高硬件成本的情況下進行測試。它還提供了一個更簡單的方法來溝通組件的功能，這對于敏捷開發中常見的結對編程和 “代碼審查” 非常有價值。

　　構建自動化

　　持續集成要求構建自動化，也就是說，提供讓軟件自動編譯和鏈接到可執行文件的能力。速度非常重要，因為大型構建可能需要很長時間。如果沒有快速、可靠的構建，就會缺乏解決集成問題所需的洞察力。在運行集成構建時，會識別由兩位或多位開發人員所做的更改之間的沖突，以便解決該沖突。所以，如果發現問題，要解決前一個構建的沖突的開發人員可以通過硬件仿真來測試更改后的代碼，不會耽誤其他開發人員的工作。但是，要實現這種效率，則必須不斷進行集成構建，在上一個構建完成時就立刻開始新的構建。這與其他流程所使用的每天一次或每周一次的構建非常不同。

　　當然，這種方法要求構建自動化，因為要將一天中反復多次開始構建的任務指定給一個人是不切實際的。此外，構建應快速執行，這往往要求構建是多線程的。多線程的構建可以使用軟件的不同組件，利用在某個其他組件上運行的構建并行地執行這些組件，從而加快匯總的構建時間。它的確需要更多硬件和更復雜的腳本。腳本變得越復雜，構建管理工具就會變得越有價值。

　　工作管理

　　主要的敏捷概念是將工作拆分成為易于管理的小塊的價值。這也是 CI 的基本前提：及早地、經常地改正錯誤。這樣就可以避免它們稍后在項目中發展成為更大、更難解決的問題。

　　該技術提供的好處之一是能夠提供在項目時間表中多個日期進行構建和測試的更小的功能性發布。通過驗證來自團隊的架構、需求和時間表估算，每個交付都降低了項目風險。在敏捷方法中，尚未完成的工作被稱為積壓(backlog)工作。如果您開始將工作分配給小交付增量(被稱為沖刺)，分配給某個沖刺的工作被稱為沖刺積壓(sprint backlog)。分配給未來沖刺的剩余工作被稱為項目積壓(project backlog)。目標是將在沖刺定義的時間內可以實現的盡可能多的工作項分組到沖刺中。

　　此流程高度依賴于指標的收集，使團隊可以更準確地預測任務所需的時間量，并推算出可以放入某個沖刺交付的任務量。然而，與這些指標等價的是，數據收集即使對于小團隊也非常繁瑣。當您將這些小團隊組合在一起來產生更加復雜的產品時，任務會相當龐大，且無法手工完成。

　　市場上有很多產品可以幫助組織完成其工作，跟蹤工作的完成狀況，并生成與工作完成了多少、完成的速度、完成的質量等有關聯的指標。如果遵循了 CI 實踐，則必須將所確定的集成錯誤迅速添加到工作積壓中，并作為高優先級移動到列表的頂部。在這方面，在市場上最好的產品提供了新工作項和構建管理系統之間某種程度的集成，因此，在每個構建后識別的錯誤就可以迅速得到修復，并與現有工作項集成，優先升級，并路由到正確的團隊。

　　質量管理

　　質量管理是確保所有產品要求均已經過測試的開發生命周期實踐。該工作需要得到組織和理解，使正確的測試可以在需求變更時得到更新。質量管理有助于項目經理回答以下問題：

　　如果我的產品必須在下周發布，哪些部分將會產生最大風險?

　　我們是否可以在沒有低層要求的情況下發布產品?

　　這是否是一個高品質的發布?

　　在面對加快交付周期的市場壓力時，快速回答這些問題可以幫助業務充滿信心地將產品發布到市場。管理人員可以更好地了解要添加哪些資源、在何處調整產品特性，以及何時重新建立交付日期，從而獲得最大優勢。

　　利用測試驅動的開發，測試的概念對于開發工作更加重要。在 TDD 中，需要根據需求編寫測試，然后開發代碼，直到它通過測試。這將確保沒有創建額外的功能，即開發團隊稱為 “鍍金” 的東西。即使額外的功能或特性似乎是一個好主意，但在不要求驅動決策時，額外的工作可能會提高成本，并增加交付時間。最終產品可能并沒有實際提高客戶滿意度。

　　自動測試

　　在創建多個構建后，團隊需要重新測試之前的版本中的可行功能。這個重新測試的流程以前被稱為 “好代碼(good code)”，現在稱之為回歸測試(regression testing)。它確保沒有因為剛剛完成的變更而將錯誤引入或重新引入之前測試過的代碼。利用 CI，可以將自動的回歸測試編寫為腳本，在每個構建結束時運行。這使得開發人員能夠得到有關在在新構建中發現的錯誤的即時反饋。這一步是為了通知開發人員，他們所生產的新代碼在按要求(或沒有按要求)工作。如果沒有回歸測試，開發人員只知道構建已完成。由于無論如何都必須創建測試，所以 TDD 并沒有添加額外的工作。它只是將工作的順序顛倒了，首先創建測試，然后編寫代碼。

　　即使沒有任何自動化測試，傳統的瀑布式開發項目也是有可能生存的?？梢悦枋龊蜆嫿椖?，然后讓一大堆人不斷對其進行測試。但只要您開始定期發布，這一流程就會出現問題。手動測試一個在一天中被多次構建的系統是不可行的。

　　協作

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