我從來冇諗過部署一個帶React前端嘅Laravel REST API會咁難。開發本身並唔係難點。我嘅Laravel詞彙量仲有提升空間,但呢個只有喺我攞到用呢套技術棧嘅項目或工作嗰陣先真正重要。真正令一切崩壞嘅,係部署呢一環。
出咗咩問題
簡單講:遷移、填充器同權限錯誤食咗我兩個鐘嘅人生。
我喺自己嘅homelab上跑住一個共享嘅PostgreSQL實例(Redis都係),咁樣就唔使為每個項目獨立起資源。呢個意味住對呢個應用嚟講,我要手動建立一個新數據庫,並修改資料表嘅擁有權,後端嘅.env先可以真正連接到並順利跑遷移。佢用得,但講唔上優雅。
返過頭睇,我大概應該寫一個似樣嘅.sh腳本嚟處理數據庫同用戶嘅搭建,而唔係手動操作。呢次已經嚟唔切喇,但呢條經驗會入我嘅工具箱,留住下次用。
Faker嘅坑
另一個食咗大量時間嘅地方:我喺填充器入面用咗Faker,但佢被放喺require-dev入面,而唔係require。呢個意味住每次我喺生產環境入面試緊跑填充器都會失敗。經過兩次重新構建,我先發現呢個問題,並將佢挪去正確嘅位置。
總結
- 共享嘅Postgres同Redis實例可以慳資源,但會多出一個手動搭建步驟(建數據庫、改擁有權),呢一步好容易一直唔記得到部署當日先諗返起。
- 一個可重用嘅
.sh腳本,用嚟設定新嘅數據庫同用戶,本可以慳返嗰兩個鐘入面相當一部分。 - 要仔細核查邊啲依賴真係需要發佈去生產環境。Faker,以及其他只用於填充或測試嘅嘢,只有喺你嘅生產流程永遠用唔到佢哋嘅情況下,先應該放喺
require-dev入面。如果會用到,就將佢挪上去。
部署當日總可以揪出嗰啲開發當日被放過嘅漏洞。呢一次只係揪出嘅比平時多啲啫。