发布和环境

目的

定义软件如何从本地开发进入生产环境。

环境模型

环境 目的 工具
Local 开发者迭代 package manager、language runtime、Docker Compose 或 Dev Container
Preview PR 验证 Vercel/Render/Fly/GitHub environment
Staging 接近生产的集成验证 云环境
Production 真实用户 云 runtime

本地怎么开发、怎么运行、依赖服务怎么启动,见 43-本地开发-local-development.md

三角色环境责任

环境 产品负责人 技术负责人 平台 / 资深工程师
Local 不负责日常操作 要求项目可被新人跑起 提供命令、依赖服务、排障
Preview 验收用户可见变化 确认 PR 风险 维护 preview 构建和链接
Staging 验收发布前核心路径 确认集成风险 维护 smoke、数据、监控
Production 判断用户影响和沟通 拍板发布风险和回滚 执行或维护发布、监控、告警入口

本地基线

本地基线不是固定命令名,而是必须能完成这些动作:

动作 目的 JS/TS 示例 其他语言示例
启动依赖 启动数据库、队列、缓存、fake external service docker compose up -d 同左,或 Dev Container
启动应用 启动 Web/API/worker,支持本地调试 pnpm dev go run ./cmd/serveruvicorn app:app --reloadcargo run
本地检查 跑合并前核心门禁 pnpm check go test ./...pytestcargo test

本地设置必须有文档,让新工程师能在半天内跑起系统。后续如果接入 Agent,同一份文档也会成为自动化运行的基础。

发布检查表

使用 templates/发布检查表-release-checklist.md

最小发布记录:

  1. Version 或 commit。
  2. 包含的 PR。
  3. Migration 状态。
  4. Feature flags。
  5. Rollback plan。
  6. Owner。
  7. 发布后检查。

回滚规则

每个高风险发布必须回答:

  1. 能否通过 feature flag 关闭?
  2. 能否回滚 binary/image?
  3. 能否回滚 migration?
  4. 哪些用户数据可能受影响?
  5. 发布后谁看 metrics?

后续 Agent 就绪要求

Agent 可以准备 release notes 和验证 checklist,但没有 human approval gate 时不应部署到生产。

下一步阅读

读完或填完这份文档后,通常继续看: