[注：原文發(fā)布于2011年12月23日]

　　背景

　　現(xiàn)如今，單元測試、自動化驗收測試、持續(xù)集成等技術手段已被很多項目團隊所采用，它們可以在軟件開發(fā)活動中很大程度的保證開發(fā)軟件的正確性，即是否滿足了新的需求并且沒有破壞已有的需求。但是如果軟件無法順利的部署到生產(chǎn)環(huán)境上，就不能帶來任何商業(yè)價值。

　　作為軟件開發(fā)人員，為了驗證軟件是否能夠部署成功，不應該只有當軟件設計、開發(fā)、測試等階段結(jié)束后才向生產(chǎn)環(huán)境或準生產(chǎn)環(huán)境部署，而應該把部署作為整個軟件開發(fā)活動的一部分，從項目之初，在項目整個持續(xù)過程中，實現(xiàn)自動化的構建、部署、測試，即“部署流水線”。

　　挑戰(zhàn)

　　有了“部署流水線”之后，當我們在每次代碼提交時，都有可能向測試環(huán)境、準生產(chǎn)環(huán)境等不同環(huán)境部署軟件并測試，會有如下情況涉及到自動化部署：

• 自動化驗收測試前，需要使用最新構造的結(jié)果部署到持續(xù)集成的測試環(huán)境上；
• 當測試需要驗證某一個版本的產(chǎn)品時，可以自動的創(chuàng)建出來該版本的一個環(huán)境；
• 對于性能測試、UAT驗收測試、給業(yè)務人員演示（showcase）時，可以自動化創(chuàng)建出某一個版本的環(huán)境；
• 自動化的向生產(chǎn)環(huán)境部署。

　　這就要求我們擁有自動化部署的能力，它有如下若干特點：

• 需要有自動化的基礎設施管理能力，比如很方便的創(chuàng)建一個節(jié)點甚至一整套環(huán)境；
• 部署過程代碼化，能夠自動化的安裝、配置軟件；
• 在向各個環(huán)境部署時，使用相同的自動化代碼；
• 各個環(huán)境與生產(chǎn)環(huán)境都需要盡可能的相似，有同樣的操作系統(tǒng)底層組件網(wǎng)絡配置等。

　　這樣當我們將軟件最終向生產(chǎn)環(huán)境部署時，同樣的部署代碼已經(jīng)在類似的環(huán)境中使用并測試過，對于這次發(fā)布我們就有足夠的信心能夠成功。

　　自動化部署

　　由上可以看出，自動化部署最主要的問題在于如何創(chuàng)建基礎設施，以及如何安裝和配置軟件產(chǎn)品。

　　在這里我們先說說如何自動化的安裝和配置軟件產(chǎn)品。只要是手工過程可以完成的安裝和配置工作，理論上我們都可以將其代碼腳本化。開發(fā)人員或者系統(tǒng)管理員完全可以通過 bash 或者 PowerShell 來完成這些工作。這要求我們將部署代碼以及更為重要的環(huán)境配置文件都當作產(chǎn)品的一部分，放入版本控制庫中。

　　現(xiàn)如今已經(jīng)有了很多自動化準備技術可以幫助開發(fā)人員實現(xiàn)部署腳本，比如比較流行的 Puppet 和 Chef。以 [Chef](http://wiki.opscode.com/display/chef/Home) 舉例，Chef 是一個開源的系統(tǒng)配置和集成框架，它通過自定義的 DSL 領域語言來實現(xiàn)基礎設施和軟件環(huán)境的搭建，并支持物理機器、虛擬機、云節(jié)點（理論上開放了 ssh 端口都可以）。由于 Chef 的部署代碼是 ruby 語言，所以我們也可以很方便的對其擴展，實現(xiàn)任何自定義的功能。

　　有了自動化的部署腳本，既可以可控的可重復的執(zhí)行部署過程。這里需要指出的是，當開發(fā)或測試人員在某個環(huán)境上發(fā)現(xiàn)產(chǎn)品配置問題時（比如發(fā)現(xiàn)性能測試環(huán)境上應用服務器調(diào)用某一個 API 服務的地址有誤），應該極力避免開發(fā)人員直接遠程連接到該機器上手工修改。一旦在版本控制中有了自動化部署腳本和配置管理，就應該從源代碼級別來修改，通過重新觸發(fā)一次新的“部署流水線”來修正問題并驗證修改是否正確。

　　云和虛擬化技術

　　對于自動化的基礎設施管理，近來年已經(jīng)逐漸成熟的云和虛擬化技術可以給我們帶來很大的好處。云和虛擬化其實并不是一個新的概念，只是最近幾年在技術圈子里很火熱。拋去云和虛擬化華麗的外表，其實這里只需要它們提供給開發(fā)人員基礎設施管理的能力，使用云和虛擬化的好處有：

• 快速響應環(huán)境的需求
• 平臺標準化，屏蔽底層的硬件物理實現(xiàn)
• 實現(xiàn)對環(huán)境搭建的可重復性
• 可以維護環(huán)境基線，根據(jù)鏡像或副本復制環(huán)境
• 可以對環(huán)境中的每個節(jié)點進行有效監(jiān)控

　　當然云和虛擬化的合理使用也會帶來成本上的好處，但更為重要的是給我們開發(fā)團隊的自動化部署、持續(xù)交付帶來了可能。可以想象，通過云和虛擬化技術，開發(fā)人員可以在實現(xiàn)一個需求后，通過一條命令可以幾分鐘內(nèi)將其自動化部署到一個新創(chuàng)建的環(huán)境中，在向業(yè)務人員做完演示后，又能通過一條命令將該環(huán)境清除。

　　下面舉兩個目前較為流行的例子，給出大家云和虛擬化技術對自動化部署時基礎設施管理提供的便利。

　　Amazon平臺

　　以 Amazon 的 EC2 服務為例，目前已經(jīng)有了很多對其提供支持的工具，比如 [Amazon EC2 API Tools]( http://aws.amazon.com/developertools/351)。配置好 Amazon 的 key 后，我們可以很方便的創(chuàng)建一個 EC2 Node：

ec2-run-instances ami-a54d67d1 --instance-type t1.micro --region us-west-1 --key MY_AMZ_KEY
# =>服務器在美國西海岸，大小為 micro，系統(tǒng)鏡像為 ami-a54d67d1

　　但這樣僅僅是創(chuàng)建出一臺最基本的基礎設施，對于開發(fā)人員來講，仍需要通過腳本代碼來對其進行自動化配置。不過，目前已經(jīng)有許多工具已經(jīng)集成了對 EC2 的自動化部署。比如，Chef 通過一個插件 [knife-ec2]( https://github.com/opscode/knife-ec2)來直接對 Amazon EC2 進行支持。當我們用 Chef 寫出對自己產(chǎn)品的部署配置代碼后，可以通過一條命令自動化地創(chuàng)建出一個具有某種角色的服務器，安裝并配置項目的產(chǎn)品及其依賴，示例腳本如下：

knife ec2 server create "role[rails_server]" --image ami-31814f58 --flavor t1.micro --availability-zone us-east-1a--ssh-key MY_AMZ_KEY
# =>服務器在美國東海岸，大小為micro，系統(tǒng)鏡像為 ami-a54d67d1，Chef 按照部署代碼將其配置為rails_server的角色

　　vagrant

　　對于虛擬化來說，現(xiàn)在也有許多技術可以給開發(fā)提供自動化基礎設施管理。這里舉 vagrant 為例。[vagrant](http://vagrantup.com/)是一個基于 VirtualBox 創(chuàng)建和發(fā)布虛擬化環(huán)境的工具，它可以自動化創(chuàng)建虛擬機，并對其進行基礎設施配置。vagrant 的使用非常方便，并且 vagrant 也直接支持 Chef 和 Puppet。我們創(chuàng)建一個 VagrantFile 表示一臺虛擬機，簡單腳本內(nèi)容如下：

Vagrant::Config.run do |config|
config.vm.box = "centos6"
config.vm.provision :chef_solo do |chef|
chef.cookbooks_path = "/PATH/TO/chef-repo/cookbooks"
chef.roles_path = "/PATH/TO/chef-repo/roles"
chef.add_role "db_master_server"
end
end

　　VagrantFile也是由 ruby 寫成，這份VagrantFile表示是一臺基于 centos6 box （vagrant 初始化一個虛擬機的鏡像）的虛擬機，在創(chuàng)建時會通過 Chef 向其部署 `db_master_server` 的角色。有了VagrantFile我們就只需要通過簡單的命令就可以控制虛擬機了。

vagrant up # =>創(chuàng)建、啟動虛擬機
vagrant suspend # =>掛起虛擬機，保存狀態(tài)
vagrant halt # =>停止虛擬機
vagrant destroy # =>銷毀虛擬機

　　鏡像及部署腳本管理

　　大部分的云和虛擬化技術都支持從一個鏡像（image 或 box）開始創(chuàng)建節(jié)點，然后再結(jié)合我們的部署腳本對其進行安裝和配置。對于有些已經(jīng)比較固定的基礎設置，或者一些配置耗時很長的過程，我們完全可以直接將其做入鏡像中。而對于屬于我們產(chǎn)品的部分，以及一些很容易變化的依賴，應該通過部署腳本來管理。

　　對于我們自定義創(chuàng)建出來的鏡像，很難放置到團隊的版本控制中去（一般這些鏡像文件都會很大），但是，我們可以把創(chuàng)建鏡像的過程自動化，并將其添加到版本控制中（這就如同我們的版本控制中只有源代碼而不要保存二進制構建結(jié)果一樣）。比如 vagrant 就可以通過簡單的命令將當前虛擬機做成鏡像（box）。我們可以通過最基礎的 box 創(chuàng)建虛擬機，通過 Chef 安裝配置機器，然后再通過 vagrant 將其做成鏡像，這個過程完全可以代碼化。

　　環(huán)境管理

　　通過云和虛擬化技術，再結(jié)合自動化部署腳本，提供給了開發(fā)人員一種通過受版本控制的腳本代碼來自動創(chuàng)建部署機器的能力。但以上過程還是僅僅在針對一個節(jié)點的管理。基于這種能力之上，我們可以實現(xiàn)完整的對環(huán)境的自動化管理。

　　通過對項目系統(tǒng)拓撲結(jié)構的配置文件化，我們只需再添加少許工作，完全可以通過一個拓撲結(jié)構的配置文件（比如一個 xml 或者 yaml）結(jié)合持續(xù)集成構造出來的產(chǎn)品庫（二進制構建結(jié)果），實現(xiàn)對整個環(huán)境的控制：

environment create uat-env --topology.yml
# => 創(chuàng)建出一個名為`uat-env` 的完整環(huán)境（集成多個節(jié)點）

　　項目實例

　　最后給大家提供一個實際的項目案例。在本項目中，團隊中任何一個人員修改并提交了代碼（這里包括生產(chǎn)代碼、測試代碼、驗收用例、部署腳本、配置文件等），都會在“部署流水線”上觸發(fā)一個新的流程：

• 打包：編譯、靜態(tài)檢查、單元測試、構建安裝包（rpm）；
• 本地測試：通過 localhost 方式運行前臺產(chǎn)品，執(zhí)行自動化驗收測試；
• 類生產(chǎn)測試：通過 Chef 在 Amazon EC2 上創(chuàng)建測試環(huán)境，部署多個節(jié)點，執(zhí)行自動化集成測試；
• 歸檔：將本次流程的構建結(jié)果（安裝包、部署腳本、配置）發(fā)布到一個歸檔倉庫中
• 手工測試、用戶演示等：任何需要新建一個環(huán)境的人員，可以使用已歸檔的安裝包、部署腳本和配置文件在 Amazon EC2 上自動化的創(chuàng)建出來一個環(huán)境；
• 準生產(chǎn)環(huán)境、生產(chǎn)環(huán)境：生產(chǎn)環(huán)境是部署在數(shù)據(jù)中心的 VMware 虛擬機上，當業(yè)務人員需要發(fā)布某一版本時，使用同樣的安裝包、部署腳本和配置文件，執(zhí)行自動化的發(fā)布。

　　這樣任何人所作的修改都會得到一個漸進的增強，流水線走的越遠，團隊得到的信心就越強。這種信心不僅僅只限于我們的代碼功能實現(xiàn)的正確性，更重要是對我們的產(chǎn)品能夠順利部署上線的信心。

　　總結(jié)

　　在自動化測試和持續(xù)集成之上，我們通過“部署流水線”可以實現(xiàn)持續(xù)交付的能力。可能對于國內(nèi)某些項目團隊，特別是遺留系統(tǒng)，還需要付出很多努力。但是可以逐步實施，一步一步打造每一個過程。云和虛擬化技術給我們提供了一個自動化基礎設施管理的能力，很大的幫助了我們持續(xù)交付中的每一個過程，最終達到了將團隊每一個成員的工作能夠順利的轉(zhuǎn)化為線上的商業(yè)價值。

it知識庫：使用云和虛擬化技術實現(xiàn)持續(xù)交付，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。