|
|
[注：原文發布于2011年12月23日]
背景
現如今，單元測試、自動化驗收測試、持續集成等技術手段已被很多項目團隊所采用，它們可以在軟件開發活動中很大程度的保證開發軟件的正確性，即是否滿足了新的需求并且沒有破壞已有的需求。但是如果軟件無法順利的部署到生產環境上，就不能帶來任何商業價值。
作為軟件開發人員，為了驗證軟件是否能夠部署成功，不應該只有當軟件設計、開發、測試等階段結束后才向生產環境或準生產環境部署，而應該把部署作為整個軟件開發活動的一部分，從項目之初，在項目整個持續過程中，實現自動化的構建、部署、測試，即“部署流水線”。
挑戰
有了“部署流水線”之后，當我們在每次代碼提交時，都有可能向測試環境、準生產環境等不同環境部署軟件并測試，會有如下情況涉及到自動化部署：
- 自動化驗收測試前，需要使用最新構造的結果部署到持續集成的測試環境上；
- 當測試需要驗證某一個版本的產品時，可以自動的創建出來該版本的一個環境；
- 對于性能測試、UAT驗收測試、給業務人員演示（showcase）時，可以自動化創建出某一個版本的環境；
- 自動化的向生產環境部署。
這就要求我們擁有自動化部署的能力，它有如下若干特點：
- 需要有自動化的基礎設施管理能力，比如很方便的創建一個節點甚至一整套環境；
- 部署過程代碼化，能夠自動化的安裝、配置軟件；
- 在向各個環境部署時，使用相同的自動化代碼；
- 各個環境與生產環境都需要盡可能的相似，有同樣的操作系統底層組件網絡配置等。
這樣當我們將軟件最終向生產環境部署時，同樣的部署代碼已經在類似的環境中使用并測試過，對于這次發布我們就有足夠的信心能夠成功。
自動化部署
由上可以看出，自動化部署最主要的問題在于如何創建基礎設施，以及如何安裝和配置軟件產品。
在這里我們先說說如何自動化的安裝和配置軟件產品。只要是手工過程可以完成的安裝和配置工作，理論上我們都可以將其代碼腳本化。開發人員或者系統管理員完全可以通過 bash 或者 PowerShell 來完成這些工作。這要求我們將部署代碼以及更為重要的環境配置文件都當作產品的一部分，放入版本控制庫中。
現如今已經有了很多自動化準備技術可以幫助開發人員實現部署腳本，比如比較流行的 Puppet 和 Chef。以 [Chef](http://wiki.opscode.com/display/chef/Home) 舉例，Chef 是一個開源的系統配置和集成框架，它通過自定義的 DSL 領域語言來實現基礎設施和軟件環境的搭建，并支持物理機器、虛擬機、云節點（理論上開放了 ssh 端口都可以）。由于 Chef 的部署代碼是 ruby 語言，所以我們也可以很方便的對其擴展，實現任何自定義的功能。
有了自動化的部署腳本，既可以可控的可重復的執行部署過程。這里需要指出的是，當開發或測試人員在某個環境上發現產品配置問題時（比如發現性能測試環境上應用服務器調用某一個 API 服務的地址有誤），應該極力避免開發人員直接遠程連接到該機器上手工修改。一旦在版本控制中有了自動化部署腳本和配置管理，就應該從源代碼級別來修改，通過重新觸發一次新的“部署流水線”來修正問題并驗證修改是否正確。
云和虛擬化技術
對于自動化的基礎設施管理，近來年已經逐漸成熟的云和虛擬化技術可以給我們帶來很大的好處。云和虛擬化其實并不是一個新的概念，只是最近幾年在技術圈子里很火熱。拋去云和虛擬化華麗的外表，其實這里只需要它們提供給開發人員基礎設施管理的能力，使用云和虛擬化的好處有：
- 快速響應環境的需求
- 平臺標準化，屏蔽底層的硬件物理實現
- 實現對環境搭建的可重復性
- 可以維護環境基線，根據鏡像或副本復制環境
- 可以對環境中的每個節點進行有效監控
當然云和虛擬化的合理使用也會帶來成本上的好處，但更為重要的是給我們開發團隊的自動化部署、持續交付帶來了可能。可以想象，通過云和虛擬化技術，開發人員可以在實現一個需求后，通過一條命令可以幾分鐘內將其自動化部署到一個新創建的環境中，在向業務人員做完演示后，又能通過一條命令將該環境清除。
下面舉兩個目前較為流行的例子，給出大家云和虛擬化技術對自動化部署時基礎設施管理提供的便利。
Amazon平臺
以 Amazon 的 EC2 服務為例，目前已經有了很多對其提供支持的工具，比如 [Amazon EC2 API Tools]( http://aws.amazon.com/developertools/351)。配置好 Amazon 的 key 后，我們可以很方便的創建一個 EC2 Node：
ec2-run-instances ami-a54d67d1 --instance-type t1.micro --region us-west-1 --key MY_AMZ_KEY
# =>服務器在美國西海岸，大小為 micro，系統鏡像為 ami-a54d67d1
但這樣僅僅是創建出一臺最基本的基礎設施，對于開發人員來講，仍需要通過腳本代碼來對其進行自動化配置。不過，目前已經有許多工具已經集成了對 EC2 的自動化部署。比如，Chef 通過一個插件 [knife-ec2]( https://github.com/opscode/knife-ec2)來直接對 Amazon EC2 進行支持。當我們用 Chef 寫出對自己產品的部署配置代碼后，可以通過一條命令自動化地創建出一個具有某種角色的服務器，安裝并配置項目的產品及其依賴，示例腳本如下：
knife ec2 server create "role[rails_server]" --image ami-31814f58 --flavor t1.micro --availability-zone us-east-1a--ssh-key MY_AMZ_KEY
# =>服務器在美國東海岸，大小為micro，系統鏡像為 ami-a54d67d1，Chef 按照部署代碼將其配置為rails_server的角色
vagrant
對于虛擬化來說，現在也有許多技術可以給開發提供自動化基礎設施管理。這里舉 vagrant 為例。[vagrant](http://vagrantup.com/)是一個基于 VirtualBox 創建和發布虛擬化環境的工具，它可以自動化創建虛擬機，并對其進行基礎設施配置。vagrant 的使用非常方便，并且 vagrant 也直接支持 Chef 和 Puppet。我們創建一個 VagrantFile 表示一臺虛擬機，簡單腳本內容如下：
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 初始化一個虛擬機的鏡像）的虛擬機，在創建時會通過 Chef 向其部署 `db_master_server` 的角色。有了VagrantFile我們就只需要通過簡單的命令就可以控制虛擬機了。
vagrant up # =>創建、啟動虛擬機
vagrant suspend # =>掛起虛擬機，保存狀態
vagrant halt # =>停止虛擬機
vagrant destroy # =>銷毀虛擬機
鏡像及部署腳本管理
大部分的云和虛擬化技術都支持從一個鏡像（image 或 box）開始創建節點，然后再結合我們的部署腳本對其進行安裝和配置。對于有些已經比較固定的基礎設置，或者一些配置耗時很長的過程，我們完全可以直接將其做入鏡像中。而對于屬于我們產品的部分，以及一些很容易變化的依賴，應該通過部署腳本來管理。
對于我們自定義創建出來的鏡像，很難放置到團隊的版本控制中去（一般這些鏡像文件都會很大），但是，我們可以把創建鏡像的過程自動化，并將其添加到版本控制中（這就如同我們的版本控制中只有源代碼而不要保存二進制構建結果一樣）。比如 vagrant 就可以通過簡單的命令將當前虛擬機做成鏡像（box）。我們可以通過最基礎的 box 創建虛擬機，通過 Chef 安裝配置機器，然后再通過 vagrant 將其做成鏡像，這個過程完全可以代碼化。
環境管理
通過云和虛擬化技術，再結合自動化部署腳本，提供給了開發人員一種通過受版本控制的腳本代碼來自動創建部署機器的能力。但以上過程還是僅僅在針對一個節點的管理。基于這種能力之上，我們可以實現完整的對環境的自動化管理。
通過對項目系統拓撲結構的配置文件化，我們只需再添加少許工作，完全可以通過一個拓撲結構的配置文件（比如一個 xml 或者 yaml）結合持續集成構造出來的產品庫（二進制構建結果），實現對整個環境的控制：
environment create uat-env --topology.yml
# => 創建出一個名為`uat-env` 的完整環境（集成多個節點）
項目實例
最后給大家提供一個實際的項目案例。在本項目中，團隊中任何一個人員修改并提交了代碼（這里包括生產代碼、測試代碼、驗收用例、部署腳本、配置文件等），都會在“部署流水線”上觸發一個新的流程：
- 打包：編譯、靜態檢查、單元測試、構建安裝包（rpm）；
- 本地測試：通過 localhost 方式運行前臺產品，執行自動化驗收測試；
- 類生產測試：通過 Chef 在 Amazon EC2 上創建測試環境，部署多個節點，執行自動化集成測試；
- 歸檔：將本次流程的構建結果（安裝包、部署腳本、配置）發布到一個歸檔倉庫中
- 手工測試、用戶演示等：任何需要新建一個環境的人員，可以使用已歸檔的安裝包、部署腳本和配置文件在 Amazon EC2 上自動化的創建出來一個環境；
- 準生產環境、生產環境：生產環境是部署在數據中心的 VMware 虛擬機上，當業務人員需要發布某一版本時，使用同樣的安裝包、部署腳本和配置文件，執行自動化的發布。
這樣任何人所作的修改都會得到一個漸進的增強，流水線走的越遠，團隊得到的信心就越強。這種信心不僅僅只限于我們的代碼功能實現的正確性，更重要是對我們的產品能夠順利部署上線的信心。
總結
在自動化測試和持續集成之上，我們通過“部署流水線”可以實現持續交付的能力。可能對于國內某些項目團隊，特別是遺留系統，還需要付出很多努力。但是可以逐步實施，一步一步打造每一個過程。云和虛擬化技術給我們提供了一個自動化基礎設施管理的能力，很大的幫助了我們持續交付中的每一個過程，最終達到了將團隊每一個成員的工作能夠順利的轉化為線上的商業價值。
it知識庫：使用云和虛擬化技術實現持續交付，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
