準備好走快速上線流程

草稿準備好了，快速發布才有意義。先用編輯器自動算出來的清單，把可以預料的上線失誤清掉。

1. 打開上線指南，把它針對這個專案列出的商家資料、營業時間、真實相片、內容、SEO、按鈕去處和手機預覽逐項完成。
2. 打開預覽，在 Desktop 和 Mobile 測店面。草稿裡有營運模組時，後台也要測——完整交付會把後台一起發布出去，你在這裡驗過的，就是店裡的人之後每天在用的。
3. 需要別人核准草稿或回饋意見時，就用審查。
4. 等狀態顯示已存檔，再打開上線。

在瀏覽器版裡，發布是由伺服器控管的工作區能力。服務商的金鑰只該放在伺服器上，絕對不要貼到頁面內容或瀏覽器儲存空間裡。

1. 在編輯器上方工具列按「上線」。
2. 畫面顯示無法發布、沒有權限或尚未設定時，就停下來，請工作區擁有者去開通。
3. 不要拿匯出當部署。匯出是可攜帶的檔案，不是伺服器確認過的線上網站。
4. 確認選到的專案。要等不可變更的發布版本通過上架檢查，Naratake 才會給出正式的系統網址；瀏覽器不會自己編一個服務商子網域出來。

Naratake 產生的是一套完整的 Next.js 應用程式，背後有資料庫；訂單、訂位、預約、顧客這些主要營運模組，都要靠那個資料庫跑起來。雲端發布對這套應用有兩種交付。完整交付會為網站開一套自己的 Postgres 資料庫和後台，那些模組會真的上線，顧客留下的紀錄也存得下來。純店面交付是同一個網站拿掉寫入面，拿掉了哪些會逐條列在發布報告裡。一個工作區能請求哪一種，是送出請求時由伺服器決定的，不是瀏覽器說了算：完整交付需要方案同時包含商務和預約模組，目前就是 Storefront Pro。至於網站本身會有哪些東西，一樣是依照存檔後那一版實際會交付的元件和模組算出來的，不是看範本名稱。

1. 看清楚上線畫面說這次要交付什麼：是帶自己的資料庫和後台的網站，還是同一個網站的純店面版本。
2. 生意需要即時訂單、預約、顧客紀錄或需登入的後台時，就請求完整交付。方案裡沒有商務和預約模組的工作區，會在動到任何服務商之前先被擋下來，而且被擋的訊息會講明哪個方案有這項。
3. 不要為了早一點發布，就把生意需要的模組拿掉。要嘛把工作區換到包含完整交付的方案，要嘛就明明白白地決定先上純店面交付，在那之前把完整營運流程留在預覽裡測。
4. 方案沒有包含的交付方式，不要改用桌面版匯出、自己的服務商金鑰，或手動從瀏覽器上傳來頂替。

警告不一定會擋住部署，但它們講的是顧客看得到的問題。把它們當成一份需要簽字放行的清單。

1. 逐則打開警告，弄清楚受影響的是哪一頁、哪段內容、哪個模組或哪個環境設定。
2. 顧客看得到的問題先修：少了法律條文、還留著範例資料、按鈕點了沒反應、付款設定沒填完。
3. 如果某則警告是刻意接受的，送出上線前把是誰接受的、為什麼接受記下來。

部署要花時間，也可能做到一半才失敗。真正算數的是雲端服務回報的狀態，不是你按下去那一刻，也不是瀏覽器樂觀顯示的訊息。

1. 「上線」只按一次，進度回報期間讓專案一直開著。
2. 覺得建置很慢也不要一直重送。重試之前先重新整理部署狀態或發布紀錄。
3. 伺服器回報錯誤時，把請求或部署編號和完整訊息留下來，照它說的原因修好，再重試一次。
4. 模擬、演練、預覽或還在進行中的狀態，一律當成還沒上線。

最後這關要離開編輯器，直接對著回傳的公開網站和它真實的伺服器行為來檢查。

1. 用無痕視窗打開回傳的網址，檢查首頁、導覽列、法律連結，以及這一版真的有帶上的每一個行動按鈕。
2. 確認公開內容就是審過的那一版，而不是舊的預覽。
3. 只有這一版真的帶了訂單、訂位、預約或需登入的後台，才對外這樣說。完整交付有帶——到回傳的網站登入後台，確認測試紀錄真的進得來；純店面交付沒有，發布報告裡會列出它拿掉了哪些。
4. 分享出去之前，用手機打開線上網址看一次，並確認是 HTTPS。

存檔只是更新草稿，不會偷偷改到線上的網站。下一版審好了，再按一次上線。

1. 改完之後等顯示已存檔，再重跑一次預覽，以及各模組專屬的測試。
2. 動到線上模組的改動，部署前要當成會影響資料的決策來審。
3. 再按一次上線，並且像第一次發布那樣，把回傳的狀態和網址驗證一遍。
4. 新版還在驗證期間，讓上一個可用的發布版本保持可用。