持續交付模式

　　英文原文：Patterns for Continuous Delivery

　　當你有了持續集成需要的構建服務器和腳本之后，下一個問題肯定是：“我們該拿這些構建版本怎么辦?”持續交付，以自動化或半自動化方式，將構建版本從一個環境提送(promote)到更接近實際生產的交付準備環境;這常常是公司在這方面演進的下一步。

　　任何規模的公司都可以實施持續交付，但是具體流程會根據公司具體情況差異很大。顯而易見，四人全能團隊的需要，與大規模、多團隊、配備正式QA和設備精良的產品支持部門這樣的公司，二者一定有很大差別。本文沒有試圖提出萬能方案，而是覆蓋多種場景和選擇。

　　選擇持續交付工具集

　　為持續交付選擇工具集，是最不重要的決策。當你制定出工作流程之后，只需要選擇相匹配的工具集即可?？紤]到初始設置和配置的工作量，花幾天時間構建自己定制的工具也不是非理性選擇。

　　更重要的是，這樣做沒有鎖定的風險。跟選擇版本控制系統不同，你可以使用多種持續交付工具，而且可以互相之間自由切換。QA團隊從開發人員那里拉出構建版本使用一種工具，向準備服務器推送時使用另一種工具，這樣的事情也有所耳聞。

　　基線場景

　　在基線場景中，我們要以有限的資源找出公司中的模式。像由3到4人構成的IT部門，常常兼做開發和系統管理。這樣規模的團隊常常支持中小型業務，特別是不以技術為主業務的公司。大型公司也有可能這樣組織，把人分成多個、很可能是互相獨立的小組，各小組之間也沒有交互。

　　在真正開始進行持續交付之前，需要做一些必要的設置工作。首先，最重要的是要有版本控制系統，以及與之匹配的構建服務器。這第一臺構建服務器將會是你的持續集成服務器，它要保證每次簽入動作都能成功構建。一般來說，你需要一個“現成”的構建服務器擔當此任。能夠監控簽入動作還要自動初始化構建，要想手工開發這樣的東西，真正操作起來常常要比聽起來難得多。即使可以在版本控制系統中加入觸發機制，完成諸如失敗構建通知這樣的功能也不值得花太多功夫。

　　即使在資源有限的作坊式公司，交付準備服務器(staging server)也是持續交付的必要組成部分。交付準備服務器應該盡可能模擬出生產環境。“你有多少預算”常常是首要問題。如果你的生產環境有價值幾十萬美元的數據庫服務器，很可能你無法負擔搭建一個同樣的交付準備服務器。而且可能你也不想這么做。

　　在模擬生產環境時，有一個常見錯誤：過高匹配硬件環境。假如你的生產環境每秒處理100個請求，如果為交付準備服務器購買同樣硬件，但測試時每秒只執行幾個請求，你的結果就是有問題的。理想情況下，為了模擬生產環境請求，你還應該購買并設置負載服務器，但這么做成本太高，而且耗費時間。對于這種規模的團隊，降低交付準備服務器處理能力是更佳策略。

　　另一個常常忽略的需求，是構建的版本化。必須有某種唯一的識別機制，保證可以區分開每個構建和其他構建版本。如果針對單一的公共主干代碼，簡單的時間戳或是自增長版本號也就夠了。本文后面會討論更復雜的場景。

　　結構

　　有了上面列出來的部件，現在你的環境應該跟下面的圖很像：

　　交付策略

　　構建服務器編譯代碼，交付準備服務器等候接收構建結果，有了這二者之后，下一步就是決定你的部署策略。小團隊有兩種選擇：“簽入時交付”和“定時交付”。

　　簽入時交付

　　“簽入時交付”策略的優勢在于馬上產生的滿足感。根據代碼庫的規模，從簽入新功能代碼到能夠在交付準備服務器上測試，一兩分鐘就夠了。

　　這種方式的主要問題在于：交付準備服務器會被蹂躪得不穩定。很多時候，我見到有人試圖測試某個功能，突然新的版本推到交付準備服務器上了，破壞了正在運行的測試。更糟糕的是：交付準備服務器常常作為演示服務器使用，在某些重要的演示時，很可能出現嚴重的后果。

　　代碼混亂是另一個問題。比如，如果三次簽入在很短的時間內先后進行，那么可能觸發三個構建、交付周期，實際上只有最后一次才是必要的。極端情況，這會帶來很大混亂，交付部署環境將無法有充足的時間展示自己的功用。不過，大多數構建服務器都有選項，可以延遲構建的開始，或是在給定時間間隔內避免多次構建。

　　定期交付

　　定期交付策略更易于預測。所有人都知道交付何時啟動，并可以規劃自己的代碼簽入是在交付之前還是之后進行。典型做法是一天構建/交付一次或兩次。

　　每日構建的缺點在于，它會給工作環境帶來不必要的壓力。開發人員會發現自己要趕著在構建截止時間之前完成一次簽入。在每日深夜構建，這時開發人員應該不在工作，可以減輕壓力，但也意味著除非到第二天，他們無法執行第二層測試。

　　當我們開始使用“每日構建”這樣的詞匯時，很容易忘記我們實際上不是在談論構建。我們真正在談論的是完整的構建、交付周期。有了持續集成，如果構建失敗，你馬上就能知道。接下來是要修復問題，還是要回滾簽入，就很簡單了;只要規劃好的交付完成了，軟件就已經準備好部署到生產環境。

　　部署到生產環境

　　該場景的假設是：實在沒人能夠完成任何特定版本前要做的大量測試工作。只要交付準備服務器上的檢查完成，構建版本就會直接提送到生產環境中。但即使如此，也有多種選項，各有其妥協之處。

　　從交付準備階段提送

　　將經過驗證的構建版本從交付準備服務器直接提送，是常見的選擇。其優勢在于高度確定性。理論上，測試一個版本的構建、然后錯誤地部署另一個版本，這樣的事情不可能發生。寫腳本把文件從交付準備服務器拷貝到生產環境，也很容易。

　　但像很多事情一樣，理論跟現實總是有差距的。有了到交付準備服務器的自動化推送，很可能出現這樣的情況：測試完成，去倒一杯咖啡，回來后工作針對的構建版本可能就完全不同了。更糟糕的情況是：構建代理會開始覆蓋交付準備服務器上的文件，而這時這些文件正在推送到生產環境服務器上。

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