開發環境蔓延
Development --> Staging --> Production一個非常典型的工作流程。這可以。
“好吧，你想要一個‘測試版’環境來向一些尚未準備好迎接黃金時段的使用者/客戶展示一些東西。”
Development --> Staging --> Beta \-> Prod“‘預生產’是什麼意思？這就是 Staging 的用途。”
我見過一些（少數！）可能需要更多的案例，例如必須進行複雜測試的經過嚴格審核的行業，但即使它們似乎也失控了。（我曾經在一個有 11 個獨立環境的地方工作過！）
還有其他人看到這個環境蔓延嗎？我們如何管理認為這些“重要”的開發人員（和管理層）？
甚至我關於增加成本和復雜性的請求似乎也被忽略了，感覺其中一些原因是懶惰。超過 4-5 個環境，我的蜘蛛俠感覺開始刺痛……
跳出這個典型的工作流程有很多正當的理由。我們沒有像@CamelBlues 建議的那樣的 QA 環境，畢竟所有程式碼在被標記為完整併準備好進入暫存之前都應該是 QA。我們在開發時使用 QA，因此不需要 QA 環境。
無論哪種方式，對程式碼的重大更改，例如 UI 替換或導致需要額外開發分支的事情，通常也需要與主要開發環境不同的測試和階段。
例如，如果我要替換我的 UI 並將我的應用程序移植到一個新的 MVC 系統，我可能會在原始碼控制儲存庫中創建一個新分支來完成此操作。但是，我不能同時執行我的舊程式碼和新的 MVC 程式碼，因此我們需要一個新環境來託管該分支，直到它完成。特別是如果您仍然需要在此過程中修復錯誤。
請記住……這正是虛擬機的用途。出於開發和測試目的，您甚至可以從 Microsoft（如果那是您的平台）獲得 60-90 試用許可證。請求多少環境（在合理範圍內並與您的團隊規模相比）真的無關緊要，因為您應該有一個平台可以輕鬆快速地啟動機器，這就是大多數大型開發商店的運作方式，實際上允許開發人員和測試人員檢查-out 要使用的虛擬機。
**更新：**剛剛檢查了我們的環境，我們也進行了預生產。發布和部署團隊使用它來測試說明和修復，以便在實際接觸生產箱之前進行試執行。給他們一個緩衝。