返回全栈开发
PATH 02/LESSON 14/18 分钟

从构建到生产交付

用类型、测试、可访问性、性能与观测守住上线质量。

课程全目录 · 选择章节

本课学习目标

  • • 检查 — 类型、规范与测试
  • • 构建 — 生成可交付产物
  • • 发布 — 部署确定版本
  • • 观测 — 确认真实表现

完成路径

阅读概念与案例 → 完成动手任务 → 勾选实践检查 → 回答检查点 → 保存完成记录。练习由你自行检查,不会假装成自动代码评分。

01 / 核心概念

部署不是开发结束后的最后一步,而是一条可重复的管线。构建、检查、发布和回滚都应该有明确输入与结果。

生产质量来自多个小护栏,而不是一次最终人工检查。

02 / 心智模型

01

检查

类型、规范与测试

02

构建

生成可交付产物

03

发布

部署确定版本

04

观测

确认真实表现

03 / 代码骨架

TYPESCRIPT / CONCEPT
npm run typecheck
npm run lint
npm run test
npm run build
# deploy the exact successful artifact

这是解释结构的代码骨架,外部函数与数据需要在实际项目中实现。

04 / 贯穿案例

放进真实情境里看

任务台在本地工作正常,部署后却因缺少环境变量导致登录失败。构建通过只能说明代码可编译,不能证明真实访问路径可用。

  1. 01

    拆开交付门槛

    类型检查、lint、关键路径测试、可访问性检查和生产构建各自覆盖不同问题。保留明确的失败阻断条件。

  2. 02

    验证生产路径

    部署到预览环境后走一遍登录、创建任务、刷新、退出;核对数据库权限与环境变量是否属于该环境。

  3. 03

    准备回滚与观测

    记录本次版本、迁移和关键指标。出现持续错误时,知道是回滚应用、修正配置,还是需要兼容旧数据。

05 / 动手做

用自己的产物检验理解

为任务台写一份上线清单:至少五个发布前检查、两个发布后信号,以及一个回滚条件。

完成时检查

  • 包含真实登录与权限路径
  • 能说明环境变量缺失时的表现
  • 定义可执行的回滚条件

自动保存在当前浏览器,不会同步到账户。

继续到代码练习

06 / 检查点

为什么应该部署确定的构建产物?

延伸阅读 · 原始资料