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 链接，等项目需要时再加入域名、回滚、访问分析、自动化和团队控制。