Staging 環境（staging environment）是系統正式環境（production）的複本，用來在改動上線前先作檢查。新功能、錯誤修正、內容和設定改動會先部署到 staging，讓團隊和企業在接近真實的條件下查看效果。有問題能及早發現，不必等客戶遇上。
開發環境、staging 與正式環境
不少軟件項目最少有三個環境。各團隊的叫法未必相同，但角色大致如下：
- 開發環境：開發人員編寫和試驗改動的地方，可以是個人電腦或共用的開發伺服器，經常變動，功能亦未必完整。
- Staging 環境：另行設置、盡量貼近正式環境的複本，準備發佈的改動先在這裏檢查才上線。
- 正式環境：客戶和員工實際使用的系統，涉及真實資料、真實付款和真實訊息。
Staging 環境有甚麼用途
- UAT 及簽收：業務用戶可以用測試帳戶在 staging 進行用戶驗收測試，不會影響正式記錄。
- 回歸測試：每次發佈前，團隊以人手或自動化腳本確認原有功能仍然正常，詳見回歸測試解說。
- 付款及系統整合檢查：支付閘道及不少外部服務都提供測試或 sandbox 模式。連接後便可試行預約、付款等完整流程，不會真正收費。
- 內容預覽：編輯可以在發佈前檢查新頁面、版面或推廣內容。
好用的 staging 環境要具備甚麼條件
- 設定貼近正式環境：在可行範圍內使用相同的軟件版本、設定和主要組件。兩者差異愈大，測試通過的參考價值便愈低。
- 資料及登入憑證分開：有獨立的資料庫、帳戶、密碼和 API 金鑰，即使在 staging 出錯，也不會改動正式資料。
- 使用測試付款及 sandbox 金鑰：付款、電郵和短訊連接都指向測試或 sandbox 帳戶，而不是正式帳戶。
- 不對外公開：以登入或 IP 白名單等方式限制存取，並設定搜尋引擎不要收錄。
- 部署流程與正式環境相同：兩個環境採用同一部署方式，確保檢查過的版本就是上線的版本。
常見陷阱
- 與正式環境逐漸脫節：其中一方的設定、軟件版本或資料結構改了，另一方沒有跟上，結果測試通過，上線後卻出錯。
- 隨意複製真實客戶資料：把正式資料庫複製到 staging，可能令更多人和系統接觸到個人資料。應盡量使用樣本或經匿名處理的資料。
- 真的發出電郵、短訊或付款：如果 staging 仍連接正式服務，一次測試便可能向真實客戶發出訊息或產生真實收費。每一個對外連接都要檢查。
- 忘記阻止搜尋引擎收錄：staging 網站一旦被收錄，便可能在搜尋結果中出現，顯示測試內容和重複頁面。
以下示例僅供說明：一間診所的預約網站要加入網上訂金功能。開發商先把改動部署到 staging，並連接支付服務供應商的 sandbox。前台同事進行測試預約、以測試信用卡資料付款，並確認電郵只會發到內部測試地址。流程通過驗收後，同一版本才部署到使用正式付款設定的正式環境。
可向開發商查詢甚麼
小型企業不必自行管理 staging，但值得向開發商了解：
- 系統有沒有 staging 環境？誰可以存取？
- 它與正式環境有多接近？如何保持一致？
- 它使用甚麼資料？會否複製真實客戶資料？
- Staging 上的付款、電郵和短訊是否連接測試或 sandbox 服務？
- 它是否已限制公眾存取，並阻止搜尋引擎收錄？
- 每次發佈是否都先在 staging 檢查？報價或支援安排是否已包括這部分？
上線後，網站監察負責留意正式系統的狀況，而軟件支援 SLA 可能會列明改動如何測試和發佈。如需了解服務範圍，可參閱 technine.io 的網站及 Web App 開發服務，當中包括 UAT 及上線驗證。
常見問題
小型網站需要 staging 環境嗎？
視乎網站改動的頻率和用途。簡單的資訊網站可能只需要內容預覽；設有預約、付款、登入或系統整合的網站，一般較適合設置 staging，因為這些功能出錯會直接影響客戶。
Staging 環境等同測試環境嗎？
不一定。有些團隊把兩個名稱交替使用；有些則另設供開發及 QA 使用的測試環境，再以貼近正式環境的 staging 進行最後檢查和 UAT。可向開發商了解每個環境的用途。
可以把正式資料複製到 staging 作測試嗎？
有時確實需要接近真實的資料，但複製真實客戶記錄會帶來私隱和保安責任。應優先使用樣本或經匿名處理的資料，並限制可存取的人員；如涉及個人資料，請向顧問確認相關責任。