持續交付模式(2)

　　從構建服務器提送

　　將構建版本從構建服務器直接提送是更好的選擇。這可以消除我上面提到的那種方式中的多種時間沖突。而且，人們更容易知道被推送的是哪個版本。

　　這種方法也有弱點：人們很容易選擇錯誤的版本推送到生產環境中。

　　重新構建并推送

　　第三種選擇是為持續集成服務器創建新的構建選項，其中包括推送到生產環境這一步。我提醒大家要小心這種方式。雖然理論上重新構建的代碼與你測試的代碼沒有區別，但還是有某些東西增加了出錯的可能性。

　　另一個問題是：這讓你可以選擇多種編譯選項。如果你可以選擇，你可能希望在交付準備服務器上使用調試構建版本，在生產環境上使用發布構建版本。如果有些行為在兩個構建配置中有變化，這會產生災難性后果。

　　雖然使用持續集成服務器做配置很容易，但我再次強調：我不推薦人們選擇這種方式。

　　場景2：加入QA

　　如果QA加入進來，事情就變得非常復雜了。因為你現在必須處理跨團隊的溝通和規劃，你需要更多的構建環境，還有更具意義的所有制感覺。

　　結構

　　一旦QA加入，你可能需要至少3個非生產環境服務器。在某些特定條件下，代碼變更從一臺服務器提送到下一臺服務器。

　　集成環境

　　這是功能代碼簽入后，構建版本到達的第一臺服務器。被稱為“集成環境”，是因為簽入功能代碼會與其他功能代碼完全集成。用來現場檢查一個構建版本是否適于提供給QA。這個環境中允許不穩定，但是不允許構建版本停留太長時間。

　　QA環境

　　這是QA團隊完成自己大部分工作的地方，根據需要會從集成環境更新代碼。

　　交付準備環境

　　交付準備環境現在完全用作演示和在構建進入生產環境前的最后檢查。任何構建版本到了這個環境，都應該是牢固可靠的。交付準備環境也許可以連接到生產環境資源，比如數據庫和文件系統，但不是必須這么做。

　　QA交付選項

　　從構建服務器向集成環境交付代碼，可以使用基線場景中提到的多種方式之一。從集成到QA環境就需要動動腦子，因為涉及多個團隊。下面是我看到的一些成功模式。

　　開發者發起

　　在“開發者發起”模式中，開發人員決定何時進行編譯檢查和把構建版本提送給QA。說得難聽一點，當QA完全“服從”開發人員時，可以使用該模式?？赡艿谝谎劭瓷先?，這對開發人員來說還挺好，實際上常常陰暗著某種問題。比如：如果發生某個質量上的問題，QA人員可能要等很長時間，等著阻礙他們工作的bug得到解決。

　　極端情況下，需要設置自動提送機制，定時自動提送到QA環境。

　　QA發起

　　這是更適合大部分團隊的典型方式。開發人員仍然參與，他們需要在集成環境中檢查他們的構建，然后確定構建版本是否可以提送。

　　在這種方式下，QA準備好測試新功能時，他們會拉過來“已知正常”的最新構建版本。通常是QA經理完成該工作，一般來說他對于QA人員的需要最了解。雖說如此，有些QA團隊允許所有成員提取新構建版本。

　　Test Runner啟動

　　對于想真心做好自動化測試的公司來說，這才是目標。構建版本到達集成服務器后，整個自動化測試套件就開始運行。如果全部通過，構建版本會自動提送到QA。跟其他自動化交付方式一樣，可以采取簽入時方式或定時方式。

　　不要低估這種方式需要投入的成本。不僅需要有完整的測試套件，所有的測試必須還都能通過。構建服務器無法區分測試失敗是由于新功能出問題，還是說有些問題需要留待將來解決。

　　變通方式，是把測試拆分成必須通過(must-pass)的項目和臨時項目。測試從臨時項目開始，特別是在TDD風格編程中用到的測試。只要測試驗證正確、有用，代碼也可以通過這些測試，就轉而處理必須通過的項目。構建服務器不會運行臨時測試，但是會看重必須通過的測試項目的結果。

　　交付準備/生產環境交付選項

　　在持續交付思想指導下，QA對于接收到的給定構建版本，只有兩個選項：構建要么失敗，要么提送到交付準備服務器。QA不會一邊處理一個可用的構建版本，同時等待某些功能完成

　　這的確提出一個問題：如何定義某個構建版本是“可用的”?任何可以安全放到生產環境的構建版本，都是可用的構建版本。如果其中有未完成的功能，但這些功能可以以as-is方式工作，那么構建就可以往前提送。除非某個失敗的功能會影響應用在生產環境中的使用，構建版本就不能停滯在QA這里。

　　進入交付準備服務器后，構建版本在下個發布周期中就要提送到生產環境。盡管持續部署到生產環境很難完全實現，還是經常聽到成功的每周、甚至每日部署。關鍵點在于：一旦一個某件版本證明沒有問題，就需要快速移動到生產環境，這樣團隊就可以聚焦于下一系列要開發的功能。如果構建版本停留在交付準備階段長達幾周乃至幾個月，就會造成無盡的問題。

　　把QA環境和交付準備環境分開，是為了推進工作流。只要一個構建版本提送到交付準備服務器，下一個構建版本就會從集成服務器拉過來。這樣一來，交付準備服務器就總會有一個穩定的環境，供利益相關者和其他第三方查看演示版本，同時QA仍有自己可以工作的環境。如果把服務器的職責混合起來，當環境鎖定時，QA的工作就必須要停下來。

　　配置相關問題

　　一旦有了多個環境之后，配置文件就會成為嚴重的問題。舉個例子，交付準備服務器必須配置正確，避免發生諸如發送測試郵件給所有用戶，或是通過正式支付網關下訂單等問題。我曾與一個剛入門的開發人員一起工作，他當時試圖通過一個配置錯誤的測試服務器購買幾百萬美元的債券。(幸運的是，每張債券的價格比實際價格高，因為訂單沒有成功購買。)

　　出現這種狀況，因為生產環境的配置保存在版本控制系統中，并與應用一起部署。這么做，是要防止出現非生產環境的配置放在版本控制系統中，然后被部署到生產環境服務器上的狀況。

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