模板
教程
環(huán)境
性能
功能
管理
持續集成理論和實(shí)踐的新進(jìn)展(3)
廣義的持續集成及持續集成策略
當要把持續集成實(shí)踐應用到團隊的時(shí)候，有很多額外的技術(shù)或者非技術(shù)因素需要考慮。
組織結構
持續集成是一個(gè)重要的溝通工具，而開(kāi)發(fā)過(guò)程中兩個(gè)最需要緊密溝通的角色就是開(kāi)發(fā)和測試。在我們常見(jiàn)的組織結構中開(kāi)發(fā)和測試往往隸屬于不同的部門(mén)，甚至這些部門(mén)隸屬于不同的高級經(jīng)理。這往往會(huì )給持續集成的推廣帶來(lái)很大的阻力。這是因為持續集成從環(huán)境搭建到運行維護都需要兩種角色的通力合作。我們的經(jīng)驗是這類(lèi)涉及到人力資源的事情除非某一級“共同的大老板”出面，否則是很難協(xié)調的。“借調”這樣的方式往往不能保證效果。
流程
放到團隊的角度看待流程應當更加關(guān)注于各個(gè)成員之間的配合。每個(gè)開(kāi)發(fā)人員提交代碼之前應當確保是經(jīng)過(guò)本地構建的;開(kāi)發(fā)人員在提交之前應該確認主線(xiàn)上的代碼是通過(guò)了持續集成的;測試人員測試的版本應該是通過(guò)了某次持續集成的，并且有相應的具體版本信息。
為了保障流程的順利執行，我們還經(jīng)常采用持續集成看板、提交令牌等輔助手段。
環(huán)境
環(huán)境是指持續集成運行時(shí)所依賴(lài)的軟件和硬件的集合。我們經(jīng)常遇到的一個(gè)問(wèn)題是，軟件在一臺機器上能夠通過(guò)持續集成的驗證，而在另一臺機器上則不能通過(guò)。這通常是因為我們對持續集成環(huán)境的定義不明確造成的。所以在搭建持續集成和在組織內推廣持續集成的時(shí)候，我們需要特別注意持續集成環(huán)境的標準化，明確指出持續集成運行時(shí)依賴(lài)哪些第三方庫，機器配置如何，端口和網(wǎng)絡(luò )狀況如何等等。
我們經(jīng)常采用將持續集成環(huán)境加入配置管理的方式來(lái)解決環(huán)境標準化的問(wèn)題。
分層
在大型團隊(超過(guò)100人)中，扁平的開(kāi)發(fā)組織結構是運行起來(lái)是比較困難的。常見(jiàn)的做法是按照特性，將團隊劃分為10人左右的小團隊。一般來(lái)說(shuō)，如果團隊數量超過(guò)10個(gè)，還會(huì )再增加一層架構。這時(shí)候，配置管理的策略也應當做出調整。常見(jiàn)的做法是為每個(gè)團隊拉出一個(gè)分支，設置一個(gè)集成分支用于將各個(gè)特性分支的內容整合在一起。需要注意的是，這里每個(gè)分支都應該具備所有代碼的訪(fǎng)問(wèn)權限，也就是所有分支是同根的、等價(jià)的。
在實(shí)施持續集成時(shí)，對于測試的類(lèi)型應該有比較明確的定義。一般來(lái)說(shuō)，我們經(jīng)常把測試分為三級——單元測試、集成測試和系統測試。這是一個(gè)很大的話(huà)題，這里只是說(shuō)明此處的單元測試并不是指針對函數的測試。雖然單元測試主要是函數基本的測試，但是每個(gè)單元測試應該針對的是特性或者對應代碼在實(shí)現該特性上所發(fā)揮的作用。
單元測試的運行速度通常非?？?，應該在數秒到數分鐘。單元測試應該覆蓋絕大部分的特性需求。集成測試單個(gè)測試的運行速度通常會(huì )比單元測試慢一個(gè)數量級，比如存在文件讀寫(xiě)或者其他的IO和網(wǎng)絡(luò )操作。集成測試主要用于保證系統的各個(gè)組件之間的調用是工作的。系統測試的運行速度一般會(huì )比集成測試慢，通常需要將整個(gè)系統運行起來(lái)，比如Web開(kāi)發(fā)中的selenium測試。系統測試主要用于測試系統的正確路徑(Happy Path)可以工作。有的團隊會(huì )開(kāi)發(fā)很多基于整個(gè)系統的回歸測試，也屬于系統測試。就場(chǎng)景的覆蓋而言，單元測試>集成測試>系統測試，從運行時(shí)間來(lái)看則相反。
在幫助客戶(hù)實(shí)施和推廣持續集成的過(guò)程中我們逐漸總結出一些原則，幫助客戶(hù)評估現狀，分析和設計未來(lái)的目標。該評估方法借鑒了ThoughtWorks敏捷成熟度模型中有關(guān)配置管理、測試、構建等內容，并做了適當的簡(jiǎn)化。
構建：
| 級別 | 描述 |
| 3+：對外防御的 | 團隊能夠根據自己的需要，協(xié)調其他團隊的持續集成，當依賴(lài)的其他團隊的代碼和組件或者第三方庫和基礎設施發(fā)生改變時(shí)自動(dòng)進(jìn)行構建。團隊對于外部依賴(lài)的可靠性有信心。 |
| 3：對內防御的 | 構建是自動(dòng)的。由測試和檢查來(lái)保證團隊內部的開(kāi)發(fā)質(zhì)量。持續集成的修復具有最高的優(yōu)先級。團隊對持續集成的結果有信心。 |
| 2：頻繁的 | 構建是自動(dòng)的，而且構建的速度較快。構建的觸發(fā)條件是明確的，通常每次代碼提交都會(huì )觸發(fā)構建。團隊中的每個(gè)人都會(huì )觸發(fā)構建，并且了解構建的狀態(tài)。 |
| 1：重復執行 | 構建是自動(dòng)的，但是執行的不夠頻繁。構建的觸發(fā)是隨機的或者頻率是非常低的（低于每天一次）。構建的速度通常非常慢，比如一次構建超過(guò)半個(gè)小時(shí)。 |
| 0：可重復的 | 主要依賴(lài)于手動(dòng)的方式構建軟件，但是每次構建的方式都是相同的或者相似的。通常有相關(guān)的文檔的指導。經(jīng)常團隊指定某個(gè)人負責構建軟件，雖然大部分人都能夠做這件事情。 |
| -1：手動(dòng)的 | 主要依賴(lài)于手動(dòng)的方式集成軟件。每次集成的方式可能不一樣。經(jīng)常團隊中只有個(gè)別人能夠將軟件集成起來(lái)。 |
測試：
| 級別 | 描述 |
| 3+：全面集成的 | 全團隊對測試負責。測試驅動(dòng)整個(gè)開(kāi)發(fā)過(guò)程。測試與構建完全集成。 |
| 3：測試驅動(dòng)的 | 業(yè)務(wù)分析人員和開(kāi)發(fā)人員均參與測試。測試在構建過(guò)程中自動(dòng)執行。開(kāi)發(fā)人員實(shí)踐測試驅動(dòng)開(kāi)發(fā)。 |
| 2：集成的 | 開(kāi)發(fā)人員參與測試。部分測試集成在構建過(guò)程中執行。大部分測試在軟件開(kāi)發(fā)過(guò)程中執行。 |
| 1：共享的 | 開(kāi)發(fā)人員參與測試。測試并未集成在構建過(guò)程中。部分測試在軟件開(kāi)發(fā)過(guò)程中執行，大部分測試在軟件開(kāi)發(fā)結束后執行。 |
| 0：審查的 | 測試由專(zhuān)門(mén)的測試人員負責。有部分測試是在軟件開(kāi)發(fā)過(guò)程中執行。但大部分測試在軟件開(kāi)發(fā)結束后執行。 |
| -1：獨立的 | 測試由專(zhuān)門(mén)的測試人員負責。僅在軟件開(kāi)發(fā)結束后執行。 |
原文轉自：http://kb.cnblogs.com/page/109735/
