測試環境、正式環境與部署白話指南：多環境怎麼運作、業主要確認什麼
和開發團隊開會時，常會聽到這幾句話：「這版先推到測試機」「正式環境還沒部署」「我們先回滾看看」。多數業主聽得懂字面，卻不確定這些動作實際上在做什麼、什麼時候該由自己拍板。
環境與部署聽起來是工程內部的事，但它直接關係到上線會不會出事、出事之後能不能救回來。這兩件事都是業主要承擔後果的，因此值得花時間弄懂基本邏輯。
這篇不談技術細節，只講你在專案裡需要判斷與確認的部分。會提到的環境有三種主要的——開發、測試、正式——以及部分專案會額外加的一種預備環境。
為什麼一套系統需要多個環境
所謂「環境」，指的是一整套能讓系統跑起來的配置：程式碼、資料庫、伺服器設定、對外串接的服務。同一份程式碼放在不同環境，連到的資料庫和外部服務是不同的。
多數專案至少會有兩個，常見的是三個：
- 開發環境：工程師自己電腦或共用的開發主機，改東西最頻繁，隨時可能是壞的，這很正常。
- 測試環境：功能做完後放上來驗收的地方，資料是假的，操作再怎麼錯都不影響真實客戶。業主的驗收主要在這裡進行。
- 正式環境：真實使用者在用的那一套，資料是真的，金流是真的，錯誤是會被客訴的。
分開的理由只有一個：讓錯誤在還不會造成損害的地方被發現。若只有一套環境，任何修改都是在真實資料上動刀，測試與營運混在一起，遲早出事。
在這三種之外，有些專案還會多一個「預備環境」（開發方常直接說 staging，你在會議上聽到的就是這個字），設定盡量比照正式，用來做上線前的最後彩排。它是選配而非必要，但系統複雜或整合對象多的時候特別值得投資，因為很多問題只有在設定接近真實時才會冒出來。
部署到底在做什麼
部署可以理解成「把新版本的程式送到某個環境並讓它生效」。實際上通常包含幾個步驟：把程式碼打包、放到伺服器上、更新資料庫結構、清掉舊的暫存、重新啟動服務、確認一切正常。
有幾個觀念對業主特別重要。
部署不等於改檔案。 成熟的做法是整個流程自動化：每次都執行同一套步驟，不靠人工記憶。這樣不論誰執行、執行幾次，結果都一致，也能留下紀錄。反過來說，若部署是靠人工把檔案一個個拉上去、沒有固定腳本也沒有紀錄，代表這個過程難以重現、也難以還原，值得提出來討論——判準在流程有沒有被固定下來，而不在用的是哪一種工具。
部署到測試環境和正式環境應該用同一套流程。 兩者流程若不同，測試環境驗過的結果就不能代表正式環境會正常——這是上線當天出意外的常見來源。
資料庫的改動要特別小心。 程式可以換掉再換回來，資料表結構改了卻不一定能輕易還原，資料一旦被覆蓋更可能救不回。涉及資料結構調整的部署，事前備份與還原步驟必須先確認。
版本與回滾：出事時的退路
版本是指每次部署出去的那一份程式碼的明確標記。有清楚的版本，才能回答「客訴發生時線上跑的是哪一版」「這個問題是哪次改動帶進來的」。
回滾則是把線上版本換回前一個已知正常的版本。它是上線時最重要的保險：不需要當場找出問題原因，先讓服務恢復正常，再慢慢查。
要讓回滾真的可行，有三個前提：
- 舊版本留得住：前幾個版本要保留，不能一部署就覆蓋。
- 資料庫改動要可逆或向下相容：如果新版把欄位刪了，回滾後舊程式就找不到資料。實務上會盡量採用「先加不刪」的方式，等新版穩定一段時間後再清理。
- 有人演練過：沒有實際做過的回滾等於不存在。上線前至少在測試環境走一次。
設想一個情境：改版當晚上線後發現結帳流程有問題。有回滾機制的團隊很快就把服務切回舊版，客人照常下單，隔天再從容修正；沒有的團隊只能在深夜邊修邊測，壓力下更容易改出新的問題。
業主在部署流程裡要確認的事
你不需要看懂指令，但下面這些答案應該拿得到：
- 這次要上什麼：這個版本包含哪些改動、哪些是使用者看得見的。
- 什麼時候上：時段是否避開營業尖峰，需不需要對外公告。
- 會不會中斷服務：預計中斷多久，中斷期間使用者會看到什麼畫面。
- 誰負責執行、誰負責確認：部署完成後由誰去實際點一遍關鍵流程。
- 失敗怎麼辦：判定失敗的標準是什麼、多久之內可以還原、由誰決定要不要還原。
- 資料有沒有先備份：涉及資料庫改動時，這一項不能省。
把這幾題變成上線前的固定問答，可以避免大多數混亂。更完整的上線項目可以對照網站上線前檢查清單。
驗收要在哪個環境進行
驗收原則上在測試環境進行，而且要用「盡量接近真實」的條件：完整走完一次流程，而不是只看單一畫面對不對。
需要特別留意的是測試環境常見的替代設定。金流通常接測試模式、簡訊與電子郵件可能被攔下不真的寄出、外部系統可能用模擬回應代替。這些設定是必要的，但也代表有些問題只有在正式環境才會浮現。因此上線後的第一件事，永遠是在正式環境實際做一筆完整的測試交易並確認結果。
驗收的紀錄方式、缺陷怎麼分級、哪些必須修好才能上線，建議在專案初期就講定，做法可以參考軟體驗收怎麼做。
環境設定與機密資料怎麼管
同一份程式碼在不同環境要連到不同的資料庫、不同的金流帳號，這些差異靠「環境設定」處理，通常包含連線資訊、各種服務的金鑰與密碼。
業主要注意三件事：
金鑰不該寫在程式碼裡。 寫進程式碼等於任何看得到原始碼的人都拿得到，換人時也難以撤換。正確做法是放在環境設定中管理。
正式環境的權限要收斂。 能碰正式環境的人愈少愈好，並且要能對應到具體的人，而不是全公司共用一組帳號。
交接時要一併移交。 專案結束時，正式環境的存取權、各項服務的帳號歸屬、設定清單都要移交給你，而不是留在開發方手上。這一點屬於維護與交接條款的範圍，可以對照網站維護費用包含什麼裡的交接說明。
常見的三個錯誤做法
一、只有一套環境。 為了省事直接在正式環境改，短期看起來快，第一次出事就會把省下的時間全部還回去。
二、測試環境長期失修。 資料過期、設定與正式環境差太多、串接對象早就換了，導致在上面驗過的結果不具參考價值。測試環境需要被當成正式資產維護。
三、上線當天才第一次跑完整流程。 部署流程、回滾步驟、通知對象都應該事先演練過。上線當天要處理的是意外，不是第一次操作。
想進一步了解自動化測試在這個流程裡的位置，可以看自動化測試是什麼。
給非技術主管的三句話
環境與部署講的其實是同一件事：讓改動可控。你不需要參與執行，但可以把下面三句話直接拿去問，而且每一句都有可以驗證的回答方式。
「這個改動在哪個環境驗過？我可以自己點一遍嗎？」 對方應該給得出測試環境的網址與一組測試帳號。若回答是「我們在本機看過沒問題」，代表你沒有機會親自驗收。
「測試環境和正式環境的部署，是不是同一套流程？」 答案要是同一套，而且能說出這套流程留下了什麼紀錄（誰在什麼時間上了哪一版）。兩邊流程不同，就等於測試結果不能代表正式環境。
「這次失敗的判定標準是什麼？多久能還原、誰決定？」 要拿到的是一個時間長度、一個具體的人，以及「上一次演練是什麼時候」。三個都答得出來，上線就從賭運氣變成例行作業。
若你手上的系統目前只有一套環境、上線流程仍靠人工記憶，把現況講一遍會比先問價格有用：和 NETVANA 聊聊你的專案。軟體服務沒有固定套餐，我們逐案了解現況、確認風險落在哪裡之後才提出調整順序與報價；軟體服務介紹裡列了各項服務的內容與交付物。
延伸閱讀：主機形式會直接影響部署與擴充方式，先看網站主機怎麼選；正式環境的防護與事故處理邊界，看企業網站資安基本功；上線時程一再延後的根因，看軟體專案為什麼總是延誤；切換網域或搬主機時會碰到的設定，看網域與 DNS 白話指南。
