測試過程中，一套合理的環境管理流程是發布過程中很重要的一環。如何在測試過程中讓環境為你服務而不是在環境維護過程投入過多人力，其實還是挺重要的乙個工作。
在現在網際網路模式下，微服務化架構盛行，毫不誇張的說，好的環境管理流程是事半功倍的。
一般的網際網路公司環境分為三套：
以上三種環境基本上都是網際網路公司的必備的開發測試流程中很重要的三套環境。其實這裡面有幾個坑點需要特別注意
1，測試環境是開發維護，所以測試人員在環境過程中一點沒有參與過程，對環境部署和系統架構一點無參與，直接導致測試無法參與到問題排查過程；
2，開發維護測試環境部署過程都會比較隨意，因此系統複雜之後，部署過程非常耗費時間。
1，測試環境的部署方案和線上不一致，導致測試環境在發布過程中，有可能出現因為環境依賴而導致的問題無法在測試環境復現；
2，測試環境的部署都是測試進行，測試在過程中成為瓶頸；
1，開發和測試都對環境過程不介入，導致環境導致的問題調查成本高
2，同坑點一，測試角色介入度太淺
按照上面來說，看起來開發、測試、運維三個角色好像都不合適對測試環境進行管理，那怎麼是乙個合適的方案呢？
我認為合適的方案要有如下要素：
1，測試維護測試環境的部署指令碼
,2，環境部署指令碼模板運維統一提供，保障線上、預發、測試三套環境的模板只是配置項不同，其他依賴環境的版本等均一致
3，測試環境的管理可以通過一套工具平台來進行統一的部署
所以，其實對於測試環境的管理來看，合理的方案是要有一套可標準化的管理工具、部署模板。
測試環境為了方便部署，一般在專案部署過程中一般有如下幾種方案：
這種部署方案一般適用於小型專案團隊快速開發，且並行度不高的情況，因為部署應用的數量和深度都不高，所以通過jenkins等定義好部署指令碼，隨時使用新agent就可以快速重新部署一套環境。
但是，如果環境複雜度增高之後，這種成套的部署方案會出現如下幾個問題點：
此時，我們需要尋求解決方案：
測試環境部署方案二： 一套統一的標準環境，所有其他專案環境都依賴標準環境進行測試
以上這種方案通過增加標準環境解決了環境依賴的問題，也是基本上網際網路公司使用的標準化測試環境的方案。不過，這裡面還是有一些問題點存在：
如上，為了解決這兩個問題，整個針對環境管理需要兩個新的工具平台來承載。好在一般的發展到一定規模的公司，開發這兩個平台的實力還是有的。
但是時間長了，第三個問題就會越來越痛，以至於隨著測試團隊規模的增加，我們需要出乙個子團隊（1~2個人）長期對環境進行管理維護，隨時應對各種環境問題導致的部署失敗和衝突問題。苦不堪言~
因此測試環境在近幾年進入第三套部署探索方式
測試環境部署方案三： 基於docker的標準化測試環境部署方案
docker的引入，讓環境的標準化問題解決了，環境的維護成本會減少，但這個方案是不是最後的方案了，其實我認為也不是因為其實docker解決了環境問題，又引入了幾個新問題：
其實環境隨著一步步的解決問題，技術的複雜度是越來越高了。有時候其實考慮如果完全docker生成一套隔離環境，可能會是更好的方案，在不計成本的情況下完全拋棄測試標準環境。
所以測試環境管理和維護這條路，其實是隨著解決的問題深入，需要有很深入的思考和解決問題能力的，而且對技術的要求也越來越高。
今天就先寫這兩個點的環境問題，其實對於測試環境來說，如何和持續整合更好的互動、配置中心、環境監控、日誌收集等等都會是可以深入討論的問題點。
但，考慮到此賬號會持續更新，因此關於測試環境就先寫這一篇，以上提到的問題，待以後再逐一深入分析下。
Windows測試環境管理系統
一 測試環境管理中心需求 客戶端測試環境的管理是以虛擬機器為基礎的，虛擬機器比較靈活，且可以通過快照來儲存測試環境 客戶端測試環境管理中心是在下面需求背景基礎上產生的 虛擬機器效能 vmvare workstation 效能比較差，影響使用 資源管理 虛擬機器資源需要統一排程，避免多人互踢，提高使用...
anaconda 環境管理
檢視當前系統的anaconda環境 conda info e 新建乙個 conda 環境 tensorflow conda create n tensorflow pip python 3.5 啟用環境 mac source activate tensorflow 退出環境 mac source d...
Anaconda Python環境管理
不同的實驗，開發不同的專案，會用到python不同的版本 大量的包，anaconda很好的解決了python的版本 包使用混亂的問題。anaconda基礎環境中包含了大量的依賴包，庫函式，並且可以根據專案或者實驗需求，方便的建立乙個或多個需要的虛擬編譯環境，用起來方便快捷且實用。在環境建立好之後，執...