2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
最初于 2026 年 5 月 13 日发表在 ajeetchaulagain.com 上。
几个月来，我一直在构建 ShipWindow —— 刻意放慢节奏，从第一天起就秉持生产环境思维。虽然目前还没有用户，但拥有真实的架构、真实的持续集成（CI）以及基础设施即代码。
“快速发布，稍后重构”可能是这类副项目的常规做法。但我希望在推进过程中尝试将其与生产环境思维相平衡 —— 依然在发布，但在操作的同时考虑得更长远一些。
结果可谓喜忧参半。一些出于生产环境考虑的决策已经得到了回报 —— 我即将详细介绍的持续集成工作就是其中之一。本文主要讨论的就是这部分取得成效的内容。
持续集成是这种思维早期体现的地方。在项目初期，我有一个最小化的工作流来验证每个拉取请求 —— 代码检查、类型检查和测试 依次顺序运行。这在当时是可行的。但随着项目的发展，工作流也随之扩展。截至撰写本文时，同样的持续集成流程在大多数推送中能在 约 2 分 30 秒内跨越 3 个应用程序和 4 个包运行 —— 并且其设置旨在随项目扩展而扩展，而不是随着代码量的增加而变慢。
三个应用程序，几个共享包，每次推送都重新构建所有内容。你可能会认为在这种设置下持续集成会很慢 —— 这确实是我最初的起点。但事实证明并非必须如此，而且 这种在跨技术栈合并更改时带给我的信心，说实话才是更大的胜利。我将详细介绍其工作原理，以及促成这一结果的决策过程。
代码仓库的结构
代码仓库的高层结构如下：
shipwindow/
├── apps/
│ ├── web/ # Next.js 16 — 经过身份验证的仪表板
│ ├── site/ # Next.js 16 — 落地页
│ └── api/ # NestJS — Webhook 接收 + 身份验证
├── packages/
│ ├── ui/ # 共享组件库 (Tailwind v4)
│ ├── shared-types/ # Web 与 API 共享的类型定义
│ ├── eslint-config/
│ └── typescript-config/
├── infra/ # AWS CDK 堆栈
├── turbo.json # 任务图 + 缓存配置
└── package.json # Yarn 工作区声明
三个应用程序位于 apps/ 目录下 —— 每个都是独立部署的项目。四个共享包位于 packages/ 目录下 —— 这些是应用程序导入的库，但它们本身并不独立发布。基础设施位于 infra/ 目录中（使用 AWS CDK 编写的堆栈），与应用程序代码分开存放，因为它拥有自己的生命周期和工具链。
Yarn 工作区 将整个项目连接为一个代码仓库 —— 当 apps/web 导入 @shipwindow/ui 时，它直接解析到本地源代码，中间无需发布步骤。Turborepo 建立在工作区之上，负责任务运行的编排 —— 知道以什么顺序构建什么内容、缓存什么内容以及跳过什么内容。
为什么选择单体仓库
当我开始思考 ShipWindow 的设置时，我的第一直觉实际上是拆分为多个代码仓库。这感觉更安全 —— 减少 t
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
