背景

在軟件發展的幾十年歷程中，人們一直在孜孜不倦地追求用更快的速度交付更高質量的軟件及服務。無論是不斷革新的軟件工程思想，還是持續優化的編程語言及工具，亦或是紛紛出現的可復用開發、測試框架，無不大大提高了整個軟件開發及交付的效率。但是，與此同時，軟件系統復雜度急速上升，可靠性要求越來越高，這讓軟件快速交付依然非常具有挑戰。尤其是進入互聯網和云計算時代，市場競爭異常激烈，人們對于軟件交付的周期已經從原來的以季度、年度為單位縮短到以天計算，以便在市場中快速試錯，找到真正的用戶需求。這些都給傳統的軟件開發、測試體系提出了巨大的挑戰。

[[157936]]

最近幾年，公有IaaS云快速發展，人們已經認識到云計算帶來的強大敏捷性和低成本優勢。在越來越多軟件及服務的生產環境直接部署和運行在IaaS云上的同時，企業級用戶也在積極嘗試利用IaaS云服務來改進自己的軟件開發、測試體系。但是，由于發展路徑問題，國內的公有云開發人員還是習慣于以包年包月的方式使用IaaS云服務，并沒有充分發揮出云計算彈性、靈活和按需服務的優勢。隨著國內IaaS云開始普遍提供API，國內的開發人員必定也會逐步體會到彈性云計算帶來的具體優勢，并逐步適應這種新模式。因此，使用云來加速開發測試也正離國內開發者越來越近，并將會被廣泛接受。

傳統開發、測試中的挑戰

在軟件開發、測試中，一般需要經過開發、測試，驗收和上線四個階段，同時也對應有四個環境：開發環境，測試環境，驗收環境和生產環境，即所謂的DTAP。整個流程如下所示：

在這樣一個復雜且冗長的流程中，需要不斷地涉及到環境的準備以及應用程序的部署。而且涉及人員也非常多，包括開發、測試和運維。面對這些挑戰，傳統的軟件開發測試體系中普遍存在一系列問題：

獲取基礎設施(硬件、軟件和網絡等)非常困難，而且基礎設施的交付周期也非常長。由于采購基礎設施多為一次性投入，成本還非常大，企業在做這樣決定都非常謹慎。除非是已經被市場驗證的想法和產品，企業一般不太容易快速決定相關采購。即使決定采購，從下單到交付仍然是一個漫長的過程(常常以月為單位計算)。所以為了避免影響工程進度或者節省成本，經常會看到多位開發測試人員(甚至多個產品團隊)共用一套開發或者測試環境，然后就會出現為協調使用基礎設施而郵件漫天飛的場景。更為糟糕的是很多好的想法和構思因為冗長的基礎設置準備過程而錯失市場機遇，甚至直接就胎死腹中。

部署和維護各種開發及測試環境令人頭痛。當我們有了足夠的硬件資源來支持開發、測試后，另外一個問題又隨之而生。如何管理、部署這么多環境，如何讓這么多環境保持一致。例如，使用的Linux內核是不是一個版本嗎?都裝了統一版本的Python嗎?大家在不同的環境上是用一致的代碼做測試嗎?這樣的問題必然會影響到整個團隊的開發效率，最后非常有可能的結果就是大家還是會回到只用一個公共開發測試環境(這樣又開始重新相互影響)，亦或土豪公司會再招個專職的人員來維護這些環境(于是，這個人會成為新的單點，他/她一不在場時大家都傻眼了)。除了開發、測試環境之間的一致性維護工作外，保持開發及測試環境和生產環境的一致同樣具有挑戰。因為某個配置的不一致導致測試通過的代碼在生產環境不工作是常有的事情。因為某個新功能需要升級第三方依賴庫，在測試環境做了升級而生產環境卻忘了也隔三差五的來一次。于是窮盡各種細節的環境描述，部署文檔便塞滿了公司內部的Wiki或者某個文檔管理平臺。當然，這些文檔基本上是在完成的那一刻就已經過時，讓后來的閱讀者只會越看越糊涂。

開發及測試環境無法完全復現生產環境的場景。在實際運營中，生產環境總是承受最嚴酷的考驗(大流量的請求，頻繁的攻擊等)。但是，由于成本和意識上的一些問題，大家在開發及測試環境中很難復現這些場景并進行預先的測試。而且很多問題(尤其是在分布式系統中)都是在規模到達一定程度后才會出現，通常開發及測試環境都很難模擬出生產環境的規模。

人為的割裂IT、開發、測試和運維部門也是在傳統軟件開發、測試體系中經常碰到的問題。這個直接導致流程的冗長和信息溝通的不暢，尤其是在系統非常復雜時，需要讓各個不同部門之間的人能對整個系統有一致理解是非常不容易的事情。

由于上面這些普遍存在的問題，軟件開發人員的生產效率受到極大影響。當然，人們也在思想層面和實踐層面不斷改進這個流程，其中最近幾年盛行的DevOps思想得到了廣泛的認同。個人認為DevOps思想中最關鍵的點在于打破傳統軟件開發過程中的人為割裂和“殘酷無情”的推動自動化流程。前者意味著用統一的方式管理整個DATP流程和環境，而后者則是通過可復用的自動化工具和腳本把整個流程和環境部署、維護的知識固化下來，變成可直接操作的行動。

云計算帶來了新可能

由于前面所述的各種挑戰和問題，以及DevOps思想的廣泛認同，越來越多的公司開始行動起來改進既有的開發、測試流程，各種打著DevOps標簽的輔助工具也涌現出來。但是工程人員在獲取基礎設施方面的效率仍然無法令人滿意(這個問題尤其在創業公司和中小企業里面更為明顯)。幸好，云計算(尤其是公有IaaS云)的到來極大地改變了這個現狀。具體體現在下面幾個方面：

云計算提供了近乎無限量的基礎設施資源，而且你在任何時候都可以立馬獲得。筆者就親自經歷過一個下午啟動2000臺云主機進行測試的真實場景。有多少公司可以一次批準采購2000臺機器的預算，而且之前讓一個下午就立馬到位這么多服務器也基本是不可能的。另外，你獲取這些基礎設施資源的過程是完全“自助”式的，不需要依賴任何專門的IT或者網絡工程師。

云計算提供了全新的基礎設施資源成本模式，從原來的一次購買變成了按需付費。你只需要為自己具體使用的基礎設施資源量付費。在云計算時代，1000臺機器計算1個小時和讓1臺機器運行1000個小時的成本竟然是相等的。

云計算讓基礎設施資源“可編程”。在傳統IT時代，基礎設施資源總是顯得冰冷、生硬，程序員拿它無可奈何。你要組建一個虛擬網絡或者獲取個公網IP都得走申請流程，找運維人員。而且，絕大部分公司為了簡化管理成本或者安全考量，還會對基礎設施的使用制定一堆或合理，或不合理的規則制度，這都極大地限制了程序員的手腳。在云時代，絕大部分的公有或者私有IaaS云提供商都支持API(還沒有提供API的也都在加班加點的準備API中)。程序員可以非常靈活的調用這些API，使用標準的基礎設施單元構建自己應用的基礎設施架構。

在解決了軟件開發人員獲取基礎設施資源困難的同時，云計算還帶來了大量額外的好處。目前，主流的公有IaaS云服務商在提供基礎設施云服務的同時，還會提供如數據庫服務，監控服務，隊列服務，通知服務等一系列常見組件。這些服務同樣即插即用，按需付費。而且這些云服務都是由一流工程師開發，富有經驗的人員運維，經過了嚴酷的實際生產環境考驗。開發人員完全可以信任他們。

云時代的開發和測試

前面討論了DevOps思想和IaaS平臺各自的優勢，而這兩者恰恰又是可以很好結合來達到更好的效果。尤其是在幫助開發人員加速軟件開發測試效率，縮短交付周期上非常有用。這種加速主要體現在下面幾個方面：

1.利用IaaS平臺加速開發和測試人員獲取基礎設施的效率。在云時代，開發和測試人員可以在分鐘級別、以非常低的成本獲得想要的基礎設施，而且這些基礎設施還不需你投入人力、財力來維護。同時，由于基礎設施獲取的便捷性和低成本，它讓原來受限于基礎設施而無法并行的事情現在得以完全并行展開。例如，每個開發人員都可以獲得一個和生產環境完全一致的基礎設施并行開發，開發和測試的工作也可以并行推進，各種不同想法也能并行得到快速驗證。

2.利用DevOps思想和可編程的IaaS資源融合軟件開發的各個階段，打破原來存在的人為割裂，加速整個流程的迭代速度。如前面所述，軟件開發過程中一般包括開發、測試、驗收和生產幾個階段，每個階段都可以有自己獨立的運行環境，而且每個階段甚至是由各自獨立的人員來負責。在云時代，所有的基礎設施和應用程序的運行環境都可以通過自動化流程一體化管理，且所有的部署、交付工作都是自動化完成。因為是一體化管理，各個環境的不一致性就能得到很好的控制，可以極大地避免因為環境問題導致的開發流程受阻。如此同時，開發人員可以利用IaaS公有云提供的大量低成本資源更容易地在開發、測試和驗收環境中模擬出更多原來只能在生產環境中才能出現的場景，如大規模的流量壓力，大量用戶同時在線等。這樣可以更早發現系統的性能瓶頸，設計和實現的缺陷。

3.通過直接使用大量的通用云服務來減少工作量，加速軟件上線周期。毫無疑問，通過直接復用IaaS服務商提供的如數據庫服務，監控服務等也大大加速了開發和測試流程。當然，要想在開發和測試中利用好這些通用云服務，你最好要把自己的開發測試體系和云緊密聯系起來。

由于上面的這些明顯的優勢，越來越多的開發團隊已經開始用IaaS加DevOps的方式改進自己的開發測試體系。為了讓開發人員更容易地使用IaaS云服務支撐云環境下的開發測試，大量基于IaaS的DevOps工具也都把提升軟件開發及測試效率作為一個重要的設計目標。

【文章來源：FIT2CLOUD微信號】