引子
記得剛加入趨勢開始開發工作
的時候曾被告知，趨勢有一套auto build的系統，會每天夜裡自動把當天check in的**進行構建，生成qa可測試
的build。每個rd都得小心提交code，因為專案結束的時候會看auto build的失敗率。可是構建失敗總是在所難免，尤其是每次要提交candidate build給qa做full cycle測試時，總是在最不該發生的時候發生最不可能發生的事情，至今我還記得為了按時出乙個合格的candidate build，熬夜等build的經歷。
martin fowler大師在2000的一篇文章
中，最早提出了continuous integration（ci，持續整合）的概念。此後，ci作為軟體開發的最佳實踐已經被很多的團隊所採納。從今年年初開始，我們開始了乙個專案新版本的開發，由於專案具有的不確定性，以及開發周期不是特別緊，我們團隊決定在開發流程和質量控制上嘗試著做些改變，在趨勢，change是深植入企業文化的乙個特質，這裡的change不單單只包括老闆和管理團隊自上而下的change，還包括開發團隊和個體，只要你有想法，你都可以嘗試著去改變。（之前看過一篇《測試驅動開發的半年實戰心得》，也來自我們團隊另乙個成員在該專案中對於tdd
的新嘗試） 簡介
正如martin fowler所說，ci要求開發團隊能夠頻繁地整合開發和測試工作，以便盡早發現問題，減少專案風險。這裡的關鍵是「頻繁」，如果ci也只能每天在夜裡做一次整合，那和原來的daily build又有什麼大的差異呢？
ci其實是由一系列的最佳實踐所構成：
· 源**的版本控制和管理
· 自動化構建
· 自動化測試
· **審查
· 自動發行和部署
· 持續反饋
· 等等
通過持續地對**和測試進行盡早頻繁地整合以盡早發現問題，而為了能夠頻繁地整合，又對自動化提出了很高的要求，畢竟只有機器自動完成才有可能在一天裡整合若干次（如果需要專人來負責這件事情，第一老闆不會同意，成本太高了，其二人總是難免有出錯的時候，結果可能整合本身花費的時間超出了開發的時間，這就得不償失了，其三，由於人的適應性和「包容性」，也會讓規範很難形成並遵守） 實踐
既然ci包含了這麼多實踐，我們決定採用漸進的方式來開展，羅馬不是一日建成的，在這個專案中，我們依次展開了：自動構建、持續反饋、自動測試和自動部署等實踐，其中沒有包含**審查的部分。由於趨勢已經有一套成熟的版本控制和構建系統（採用perforce進行版本控制），這使得我們的自動構建變得相對容易，所以我們以自動構建為基礎，展開如下的一些實踐：
- 增量編譯（incremental build）：ci系統會定期監視perforce（每5分鐘），一旦發現有新的**check in，就會觸發增量編譯，取出最新check in的**進行編譯，完成後給check in**的人發出郵件通知（成功或者失敗），如果編譯失敗，對應的owner必須優先解決，否則ci會每隔一段時間（5分鐘）再次嘗試，一直到成功為止。由於增量編譯很快，developer一般在check in**幾分鐘後就能收到通知，如果失敗可以立刻予以修復。
- 單元測試
（unit test
）：ci系統在增量編譯通過的基礎上，會通過我們的測試框架自動呼叫每個模組的單元測試，同樣也會發出測試報告，如果測試失敗也要優先解決。這裡由於我們專案目前還沒有太多單元測試的case，因此我們第一步先把測試框架搭建好，然後對專案中新的**推行單元測試，而對於legacy**，則視情況補充case。
- 自動發行和部署（full build & deployment）：ci系統會定期（3小時）執行full編譯和打包，最後生成可安裝的發行包，然後通過虛擬機器自動部署並安裝到遠端的虛擬機器上。由於完整的編譯和打包操作很費時間（半小時以上），因此沒有必要對每次check in**都執行。通過自動發行和部署，ci系統可以盡早發現打包和安裝過程中的問題，並盡早予以解決。
- 元件測試（component test）：相對於單元測試，元件測試更關注於各個元件間介面部分的測試，此外，單元測試一般要求沒有外部環境的依賴，比如資料庫
，dns等，如果必須有這些依賴必須通過mock的方式解決，而元件測試則執行在真實的產品環境裡，因此資料庫、dns等外部依賴都可以作為測試的輸入輸出。這部分和單元測試一樣，由於沒有現有的基礎，因此我們優先搭建好測試框架，然後對新**進行測試，對於legacy**則視情況補充。
- 自動化功能測試
（feature test）：這是我們現有做的做多一部分，趨勢qa會對很多的功能測試case進行自動化，自然在ci系統中也會把這部分納入。我們採用每天一次的週期來執行這部分測試。
- 覆蓋率（coverage）：既然在ci裡包含了這麼多的測試的內容，那如何衡量測試的效果和標準？覆蓋率便是乙個可行的量化標準。因此我們在ci中也加入了覆蓋率的統計，通過**覆蓋工具，我們可以得到測試執行的**行覆蓋率和條件覆蓋率。這些結果也會被彙總到ci報表裡，這樣我們隨時看到測試的效果和歷史資料的改進。
- 反饋及視覺化：在ci裡還有乙個很重要的部分就是反饋和視覺化。有效的反饋機制可以讓產品的問題盡早暴露並通知到合適的人。而同時通過ci中的視覺化可以展示很多資訊，比如測試用例的數量，覆蓋率，成功和失敗構建的次數，**check in次數等等。通過視覺化，可以達到：1、讓團隊成員了解專案現狀，增加成就感（想想如果你每天可以隨時在報表裡看到由於自己的工作而增加的部分，是不是很酷？）2、讓manager隨時了解團隊現狀，減少專案風險。
工具 工欲善其事，必先利其器。這裡介紹一下我們在ci實踐中用到的一些工具以及選擇的理由。
cruisecontrol，我們選擇它開始ci系統，在選擇它之前我們也考察了其他一些ci系統，最終cc勝出也是有很多理由的：
- 首先很重要的理由cc是免費開源的系統，我們在ci上也剛剛開始嘗試，不太可能去考慮那些很貴的商業系統
- 其次，cc提供了很多的scm工具的整合，比如perforce，svn，starteam等等
- 此外，cc有非常好的擴充套件性和定製能力，在cc的build loop裡可以新增不同的task來增加額外的支援，比如我們的很多測試task、覆蓋率等都可以很方便地加入。
- 最後，cc有著很多的使用者，因此在網上可以找到比較多的支援文件。
python，我們選擇python作為我們很多定製task的編制指令碼，同時也使用python作為測試框架的指令碼（以python測試框架nose為基礎）
cppunit/xunit，這個不用介紹，單元測試必選的測試框架。
bullseye，使用bullseye作為覆蓋率工具，它可以統計行覆蓋率和條件覆蓋率，並且有很好的命令列指令碼支援。
vmware，元件測試和功能測試都需要自動部署到虛擬機器執行，因此我們選擇了簡單好用的viperl作為vm的控制指令碼。用它進行vm snapshot管理任務。
此外，還用到了很多附屬的工具集，比如ssh，expect，ant，xml/xslt，等等。在構建ci系統中乙個體會就是，盡可能使用現有的工具，通過粘合膠水（比如python）將它們串起來完成複雜的任務，從頭造輪子很少是ci最有效率的選擇。 心得
最後，談談在這次ci實踐中感受到的一些心得：
ci和process及agile：敏捷程式設計中要求在每個小迭代中都有交付件，因此要求每個迭代都有完整的整合及測試工作，因而ci是乙個很好的敏捷實踐，用以保證交付件的質量。如果沒有很好的ci，很難做到真正的敏捷。此外，ci的引入也會對現有流程形成一定的影響，乙個實際的例子就是：以前rd總是在每天晚上下班前把當天完成的**check in，而現在則是，完成了一部分就立即check in一部分，並等待幾分鐘，確保check in的**不會讓ci失敗。
ci和testing及automation：其實在前面的實踐中也已經看到，ci中包含了很多的測試實踐，比如單元測試、元件測試、功能測試、系統測試等等。integration不只是compile，更多地是通過測試來保證質量。這對rd和qa都提出了更高的要求，首先，持續意味著我們必須要保證測試的一直可用，在實施ci之前，我們也有單元測試，但單元測試往往在進入alpha或beta後就再也沒人關心和維護了，在專案結束時甚至單元測試的程式連編譯都不能通過。其次，自動化的要求意味著必須要更好地去考慮產品設計、實現、以及測試的設計工作，乙個低耦合的架構才有可能更多地自動化，糟糕的設計工作會讓自動化根本無法進行。
ci和cross-platform開發：趨勢很多專案都有多個平台的版本，因此對軟體的跨平台開發也有很高的要求。那ci對跨平台有什麼意義呢？如果我們在多個開發平台上都有響應的ci系統，那我們在開發任何乙個平台的時候，新增或者修改的**都可以及時通過其他平台上的ci系統得到盡早的驗證和反饋。這樣，通過ci可以更好地要求開發人員考慮跨平台的需要，不能因為乙個平台的**而讓其他平台的ci失敗。
「持續」：我想對ci裡「持續」的理解可以從兩方面來談，首先是持續地整合產品，盡早地發現問題；其次，也可以把這裡的持續理解為持續改進，正如前面說的，ci裡包括很多的實踐，我們不可能一下子引入全部，這就要求我們有持續改進的sense，持續地引入新的實踐（比如加入**審查等）、持續地加入新的case、持續地完善ci和process，在改進的同時，ci又很好地保證了已有部分的長期有效，不過像猴子摘西瓜那樣，缺少歷史的積澱。
企業文化和公司的支援：最後一點心得，和ci關係不大，但在任何公司、任何組織中，要想能不斷改進、嘗試新的實踐和流程，必然離不開組織和制度的支援。我們在實踐ci過程中，manager們給了團隊很多的自由，可以充分去發掘，同時允許失敗，這是任何乙個實踐能夠有所收穫的必備前提。
最後，推薦一本關於持續整合的書籍：continuous integration: improving software quality and reducing risk（持續整合：軟體質量改進和風險降低之道），它對ci進行比較全面的介紹，可以從這本書裡開始對ci做個全面的了解。
ci並不是軟體開發的銀彈，它也並不嘗試解決軟體開發中固有的很多問題，但通過採用ci，可以更好地控制和降低風險，並能更好地保證團隊和流程走在不斷成功和改進的正確道路上，從而讓我們有更大的信心去release產品，refractor**，agile流程。
擁抱敏捷、擁抱變化、擁抱ci！
【**：
持續整合CI
持續整合是什麼？持續整合 continuous integration，簡稱ci 指的是，頻繁地 一天多次 將 整合到主幹。讓產品可以快速迭代，同時還能保持高質量。持續交付 continuous delivery 指的是，頻繁地將軟體的新版本，交付給質量團隊或者使用者，以供評審。它強調的是，不管怎麼...
ci 持續整合系列
持續整合一直很蛋疼,感覺沒底.幾個方面來寫 1,搭建gitlab 配郵箱 網域名稱等使之好用 2,搭建jenkins yum,安裝常見外掛程式 3,搭建sonar,漢化 4,安裝sonar scanner 0,實現sonar scanner能手動掃瞄,在sonar介面可以看到評測結果 1,實現jen...
ci持續整合工程師前景 什麼是 CI 持續整合
現在做測試，經常聽到乙個概念 持續整合 ci continuous integration。這裡呢，用我自己的理解談一下，不正確的地方還請指正。要說持續整合，首先要明白什麼是整合。很多測試同學說到整合，就想到整合測試。這裡的整合主要是指 的整合 舉例來說，比如當前迭代，開發時間為兩周。專案開始後，開...