CLI 與 CI 流程

當部署變成例行事,
就把它寫成指令

第一次驗證可以直接在瀏覽器拖放檔案。當同一個靜態 build 需要反覆發佈,就把發佈步驟放進 terminal、CI job 或團隊操作手冊,避免上線依賴某個人記得手動上傳。

$npm install -g @deploypages/cli
查看文件取得部署存取權
💻
本機建置
zsh
app git:(main) deploy ./dist
Deploying to my-app
Uploading... 100%
✔ Success!
☁️
正式環境

適合會做第二次以上的發佈

不要靠記憶做手動流程

部署指令會把重複上傳變成團隊可記錄、可檢查、可用同一方式執行的發佈步驟。

讓 CI 完成最後一步

如果 GitHub Actions 或其他 CI 已經產出建置輸出,deploy step 應該直接發佈該資料夾,而不是再請人手動上傳。

保留同一套專案模型

先用瀏覽器上傳開始,等它變成真正發佈路徑時,再把同一個專案移到自動化。

先手動,值得自動化時再自動化

一次性預覽應該保持簡單。CLI deploy 適合反覆發佈、需要團隊審核,或由 build pipeline 觸發的網站。

steps:
  - uses: actions/checkout@v2
  - run: npm install && npm run build
  - run: npx @deploypages/cli deploy ./dist --token ${{ secrets.DEPLOY_TOKEN }}

常見問題

Q: Windows、macOS 和 Linux 都能跑嗎?

可以。實用的 CLI 部署路徑必須符合團隊本機建置和 CI runner 已在使用的作業系統。

Q: 可以從自動化指定特定專案嗎?

可以。可腳本化部署只有在團隊能明確把發佈流程綁到正確專案脈絡時才好用。

Q: 適合 monorepo 嗎?

適合。使用 monorepo 的團隊需要能指定工作目錄和發佈輸出的部署路徑。

從每個靜態網站原本就有的部分開始

上傳建置好的檔案,取得 HTTPS 連結,等專案需要時再加入網域、還原、統計資料、自動化和團隊控制。