準備好走快速上線流程

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

1. 打開上線指南，把它針對這個專案列出的商家資料、營業時間、真實相片、內容、SEO、按鈕去處和手機預覽逐項完成。
2. 打開預覽，在 Desktop 和 Mobile 測店面。草稿裡有營運模組時，後台也要測，即使目前的快速發布路徑還沒辦法部署那些需要資料庫的模組。
3. 需要別人核准草稿或回饋意見時，就用審查。
4. 等狀態顯示已存檔，再打開上線。

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

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

Naratake 產生的是一套完整的 Next.js 應用程式，背後有資料庫；訂單、付款、訂位、預約、顧客這些主要營運模組，都要靠那個資料庫跑起來。目前雲端上線先支援不需資料庫的店面網站，例如商品頁、評價和文章內容，因為託管的資料庫服務還沒接上。資格是依照存檔後實際會交付的元件和模組算出來的，不是看範本名稱；需要資料庫的專案，會在呼叫建置器、檔案儲存或代管服務商之前就停下來。

1. 確認上線畫面判定這次要交付的專案不需要資料庫，並且描述的是一次獨立的建置。
2. 如果專案需要即時訂單、預約、顧客紀錄、付款、需登入的後台，或其他要靠資料庫的模組，Naratake 判定不符合資格時就停下來。
3. 不要為了通過這道關卡就把生意需要的模組拿掉。在託管資料服務開通之前，繼續在預覽裡測完整的營運流程。
4. 雲端路徑被擋下來時，不要改用桌面版匯出、自己的服務商金鑰，或手動從瀏覽器上傳來頂替。

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

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

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

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

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

1. 用無痕視窗打開回傳的網址，檢查首頁、導覽列、法律連結，以及這一版真的有帶上的每一個行動按鈕。
2. 確認公開內容就是審過的那一版，而不是舊的預覽。
3. 不要說訂單、訂位、預約、付款或需登入的後台已經透過這條發布路徑上線，因為它目前還帶不了這些。
4. 分享出去之前，用手機打開線上網址看一次，並確認是 HTTPS。

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

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