點樣為你嘅應用程式設定 Staging 環境

要設定 staging 環境，將應用程式第二份副本部署到一個私人網址，俾佢獨立嘅資料庫同測試 API 金鑰，並盡量令佢同正式環境嘅設定一致。然後將每個重大改動先發布到 staging，跑過重要流程，確認 staging 冇問題之後，先發布到正式環境。

如果你未接觸過呢個概念，什麼是 staging 環境會解釋基本概念。本指南係實際設定方法，專為用 AI 工具建造應用程式嘅人而寫，唔係為營運 DevOps 團隊而寫。

開發、staging 同正式環境

大部分細型應用程式需要三個環境，即使第一個只係你嘅建造工具預覽：

Staging 嘅重點係佢表現得同正式環境一樣——相同嘅程式碼、相同嘅技術棧、相同類型嘅設定——但喺嗰度出錯唔會傷害任何人。

第一步：決定 staging 必須同正式環境一致嘅地方

Staging 只有喺問題能夠喺正式環境出現之前先喺嗰度出現時，先有用。以下各項都要一致：

• 相同嘅程式碼，並以相同方式發布。
• 相同嘅技術棧同版本——框架、執行環境、資料庫類型。
• 相同類型嘅設定——相同嘅環境變數名稱，但用測試值。
• 相同嘅服務——如果正式環境有網頁應用程式同 API，staging 就兩者都要有。

兩者可以喺規模（用較細嘅機器冇問題）同資料方面有所不同。

第二步：建立副本

最簡單嘅做法：將同一個項目再部署一次，放喺另一個網址，例如 staging.yourapp.com 或 yourapp-staging.example.com。

點樣做要視乎你嘅主機：

• 內置預覽或 staging 部署功能嘅主機，可以為 Git 分支自動建立一個。
• 冇呢個功能嘅主機：用同一份程式碼建立第二個應用程式或項目，然後分開部署。
• 程式碼放喺 Git：保留一個 staging 或 main 分支部署到 staging，並從發布版本部署到正式環境。請參閱點樣為 AI 建造嘅應用程式使用 Git。

第三步：俾 staging 獨立嘅資料庫

呢一步係保護你嘅關鍵。如果 staging 同正式環境共用一個資料庫，一個刪除紀錄嘅測試就會刪除真實紀錄。

• 為 staging 建立一個獨立嘅資料庫。
• 用種子資料填滿佢——即 AI 可以為你生成嘅、貌似真實嘅假紀錄。
• 如果你需要正式環境資料嘅副本，先移除或打亂姓名、電郵同任何個人資料。

寫一個種子腳本，將空白資料庫填入貼近真實嘅測試資料：20 位客戶、50 張處於唔同狀態嘅訂單，以及兩位管理員用戶。使用明顯係假嘅姓名，以及 example.com 電郵地址。

喺信任設定之前，確認每個副本連接嘅係邊個資料庫。直接問：

呢個應用程式連接緊邊個資料庫，而呢個設定來自邊度？顯示變數名稱俾我睇，唔好顯示密碼。

第四步：使用測試金鑰同獨立設定

Staging 入面，所有同外部服務溝通嘅項目都應該用測試憑證：

• 付款使用測試模式（例如 Stripe 測試金鑰），確保唔會真係扣款。
• 電郵發送到沙盒，或者只發送俾你自己嘅地址，確保客戶永遠唔會收到測試郵件。
• AI 同其他付費 API使用獨立金鑰，並設定低消費上限。
• Webhook 指向 staging 網址，而唔係正式環境。

兩個環境中，變數名稱要保持一致，只改變值。咁樣程式碼就唔需要知道自己運行喺邊度。想了解更多，可以睇點樣令 API 金鑰保持安全。

第五步：令 staging 保持私隱

Staging 唔應該公開：

• 將佢放喺登入、密碼，或者團隊電郵白名單之後。
• 用 noindex meta 標籤或 X-Robots-Tag 標頭，阻止搜尋引擎索引佢。
• 唔好喺你嘅公開網站連結去佢。
• 令佢睇落同正式環境唔同——例如一條有顏色嘅「STAGING」橫幅，可以防止你喺錯誤嘅分頁測試。

當 APP_ENV 環境變數為 "staging" 時，喺每一頁頂部加入一條鮮黃色橫幅，寫住「STAGING — 只限測試資料」。喺呢種情況下亦加入 noindex meta 標籤。

第六步：建立發布常規

Staging 只有當你每次都用嘅時候先有幫助。一個簡單嘅常規：

1. 喺開發環境作出改動，並喺預覽中檢查。
2. 發布到 staging。
3. 跑過你嘅關鍵流程：註冊、登入、主要功能、付款，以及任何受改動影響嘅嘢。
4. 如果有嘢壞咗，就修好並再次發布到 staging。
5. 將同一個版本發布到正式環境。
6. 快速檢查正式環境——同樣嘅流程，簡單跑一次。

將關鍵流程寫成一份簡短嘅測試腳本。點樣喺上線前測試你嘅應用程式會講解應該包括啲咩。

第七步：小心處理資料庫變更

資料庫結構嘅改動——例如新增一個欄位、重新命名一張資料表——正正係 staging 最能發揮作用嘅地方。

• 所有結構性改動都先喺 staging 執行。
• 檢查現有資料有冇保留，而唔係只係確認新功能能夠運作。
• 喺正式環境執行同一個改動之前，先為正式環境製作備份。請參閱點樣備份你嘅應用程式資料庫。
• 優先選擇新增而非重新命名或刪除嘅改動，咁樣如果要回滾，舊版本仍然可以運作。

範例提示

解釋如果我哋喺正式環境執行呢個資料庫改動，現有資料會發生咩事。有冇嘢會被刪除或重新命名？

將所有與環境相關嘅設定——API 網址、金鑰、電郵寄件人、網站自己嘅網址——改為從環境變數讀取，並且 staging 同正式環境使用相同嘅變數名稱。列出所有變數。

根據呢個應用程式嘅功能，寫一份簡短清單，列出每次發布前我應該喺 staging 測試嘅流程。

常見錯誤

• **共用資料庫。**最具破壞性嘅錯誤。Staging 必須永遠有自己嘅資料庫。
• **Staging 用正式金鑰。**會產生真實收費，亦會向真實客戶發出真實電郵。
• **Staging 同正式環境出現偏差。**版本或設定唔同，staging 就會失去捕捉問題嘅作用。
• 公開、被索引嘅 staging 網站，喺搜尋結果中同你真正嘅網站並排出現。
• **因為改動「細」而跳過 staging。**細改動都會令嘢壞咗。
• **喺錯誤嘅分頁測試。**一條顯眼嘅橫幅就可以解決。

清單

• Staging 運行與正式環境相同嘅程式碼、技術棧同服務。
• Staging 有自己嘅資料庫，並使用測試或打亂後嘅資料。
• Staging 嘅付款、電郵同付費 API 都使用測試金鑰。
• 各環境嘅變數名稱一致；只有值不同。
• Staging 放喺登入或密碼之後，並且唔會被索引。
• 身處 staging 時會顯示橫幅。
• 每次發布都先到 staging，並附有書面嘅待檢查流程清單。
• 資料庫改動先喺 staging 執行，並喺發布前為正式環境製作備份。

Mythex 上嘅 Staging

Mythex 嘅 Publish 為每個應用程式提供一個即時網址；冇獨立嘅 staging 開關。實際上你有兩個選擇：

• 用預覽作為發布前檢查。每個項目都喺私人雲端工作區中運行，並提供即時 Preview。/test 可以令代理以用戶身份點擊整個預覽，而分享連結則可以俾客戶或隊友審閱預覽，而無需發布。請參閱Preview 同 Code。對好多單人項目嚟講，咁已經足夠。
• **用第二個項目作為 staging。**在 Pro 方案下，匯出項目並匯入到一個新項目，俾佢自己嘅資料庫同測試金鑰秘密，並以自己嘅 slug 發布。喺發布正式項目之前，先發布到佢。

無論點做，喺測試任何具破壞性嘅嘢之前，都要問代理預覽同已發布嘅應用程式分別用緊邊個資料庫，並使用檢查點喺改動出錯時回滾。如果要更全面了解如何將應用程式上線，可以參閱點樣將 AI 原型推進到正式環境。

常見問題