Cloudways Staging Push 教學：檔案、資料庫與避免覆蓋訂單

測試站完成後，Push to Live 才會把變更帶回正式網站。風險在於選錯檔案模式、資料庫範圍，或把測試站舊資料覆蓋最新訂單。以下流程適合 WordPress、GreenShift 及 WooCommerce。

步驟 1：確認測試完成後才開啟 Push

在 Staging Management 按 Push to Live 前，先完成版面、外掛、表單、登入及手機顯示測試。選擇低流量時段，通知團隊暫停正式站編輯，並確認已建立正式站備份。Push 是會改動正式資料的操作，不要把它當成單純發佈按鈕。

步驟 2：選擇 Web Files 的 Incremental 或 Overwrite

Incremental 只推送新增及已修改檔案，通常較適合版面及外掛調整；Overwrite 會取代整個檔案範圍，可能覆蓋 `.htaccess`、設定檔及正式站新增檔案。若必須使用 Overwrite，先列出差異並確認正式站沒有獨有檔案。

步驟 3：選擇 Full DB 或 Selected Tables

Full DB 會以 Staging 資料庫覆蓋正式資料庫，適合沒有持續寫入資料的測試站。WooCommerce、會員或表單網站應優先選 Selected Tables，排除訂單、客戶、登入 session、購物車及其他正式站持續寫入的資料表。推送前逐一核對表名，不要只依賴自動選擇。

步驟 4：查看 What Will Happen 並建立正式站備份

展開 What Will Happen，查看將新增及更新的檔案、資料表及排除項目。確認 Backup live application 已啟用；這個備份是推送前的還原點。若預覽出現不應修改的檔案或表格，先取消並回到 Staging 修正選擇。

步驟 5：最後確認範圍後才 Proceed

再次核對 Staging、Live、檔案模式、資料庫範圍、排除訂單及備份狀態。Push 期間正式站可能短暫不可用，確認維護時段後才按 Proceed to push。不要分享密碼、網址、IP、訂單編號或後台截圖。

步驟 6：查看 Push History、清快取及驗證正式站

完成後查看 Push History 及 deployment log，確認狀態為 Success。清除 Breeze、Varnish 及 CDN 快取，再測試首頁、GreenShift 區塊、登入、表單、結帳及 HTTPS。Staging 通常仍可保留作下一輪測試；若正式站出錯，先使用推送前備份還原。

甚麼時候應使用 Overwrite？

只有在你已確認正式站不含需要保留的檔案，並且有可用備份時才考慮 Overwrite。單純更新 GreenShift 版面或外掛，通常先以 Incremental 減少覆蓋範圍。

為甚麼推送後訂單數量不對？

常見原因是把 Staging 舊資料庫以 Full DB 覆蓋正式站。WooCommerce 應在 Selected Tables 排除訂單、客戶、session 及結帳相關資料，並在低流量時段推送；完成後立即核對最新訂單及付款狀態。