一鍵部署

這是什麼

一鍵部署意味著你所描述的那個應用，從建置到在網際網路上線，不需要你做任何設定。ybuild 編譯前端、開通後端、連接資料庫與認證，並把整套東西對外提供服務——託管在平台上、在你自己的網域上。沒有要搭建的建置管線，也沒有要推送的另一個主機。

為什麼重要

「在建構器裡能用」和「客戶可以用」之間的那道鴻溝，是大多數專案夭折的地方。即時部署，而且每次改動都重新部署，才是讓一個業務系統真正運行起來、而不是永遠卡在「進行中」的關鍵。上線必須是最輕鬆的那一步，而不是一堵牆。

在 ybuild 上怎麼用

當你的應用準備好了，ybuild 一個動作就把整個全端——前端、後端、資料庫與認證——部署好，並在你的網域上上線提供服務。你之後做的每一次改動都以同樣的方式重新部署，就地更新運行中的應用。你從不用碰建置設定、伺服器，或任何外部託管帳號。

「部署」到底做了什麼，以及為什麼它往往是最難的一步

「部署」聽起來像是一個按鈕，但在底層，它其實是一堆彼此獨立的工作必須同時全部成功、你的應用才能在公網上回應一個真實請求的那一刻。對一個全端業務應用來說，這意味著至少有六件不同的事情要按正確的順序發生。

前端必須被編譯並打包成經過最佳化的靜態資源，從離你客戶最近的邊緣節點快速載入。後端——運行你業務邏輯與 API 的那部分——必須在真實的伺服器上被開通並啟動。資料庫必須被建立、它的結構遷移必須被執行，這樣你應用所依賴的那些資料表在第一個請求抵達之前就已經存在。環境設定與金鑰——連線字串、API 金鑰、各個服務用來找到彼此的位址——必須被正確注入，因為一個錯誤的值就足以讓一個可用的應用變成一整頁 500 錯誤。網域必須被綁定、TLS 必須被終止、流量必須被路由。最後，新版本必須以原子方式切換上線，這樣任何客戶都不會落在一個只更新了一半的應用上。

正是這個流程，讓手動部署成了時間憑空消失的地方。每一步都在不同的工具裡，每一步都有它自己悄無聲息失敗的方式，而這些失敗往往要等到應用理應「已經上線」時才暴露出來。最經典的災難，就是在你自己機器上跑得完美無缺的建置，到了正式環境卻只回傳一堆錯誤——只因為某個環境變數從沒被設定，或者某個遷移沒有執行。

ybuild 在一次執行裡把這六件事全部做完，因為這個應用本來就是它建置的。它早就知道自己設計的資料庫結構、後端暴露的路由、每個服務需要的金鑰，以及你連接的網域——所以沒有什麼要手動設定，也沒有什麼會被悄悄設錯。你點擊部署；整個全端系統就託管在 ybuild、在你自己的網域上運行起來，端到端全部接好。

自己搭一套部署管線 vs. 在 ybuild 上直接擁有它

值得誠實地聊聊「自己動手」這條路，因為正是在這裡，一個動作的價值才變得一目了然。

靠你自己，上線本身就是一個專案：挑選主機，把執行環境容器化或設定好，接一套 CI/CD 管線讓一次改動真的能抵達正式環境，管理建置設定與每個環境各自的變數，按正確順序執行資料庫遷移，為遷移失敗的情況寫好回復腳本，安排一次零停機切換讓網站在更新時不會閃斷，然後永遠為每一層打補丁維護下去。這些沒有一樣是你客戶為之而來的那個應用。它們只是那套必須完美無瑕運轉、客戶才能看到應用的機器。

關於這一點的研究出奇地清晰。DORA——Google 長期運行的 DevOps 研究與評估專案——發現最高績效的團隊都有一項共同能力：他們能夠「快速、安全、可持續地按需發布各種變更」，在任何時間推送到正式環境，包括正常工作時間內，而不打擾使用者。正是這項能力，把頂尖交付團隊和其他所有人區分開來。問題在於，按傳統方式做，它要一支專門的平台或 DevOps 團隊花上幾個月來搭建與維護。

ybuild 把這一整套技術棧壓縮成一個動作，於是一個單打獨鬥的創辦人或一支小團隊，就能獲得頂尖團隊級別的部署能力，卻不需要頂尖團隊的人手。你用一段提示詞描述這個應用，它被建置成一個運行中的全端系統，然後一鍵上線——託管在 ybuild、在你自己的網域上。當你改動什麼——一個新欄位、一個新頁面、一個新價格——它以同樣的方式重新部署，就地更新線上版本。沒有匯出，沒有 zip 壓縮檔，沒有第二個要登入的主機，也沒有一條你必須自己維護的管線。那套機器是平台的問題；應用、資料與網域是你的。

上線的那些坑，以及持續部署對一門真實生意意味著什麼

有幾個邊界情況幾乎絆倒了每一個手動部署的人，而值得知道的是 ybuild 把它們都吸收掉了。第一次上線就壞掉——本地能跑、正式環境卻掛——幾乎總是因為缺了一個環境變數，或者一個遷移從沒執行過；因為 ybuild 把後端、資料庫與設定從它建置的那個應用裡一起開通出來，兩個世界之間根本沒有可供這類問題藏身的縫隙。破壞性遷移——一次結構變更悄悄刪掉一欄、連帶帶走真實客戶資料——正是那種 ybuild 替你打理、而不是留給你在半夜手寫 SQL 腳本去冒險的錯誤。而停機視窗——一次天真的部署在切換版本時讓網站停擺的那幾分鐘——被就地更新取代，於是運行中的應用在整個變更過程中持續對外服務。

更深的那個坑是心理上的。當部署既可怕又要手動，人們就會把改動攢成一批、很少發布，這讓每次發布都更大、更冒險、更痛苦——恰恰和有效的做法相反。DORA 在這裡的發現雖然反直覺卻證據充分：小而頻繁的部署，比稀少而龐大的部署更安全。以小批量發布能「減少部署痛苦」、降低變更失敗率，並讓團隊在幾分鐘而非幾天內從問題中恢復。頻繁發布不是冒險的選擇；它才是可靠的那個。

對一門運行中的生意來說，這改變了「發布」的感覺。一位客戶要求在預訂表單上加一個欄位，你在定價頁上發現一個錯字，一場促銷需要在週末前上線——有了一鍵重新部署，這每一件都能在幾分鐘內上線到你的網域上，而訂單還在不斷進來、客戶還保持登入狀態。你不再為了一次讓人害怕的「大更新」而囤積改動，而是一發現問題就立刻去修。部署不再是一堵你要繃緊神經去面對的牆，而變成一件你幾乎不會去想的小事——而這，正是一個運行中、被託管的業務系統本該有的感覺。

常見問題

我需要設定伺服器或主機才能讓應用上線嗎？

不需要。沒有任何東西要設定——ybuild 一步就替你部署整個技術棧。它編譯前端、開通後端、連接資料庫與認證，並把應用託管在 ybuild、在你自己的網域上對外提供服務。你從不用挑選主機、搭建管線，也不用碰任何建置設定。

我點擊部署時，到底發生了什麼？

在一次執行裡，ybuild 建置並最佳化前端、啟動後端、建立資料庫並執行它的遷移、注入每個服務所需的設定與金鑰、為你的網域綁定 SSL，然後乾淨俐落地切換到新版本。因為應用是 ybuild 建置的，它早就知道每一個部件——所以沒有什麼要你去接線，也沒有什麼會被悄悄設錯。

從提示詞到一個上線的應用，能有多快？

很快——上線是一個動作，而不是一個單獨的專案。一旦應用從你的提示詞被建置出來，一鍵就能部署整個全端系統，並把它託管在 ybuild、在你自己的網域上對外提供服務。在「它能用」和「客戶可以用」之間，沒有 CI/CD 搭建，也沒有主機帳號橫在中間。

我推送更新時，應用會不會當機？

不會。你做的每一次改動都會就地重新部署，在沒有維護視窗的情況下更新運行中的版本。訂單在整個變更過程中持續進來，客戶也保持登入狀態。正是這一點，讓你可以一發現就放心地推送小修復，而不必為一次冒險的「大更新」而囤積它們。

如果新版本出了問題怎麼辦？

你絕不會被一個壞掉的部署困住。因為 ybuild 託管你的應用並保留你的版本歷史，你可以一鍵回復到上一個可用版本，你網域上的線上網站會在片刻之間重新提供那個好的建置。小而頻繁的部署，加上即時回復，正是讓你能持續改進一門運行中的生意、而不必在每次編輯時拿它去賭博的原因。