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