模板
教程
環(huán)境
性能
功能
管理
持續集成理論和實(shí)踐的新進(jìn)展(4)
配置管理：
| 級別 | 描述 |
| 3+：企業(yè)級的 | 企業(yè)有統一的配置管理策略。 |
| 3：跨項目的 | 配置管理在多個(gè)項目之間協(xié)調。 |
| 2：自動(dòng)的 | 配置管理策略與持續集成策略緊密結合，團隊成員有頻繁提交的意識。一般采用樂(lè )觀(guān)鎖策略，原子提交。 |
| 1：集成的 | 版本管理下的內容是受控的。通常在版本管理中的代碼是可以編譯的。開(kāi)發(fā)人員能夠訪(fǎng)問(wèn)到自己工作所需要的代碼。開(kāi)發(fā)人員按照一定的規則訪(fǎng)問(wèn)配置管理工具和提交代碼。一般采用悲觀(guān)鎖策略。版本管理工具和構建過(guò)程集成在一起的。 |
| 0：基本的 | 有基本的版本管理。但版本管理下的內容不全面，或者不足以支撐團隊的開(kāi)發(fā)。 |
| -1：無(wú)配置管理 | 沒(méi)有配置管理?；蛘呤褂梅绞酵耆e誤。 |
常用實(shí)踐和工具
持續集成看板7
問(wèn)題：
我們需要讓整個(gè)團隊能夠方便快捷的了解持續集成的狀態(tài)。
上下文：
在完成了基本的構建基礎設施的搭建之后，我們需要讓團隊成員及時(shí)獲得持續集成的狀態(tài)信息。傳統的郵件方式可能會(huì )使人厭煩，或者錯過(guò)重要的構建信息。
解決方案和實(shí)現：
安裝一個(gè)顯示器，將構建的狀態(tài)信息以簡(jiǎn)明的方式展示在顯示器上。將顯示器放置在團隊所有成員都能夠很容易看到的地方。
個(gè)人構建中心
問(wèn)題：
在某些情況下，構建環(huán)境的成本很高，而我們需要每一個(gè)開(kāi)發(fā)人員提交之前完成一次個(gè)人構建。
上下文：
有些測試是依賴(lài)于設備的，而這些設備非常昂貴，并且配置復雜，所以無(wú)法給每個(gè)開(kāi)發(fā)/測試人員一套構建環(huán)境。我們發(fā)現根據本地構建的理論模型，每個(gè)人的提交應該是串行的，這樣我們實(shí)際上可以做到讓這些人共享一套環(huán)境，但是從邏輯上就像是每個(gè)人有一套自己的環(huán)境一樣。
解決方案：
在運行個(gè)人構建的時(shí)候將本地的代碼同步到一臺共享的機器上執行構建，構建完成后結果反饋給提交這次個(gè)人構建的人。
實(shí)現：
個(gè)人構建中心的實(shí)現有很多種方案。這些方案的區別主要在于如何將代碼同步到個(gè)人構建中心服務(wù)器上。兩種常見(jiàn)的方式：一個(gè)是使用rsync或者類(lèi)似方式同步;另一個(gè)是使用分布式配置管理工具如git/hg同步。其拓撲結構如下：
第一種方式相對獨立靈活;第二種方式穩定、高效，但是對于配置管理工具有依賴(lài)。
后果：
個(gè)人構建中心節省了大量的計算資源，同時(shí)也容易使得中心服務(wù)器成為單點(diǎn)失敗的源頭。一旦中心服務(wù)器出現問(wèn)題，可能會(huì )導致團隊的流程受到較大影響。
提交令牌
問(wèn)題：
在實(shí)施本地構建的時(shí)候，向目標分支的提交應該是串行的，以避免構建被破壞后難以定位問(wèn)題來(lái)源。但是團隊往往缺乏一種有效的機制來(lái)保證這種串行。
上下文：
有些團隊試圖通過(guò)技術(shù)的手段來(lái)解決這個(gè)問(wèn)題，比如通過(guò)配置管理上的鎖機制，這種方式和樂(lè )觀(guān)鎖模式有較大沖突。有些團隊通過(guò)團隊內部溝通的方式解決，比如誰(shuí)提交之前都會(huì )通知別人，或者通過(guò)持續集成監視器來(lái)了解當前的構建狀態(tài)，以決定自己是否可以提交。這些方式各自有各自的適用情形，較容易理解。
解決方案和實(shí)現：
使用一個(gè)實(shí)物作為令牌，準備提交的代碼的人首先取得令牌，當代碼提交完成(包括相應的提交構建)之后，將令牌交還。令牌要醒目，并且移動(dòng)方便。小型獎杯、毛絨玩具、較大的頭飾(如下圖)都是不錯的令牌。
問(wèn)題：
在某些團隊中完整構建所花費的時(shí)間可能很長(cháng)，如果每次提交都運行完整的構建會(huì )浪費很多時(shí)間。
上下文：
隨著(zhù)持續集成的日益完善，我們往往會(huì )發(fā)現驗證所花費的時(shí)間越來(lái)越長(cháng)，而大部分驗證趨于穩定，失敗的情況很少見(jiàn)。通過(guò)技術(shù)手段縮短構建時(shí)間是解決問(wèn)題的根本辦法，但是縮短構建時(shí)間是一個(gè)耗時(shí)耗力的工作，很難短期內見(jiàn)效。
解決方案和實(shí)現：
將構建分為幾個(gè)階段執行，在本地構建中僅執行速度比較快、可信度比較高、出錯概率比較大的驗證。利用晚上或者其他合適的時(shí)間執行全面的驗證——我們這次構建稱(chēng)為全量構建。需要注意的是，這種情況下仍然要保證提交構建和本地構建的一致性。
iAnalysis是一款輕量級的持續集成報告工具。該工具的核心思想是將持續集成構建過(guò)程中產(chǎn)生的數據以趨勢和對比的方式展示出來(lái)。正如前文所說(shuō)，我們在2009年的ThoughtWorks Away-Day上討論了敏捷度量的話(huà)題，大家最后一致認為，數據有兩種最基本的用法——橫向對比和縱向對比。橫向對比就是不同的人、不同的團隊之間對比;縱向對比就是現在和過(guò)去對比。iAnalysis正是這種思想的體現。
原文轉自：http://kb.cnblogs.com/page/109735/
