部署到自己的伺服器,意味著把類似 SSH 的存取權交給一個代理,而這台你付費的機器上可能已經有其他東西在運作。這和發布到免費子網域是不同層級的信任,而設定流程也反映了這一點──幾個欄位,填一次,之後每次建構都只是按一個按鈕。以下是大家在設定前後實際會問的問題。
建立目標需要準備什麼？
五樣東西,都在設定 → 部署裡：
- 一個你之後能認得的名稱──「prod-vps」、「client-hostgator」,隨便什麼在晚上十一點下拉選單裡還能認出來的名字
- 主機與連接埠
- SFTP 憑證
- 網站根目錄路徑
不需要 API token,不需要在伺服器上安裝 CLI,也不需要照顧排程工作。如果你的主機商提供 SFTP 存取──幾乎每一種共享主機、每一台 VPS、每個代管 WordPress 主機都有──大約兩分鐘就能搞定。
密碼還是金鑰？
如果你的主機商支援,就用金鑰。密碼也完全可用,而且我們儲存時會限制在你的帳號範圍內,但金鑰能少一個到處存在的機密──萬一之後出問題,「撤銷一把金鑰」和「重設所有重複使用過那個密碼的地方」是天差地遠的差別。很多便宜的共享主機 SFTP 只提供密碼驗證,那也完全沒問題。只是別在別的地方重複使用那個密碼。
我要怎麼找到正確的網站根目錄路徑？
這是大家第一次最容易搞錯的欄位,因為錯誤的答案看起來還挺合理的。它不是您的家目錄,也不是 /var/www ——而是您的網頁伺服器實際設定用來提供服務的那個確切資料夾。
| 伺服器 | 常見的網站根目錄 |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html ——或是三年前某位前任開發者取的、沒人記得原因的某個路徑 |
如果不確定,可以用任何 SFTP 用戶端,先丟一個用完即丟的 test.txt 到您認為是對的那個資料夾裡,然後檢查它能不能在這裡載入: yoursite.com/test.txt。一旦搞錯,部署仍然會回報成功——智慧代理會忠實地把檔案寫進錯誤的資料夾,而您只能盯著一個沒有任何變化的上線網站,納悶到底怎麼回事。
一個目標可以涵蓋不只一個網域嗎？
可以,而且這正是在你架設完第一個網站之後最省時間的部分。一個目標是一台伺服器加一組憑證──它並沒有綁定單一網域。在網域管理裡,你可以把每個網域附加到某個目標,並各自設定自己的網站根目錄覆寫。用一台裝有 Nginx server block 的 VPS 跑三個網站？
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
一個目標,三個附加項目。你不需要重複輸入三次 SSH 密碼,也不需要維護三個幾乎相同、卻在你輪替金鑰時忘了同步其中一個而漸漸失衡的目標。點擊三個網域中任何一個的部署按鈕,它已經知道是哪台伺服器、哪個資料夾──你不必在部署當下重新選擇。
代理連上伺服器後實際會做什麼？
首先,它會先環顧四周──唯讀,還沒寫入任何東西。這次檢查是在確認：
- 一個空資料夾
- 這個確切建構的舊版本
- 一個舊的 WordPress 安裝
- 主機商預設放在那裡的「即將推出」佔位頁面
這決定了採用的策略。空的網站根目錄會直接上傳。已經有東西的網站根目錄會處理得更小心,因為許多實際的設定都有一些和網站並存、不該憑空消失的東西：
- A
.well-known資料夾,用於 SSL 驗證 - 一個
uploads目錄,沒人放進 git 裡 - A
wp-config.php沒人希望被動到的
這裡的工作比較接近「找出改變了什麼並加以協調」,而不是「清空後取代」。
接著,在任何一個位元組被覆寫之前,現有的網站根目錄會先在您自己的主機上被擷取成一個版本。這不是資料庫紀錄,也不是我們計算出來、寄望它正確的差異比對——而是實際存在的當下狀態快照。這在任何目標第一次部署時最為重要,因為那次部署一定會覆蓋在某個東西之上,即便那個東西是空無一物。空資料夾,就得到空快照。五年前建的靜態網站,沒人記得怎麼做的——在被觸碰之前,原封不動地被保留下來,而且完全免費。那第一次部署,也正是您最沒把握的一次,所以這一點在此時最為重要。
它上傳的是我的原始碼,還是建構好的網站？
永遠是已建置完成的網站。對靜態網站來說,那就是產出的頁面。對框架建置——Next.js、Vite,或該網站類型所需的任何框架——來說,則是編譯後的輸出結果,也就是 dist 或 build 資料夾,絕不是原始碼樹。我認為這個決定是對的,儘管這代表您無法 SSH 進去,對伺服器上的內容執行 npm run dev 。上傳原始碼會代表您的正式環境網站根目錄需要一個 Node 執行環境和建置工具鏈才能提供 HTML 服務——把一台原本從未打算執行建置流程的共用主機,硬生生變成一台要跑建置流程的主機,而且每次部署都變成「祈禱伺服器有足夠的記憶體能跑完 npm install」。只出貨編譯後的輸出,能讓網站根目錄完全維持靜態檔案伺服器所預期的樣子。很無聊。而無聊正是您在凌晨兩點、出了狀況、盯著那個資料夾想搞清楚到底伺服器上跑的是什麼時,最想要的東西。
我要怎麼知道部署真的成功了？
上傳完成後,智慧代理會連上正式網址,檢查它能不能正常解析——不是 500 錯誤,也不是空白頁面。無論它發現什麼,再加上它在檢查過程中注意到、想請您確認的任何事(「這個網站根目錄裡有一個 wp-content 資料夾,我沒有動它,請確認這是預期的」),都會出現在該次建置的聊天串裡。這正是整個平台一貫的模式:不會有靜默的成功,也不會靜默失敗變成一張客服工單。智慧代理會在您提出建置需求的同一個聊天串裡,告訴您它看到了什麼、做了什麼決定。
版本歷史裡實際上有什麼？
每次部署都會新增一個版本──不只有第一次。所以歷史紀錄並不是把你的建構對照一條抽象時間軸畫出來的東西;它是那個網站根目錄實際依序被提供過的內容,依照時間順序,從你出現之前那裡有的東西開始算起。第一個版本永遠是平台介入前的那個狀態,自動擷取,你完全不用去想它。
還原實際上會恢復什麼？
上一個上線版本,完全一致——不是重新執行舊的建置,也不是估算出來的近似值。而是先前實際提供流量服務的那些檔案。這比我在其他地方用過的大多數「還原」功能保證得更強——那些功能通常代表「從舊的 commit 重新部署」,並悄悄假設您的建置流程是確定性的,而且您的環境自那之後沒有發生過任何漂移。而在這裡,還原是恢復到一個已知良好的快照,這也是為什麼在壓力之下伸手用它是安全的——您不必去思考還原的結果會不會跟被還原的目標不一樣。
而真正需要用到它的那一刻,從來都不會是平靜的時刻;通常是「新的建置弄壞了結帳流程,而且現在正有流量進來」。
一鍵還原到上一個版本,搞定。把這項功能當作核心功能而非事後補充的理由,寫在《無懼迭代》這篇文章裡——值得在真正需要之前先讀一遍。歷史紀錄與還原控制項都同時存在於建置卡片以及目標本身的歷史紀錄檢視畫面中。
這個功能也會備份我的資料庫嗎?
不會,而且我寧願直接把話說清楚,也不要讓任何人誤以為會。主機上的版本歷史紀錄涵蓋的是這條部署流程放進網站根目錄裡的內容。如果您的網站有資料庫、使用者上傳檔案,或任何在部署之外會變動的東西,那完全是另一回事——還原功能不會碰它,也不應該被誤認為是能涵蓋這些的備份策略。
