这一步为什么合理？
因为当时最重要的不是建立一套长期系统，而是尽快得到真实反馈：页面能不能打开，视觉是不是成立，别人能不能理解我在做什么。
直接部署把“写代码”和“看到结果”之间的距离压到了很短。它让一个想法先拥有了网址，也让后面的讨论不再停留在本地文件里。
FIELD STORY / DELIVERY INFRASTRUCTURE
先让它上线，
再让它变得可管理。
Portfolio Ops 不是一开始就被设计好的系统。它从一次直接部署开始，在持续更新中接入 GitHub，最后又因为产品变多，演进成一套单仓多产品、多域名的交付方式。
00 / THE CONTEXT
我并不是先想好了
“应该使用单仓架构”。
我只是先遇到了一个很具体的问题：如何把自己写出来的页面，尽快变成一个别人可以打开的页面。后来，产品开始变化，问题也跟着变化。
这是一段从“能上线”走向“可持续管理”的过程。 其中最重要的决定，不是选择了哪一个平台，而是每一次都认真回应上一阶段暴露出的限制。
01 / DIRECT DEPLOY
THE BEGINNING / JUST SHIP IT
我先只解决一个问题：
让代码跑起来。
最开始没有复杂的架构，也没有多产品规划。我写完一个页面，就直接通过 Cloudflare CLI / Pages 把它部署出去。
WHAT IT GAVE ME很快得到一个真实结果
想法第一次从本地文件变成了可访问的页面。
WHAT IT LEFT BEHIND下一次更新还要靠记忆
代码、部署动作和线上版本之间没有稳定的历史关系。
THE FIRST QUESTION页面可以打开，但下一次更新该从哪里开始？
当页面不再是一次性 Demo，而是要被反复修改时，“直接部署”开始从优势变成了需要被管理的动作。
02 / GITHUB MANAGED
THE SHIFT / MAKE CHANGE TRACEABLE
我需要的不只是上线，
还需要知道发生过什么。
于是代码先进入私有 GitHub 仓库，再由 GitHub Actions 把变更送到 Cloudflare。部署不再是一次手工动作，而成为代码生命周期的一部分。
GitHub 带来的好处，不只是“存代码”。
每一次修改有了提交记录，线上版本有了对应的来源，错误也不再只能靠回忆去定位。即使未来需要协作，或者需要借助 AI 一起改代码，也有一个清晰的共同上下文。
更重要的是，我不需要把部署凭证写进代码里。仓库保持闭源，Cloudflare 的认证信息只作为 CI 环境中的安全配置存在。
WHAT IT GAVE ME变更、版本和部署可以对上
我可以回看、回退，也更容易判断线上问题来自哪里。
WHAT IT LEFT BEHIND一个产品一套配置会重复
当未来出现更多产品时，仓库、Actions、Secrets 和发布规则可能被复制很多遍。
THE SECOND QUESTION如果每个产品都要上线，难道要复制一整套部署系统？
这次真正需要解决的，已经不是“怎么部署一个页面”，而是“怎么持续照看一组正在生长的产品”。
03 / MONOREPO SYSTEM
THE DECISION / MANY PRODUCTS, ONE ORDER
我一开始以为要建很多仓库，
最后选择了一个仓库里的多个文件夹。
直觉方案是“一个产品一个代码仓，再分别接入 Cloudflare”。它当然可行，而且隔离性很强；但对一个人维护的产品组合来说，重复配置本身很快就会变成新的负担。
所以最后的选择不是把所有产品揉成一个应用，而是把代码放在一个私有仓库里分区管理：每个产品有自己的文件夹、自己的发布目标和自己的域名；统一的只是管理方式。
一个产品，一个代码仓
每个产品都可以独立配置和部署，但每增加一个产品，就要重复一套维护动作。
- 隔离清晰，边界天然独立
- Actions、Secrets、构建规则重复配置
- 个人维护时，长期成本会上升
一个代码仓，多个产品文件夹
用目标清单描述“哪个文件夹对应哪个发布目标”，用一个工作流按变更选择需要部署的产品。
- 统一版本、权限和部署规则
- 按目录变更，只发布受影响的目标
- 每个产品仍然可以独立访问和迭代
THE SYSTEM TODAY / PUBLIC VIEWNO ACCOUNT IDS · NO TOKEN VALUES
01 / SOURCEPrivate monorepo一个仓库，多个产品文件夹
→02 / ROUTETarget matrix按变更选择需要发布的目标
→03 / PUBLISHPages + domains各自的产品页面与域名
最终形成的是一种“统一维护、独立交付”的关系：我只需要照看一套系统，但产品不会因此失去自己的边界。
04 / THE TAKEAWAY
这不是“单仓一定更好”，
而是它刚好回答了我的问题。
如果是大型团队、强隔离组织或完全不同的技术栈，独立代码仓可能更合适。对现在的个人产品实验来说，单仓多目录减少了重复运维，又保留了独立产品的发布能力。
统一管理什么
- 代码版本、仓库权限和协作上下文。
- GitHub Actions 工作流和构建脚本。
- 目标清单、变更识别和生产发布检查。
- CI 凭证只存在于安全配置中。
保持独立什么
- 每个产品自己的源代码文件夹。
- 每个产品自己的 Pages 发布目标。
- 每个产品自己的访问入口和域名。
- 未准备好的产品可以保持禁用。
“先让想法拥有一个网址，
再让它拥有一套可以持续生长的秩序。”
Portfolio Ops 的价值，不是把部署包装得更复杂，而是让每一次迭代都留下痕迹，让下一个产品不必从零开始。
这套系统还会继续变化，但它的方向已经清楚：让产品独立生长，让交付方式保持可复用。