舊系統不敢動：先建立可回滾變更流程

問題

• 修改靠 FTP 上傳：改了什麼、誰改的、何時改的，無法回溯。
• 沒有測試環境：每次改動直接上正式，風險集中在「一刀下去」。
• 出事只能手動救火：沒有固定回滾步驟，回復速度取決於記憶與運氣。

判斷

• 真正風險不是程式碼，而是缺少可回滾路徑與可驗證流程。
• 先把變更拆小：把「會中斷的改動」與「可安全迭代的改動」分開。
• 任何優化都必須有：版本標記 → 發佈方式 → 回滾方式 → 驗證項目。

方案

• 版本控管化：就算是舊系統，也先建立 Git 倉庫與 tag（每次上線打一個版本點）。
• 最小測試環境：不追求完整複製，只要能跑關鍵流程（登入、下單、查詢、管理）。
• 變更單規格：每次改動都寫「摘要 / 影響範圍 / 風險 / 回滾方式 / 驗證項」。
• 回滾腳本與備份點：部署前先做 DB 備份點，必要時一鍵回復到版本點。

交付

• 可回滾部署流程：上線步驟 + 回滾步驟 + 驗證清單。
• 版本節奏：命名規則、tag 規則、每次上線的變更紀錄。
• 風險分級：哪些可即時修、哪些必須排程窗口與預告。