持續交付模式(3)

　　要避免上述問題，有個出人意料的解決方法：不要讓構建代理的網絡賬號對配置文件有寫權限。這樣，如果有人不相信簽入了配置文件，部署將會失敗，錯誤就可以得到糾正。

　　不過這么做也有自己的問題。用這種方法，只要文件中的配置需要修改，就必須手工操作。如果失敗了，將會使得環境出現問題，從而帶來風險，因為數據更新隨時可能發生。

　　關注點分離和配置文件

　　“關注點分離”這個詞常常用來說明正確的設計決策應該怎么做，如果認真思考誰應該負責做什么，這種方法也是很有幫助的。比如，負責生產環境技術支持的人不關心開發人員選擇注入哪種日志記錄框架。然而，他們關心數據庫連接串和警告發送的郵件地址。

　　我推薦下面這些類型的配置文件。

　　環境設置：與特定環境相關的值，必須按照服務器分開設置。只有某些重要事件發生時，才會需要改動它們，比如新數據庫或新文件服務器上線。

　　代碼作為配置：類似于驅動依賴注入框架的XML文件。雖然看起來像配置文件，但除開發人員外任何人都不應該碰它們。這些文件必須要放在版本控制系統中，而且應該把服務器上的文件標記為只讀。

　　微調配置：這些配置與環境無關，但也許生產環境支持人員需要訪問?？赡馨ū热缗可蟼髋蜗拗?、或是web頁面請求超時設置等。

　　這三種配置中，微調配置需要付出最多精力以保證正確。理想狀態下，應該有缺省配置放在文件中，并保存于版本控制系統，并可以根據特定服務器修改出多個文件，并且不必控制這些文件的版本。

　　配置和培訓

　　避免增加不必要的配置設置，有一個技巧：要求為每個配置項提供文檔和培訓。如果不花時間教給生產環境支持人員何時、為何調整某些值，他們就無法完成這些工作，這些值就成為無法配置的擺設。

　　場景3：使用SOA的多個團隊

　　使用SOA時，通常采取多團隊方式。比如，一個團隊構建數據庫和服務，另一個團隊處理UI，這種情況很常見。有時，兩個團隊的工作會非常緊密，相關團隊成員會常?；ハ嘟粨Q。有時，團隊可能來自地球兩邊的不同公司。不管他們怎么切分，基本的模式相同。

　　結構

　　如場景2，服務團隊需要一個地方來測試構建版本，這樣他們不會對團隊之外造成負面影響。同時，UI開發人員需要一臺可信的服務器，能夠一直保持穩定，否則他們就無法完成自己的工作。因此，除了我們前面提到的單一團隊場景，有必要加入“開發環境”。

　　不考慮UI集成階段，我們看到的順序與場景2相同。交付選項相同，附加條件是只有UI團隊參與在這個流程中。UI團隊對于構建版本質量的意見比服務團隊的意見重要。

　　開發交付選項

　　何時以及如何將代碼交付給開發環境，是很多緊張情勢的來源。有問題的構建版本到了QA環境，QA團隊只要讓其失敗，然后就可以轉向其他任務，比如為新功能準備測試，或是改進回歸測試。要是有問題的構建版本到了開發環境，整個UI團隊就會發現自己無法工作了。因此，雖然QA交付中的多種交付模式都可以運作，基于自動化測試的方式目前是最成功的模式。

　　說明：誰編寫集成測試?

　　處理分離的服務層時，提供服務和消費服務的團隊都要編寫自動化測試，這很重要。提供服務層的團隊最了解服務層內部機制，因此能編寫出別人不知道、或是了解其重要性的測試。

　　不過，這不能成為消費服務的團隊不寫測試的接口。他們的測試覆蓋的場景不僅服務開發者想不到，而且能測試他們對于服務層的理解。比如：UI開發人員會假定某個給定調用永遠不會返回null或負值。測試過UI使用的所有參數組合后，他們就可以確保自己的假設沒有問題。

　　如果你的公司有QA工程師保佑，而不僅僅是只有QA分析人員，他們會發現自己也要針對服務層開發自動化測試。這常常與自動化UI測試連在一起，特別是動作結果不需要通過用戶界面驗證的時候。

　　場景4：采用并行功能開發的多個團隊

　　這種情況很棘手。目前，前面提到的各個場景都假定只有一個單獨的開發主干。一旦開始處理多個開發團隊針對同一代碼庫并行開發，就必須決定何時、如何將功能代碼從團隊分支轉移到基本開發主干中。下面兩種模型是我見過的成功范例。

　　功能推送模型

　　在該模型中，不管何時，只要確定沒有問題，每個團隊都會把自己的變更推送到主干中。該模型的優點在于：團隊可以自給自足。

　　合并-推送

　　該模型中最常用的策略是：在本地合并及測試。只要測試通過，修改的部分就可以推送到主分支。

　　該模型最大的風險是缺乏原子合并。很可能某個團隊修改了某個函數的名字或簽名，而另一個團隊正在加入新的文件使用了同一個函數。如果兩個更改同時簽入，構建版本就會失敗，而且版本控制系統不會報告任何沖突。

　　鎖定-合并-推送

　　該方式需要版本控制系統支持鎖定。推送新的構建版本時，主干應該是鎖定的。新的功能要在本地與主干合并，完成冒煙測試，然后推送到主干。雖然合并的問題可以在鎖定時解決，任何測試的失敗必須馬上把鎖釋放掉。

　　功能拉模型

　　該模型中，團隊永遠不能發布他們的變更。相反，變更控制團隊的人負責將功能拉入到主干中。這樣一來，QA團隊就只會接收到他們準備好測試的變更。

　　功能拉模型需要高級的版本控制系統，支持集成工作項跟蹤。僅僅給變更打上任務號是不夠的，成員必須要說明“將功能X合并入分支Y”，并讓版本控制系統識別所有需要的變更。這可以手工完成，但是會耗費很長時間，而且很容易出錯。

　　對于簡單的合并，變更控制工程師可以自己一個人搞定。復雜的合并，特別是團隊們沒有定期更新自己分支的情況下，需要開發相關功能的團隊協助合并工作。

　　結構

　　不管功能特性如何進入主干，結構都是一樣的。每個團隊都有自己的集成環境，他們會不斷發布，就像基線場景一樣。這些團隊特定的集成環境向通用集成環境導入代碼，然后就走正常流程了。

原文轉自：http://kb.cnblogs.com/page/117932/