淺談測試環境治理在Devops中的應用

• 2019 年 10 月 4 日
• 筆記

近年來Devops可以說是比較火的概念，幾乎一夜之間全部大公司都在談Devops，談CI/CD流水線，談效能提升；如果哪個公司沒有實施Devops實踐，那麼肯定會在心裡被鄙視到！

其實Devops之所以能火起來，還是因為現在的互聯網公司迫於競爭的壓力，想要能夠先於競爭對手、市場發布自己的產品或需求。而剩下的一部分公司則可能是跟隨主流，且不想在前沿的技術實踐上太過落後，才實踐的Devops。

不管Devops是因為什麼原因火起來，終歸它還是一個好的實踐，可以給團隊和公司帶來研發流程和效率上的提升。而今天我們就來說說測試環境治理在Devops中的幾種應用方式。

測試環境治理

測試環境治理是軟體測試過程中對被測對象軟體環境的管理和調度的總稱。簡而言之，就是在測試過程中提供簡單、方便、高效的軟體測試環境的手段。

為什麼測試環境治理跟Devops能扯上關係呢？因為Devops的環節中其中必不可少的就是自動化測試，而自動化測試自然就要涉及到自動化測試環境的搭建和維護，因此就需要有一個針對性的解決方案 — 測試環境治理。

其實對測試環境的管理和維護，是要更早於Devops實踐；但是對測試環境的關注和投入，卻是因為Devops才被放大的。所以才有了多種形式的測試環境治理方案。

基於物理機/VM的環境編排

在這種情況下並沒有真正的使用到虛擬化技術，因為這裡的物理機和VM都是提前搭建好的固定作業系統，不是那種可以動態創建和還原的虛擬機鏡像。因此可以直接認為是在固定的物理環境中搭建和管理測試環境。

對於這種實際情況，最簡單的實現方式就是通過Jenkins來配置每一個模組，直到把所有的模組都配置完成，這樣一套完整的測試環境就可以在Jenkins中被管理起來，任意一個模組有更新時，直接觸發該模組對應Jenkins部署任務就可以了。

優點：可以基於開源的框架直接上手，管理方式簡單清晰

缺點：同時管理全套的所有模組則不夠靈活，每一個分支都需要單獨寫一套搭建的流程

除了上面的jenkins的方式，還有一種就是開發環境搭建的編排工具。同樣的它會負責每一個模組的具體搭建工作，另外它還可以統一管理一套環境中的所有模組。並且提供各模組間的依賴搭建編排功能，甚至可以提供模組狀態的監控功能。

優點：統一管理一套環境，提供編排、監控、並發能力

缺點：需要一定的開發工作量

基於openstack/KVM的虛擬化編排

選用第一種方式來管理測試環境，通常是因為迫於現狀才選擇的。如果公司的運維能力相對比較好點，那麼你們可能已經使用上了openstack等雲平台基礎架構，並能夠提供動態創建虛擬機的服務。

對於這種實際情況，對於測試環境的治理就相對的容易點了，因為你可以把所有模組的基礎環境都做成鏡像，每次部署模組時可以通過基礎鏡像來新建或者恢復一個虛擬機，然後再部署好最新的模組即可。

優點：能夠提供非常乾淨的基礎搭建環境

缺點：需要一定的運維基礎能力支援（公司需要有搭建私有雲的技術能力）

基於docker的容器化編排

如果公司的運維能力再進一步，你們可能已經使用上容器化技術了。那麼恭喜你！在測試環境治理的路上，你又可以更進一步了！通過docker的容器化技術，不僅可以實現基礎環境的還原，而且是快速的。

對於這種情況，如果配合K8S使用，那麼還可以同時擁有全套環境統一管理，編排和監控能力。配置完成一套環境後，可以快速搭建一套一模一樣的基礎環境。

優點：能夠快速搭建全套環境，同時提供編排、監控能力

缺點：需要運維的支援、需要k8s、docker的實踐經驗

基於服務虛擬化的環境治理

上面提到的3種測試環境治理方案，雖然都能夠管理一套環境的搭建，甚至可以快速的複製另一套測試環境。但還是不能覆蓋實際工作中的主要場景需求。

比如：開發者A因為開發模組A需要聯調，他可能需要一套環境來自測；同樣的開發者B、C都會有同樣的需求，甚至測試A，產品D都需要一套特定的測試環境來進行測試或者驗收。

值得注意的是，上述場景並不是假設的，而是真實存在的；尤其是對於功能模組比較龐大的被測對象。比如：現在比較流程的微服務架構，動輒成百上千的服務模組；想搭建一套完整的服務實屬不易，況且還要有空餘的機器支援！

所以說上面的3種解決方案，最多只能解決單套測試環境的問題，而不能解決多套測試環境並行的問題。對於這種情況就需要使用服務虛擬化技術來解決了。

所謂的服務虛擬化，是相對於容器技術的進程虛擬化而言。即指的是對服務進行隔離和互通的一種技術實現方式。

服務虛擬化的概念是阿里提出的，但是類似的技術方案在其它公司也有實現，且具體技術方案也不一樣，但是其基礎的思想都是一致的。下面就來介紹下服務虛擬化的測試環境治理方案。

服務虛擬化的前提是，保證已經擁有了一套基礎版本的全套模組服務，這裡暫且稱之為base環境。base環境通常是與線上版本保持一致的線下全套服務環境。

有了base環境之後，理想狀態下如果其中一個模組被修改了，直接用該模組的測試版本替換掉原來的base版本，就可以擁有一套完整的測試環境了。但這裡仍然會有幾個問題：

1.替換測試模組的方式會破壞原來的base環境2.不能同時支援多個模組並發替換和測試

所以服務虛擬化的概念就有了，如何才能實現不同服務間的隔離和共享，來達到環境服務的虛擬化。下面來看一張服務虛擬化的圖示。

上圖中假設一套環境只有ABC3個模組組成，而上面5個模組卻已經擁有了3套環境：一套base環境（ABC），2套虛擬環境（A'BC，ABC'）。依據上面的假設可以推理出，服務虛擬化可以提供任意的一個或多個模組的動態替換，快速的組建起一套基於base環境的虛擬環境。

該方案可以說是環境治理的終極方案，但是它的實現依賴於2個關鍵技術點：

•一是如何實現動態替換base環境中的模組，且不影響其它虛擬環境使用該base模組•二是如何去識別被處理的請求的意圖，即請求本身希望被測試模組處理還是被base模組處理