19｜交付工作流：从 Commit 到 PR 与 CI/CD
组合提交、PR 清单与 CI/CD 配置完成交付闭环。
组合提交、PR 清单与 CI/CD 配置完成交付闭环。
交付像接力赛，不是一个人从需求一路冲到生产。设计明确意图，开发实现，审查挑战假设，发布验证环境；每次交棒都要有可检查的产物。
本课交付物
为一个双语设置页写四阶段执行单，每阶段列负责人、输入、输出、禁止项与通过门槛，最后设计生产烟雾检查和回滚触发条件。
上下文
- 当前 git 状态: !
git status - 当前 git diff: !
git diff HEAD - 当前分支: !
git branch --show-current - 最近的提交: !
git log --oneline -10
你的任务
根据上面的变更创建一个单独的 Git 提交。
如果通过参数传入了 message，就直接使用它：$ARGUMENTS
否则，分析这些变更，并按照 conventional commits 格式生成合适的提交信息：
feat:新功能fix:修复 bugdocs:文档变更refactor:代码重构test:新增测试chore:维护任务
核心讲解
在创建 PR 之前，请执行以下步骤：
-
运行格式化：
prettier --write . -
运行测试：
npm test -
查看 git diff：
git diff HEAD -
暂存变更：
git add . -
按 conventional commits 创建提交信息：
fix:bug 修复feat:新功能docs:文档refactor:代码重构test:测试新增chore:维护
-
生成 PR 摘要，包含：
- 变更了什么
- 为什么变更
- 做了哪些测试
- 可能的影响
核心讲解
根据项目类型实现完整的 DevOps 质量门禁：
- 分析项目：检测语言、框架、构建系统和现有工具链
- 配置 pre-commit hooks，使用与语言匹配的工具：
- 格式化：Prettier/Black/gofmt/rustfmt 等
- 代码检查：ESLint/Ruff/golangci-lint/Clippy 等
- 安全：Bandit/gosec/cargo-audit/npm audit 等
- 类型检查：TypeScript/mypy/flow（如适用）
- 测试：运行相关测试套件
- 创建 GitHub Actions 工作流（
.github/workflows/）：- 在 push/PR 时镜像 pre-commit 检查
- 多版本/多平台矩阵（如适用）
- 构建和测试验证
- 部署步骤（如需要）
- 验证流水线：本地测试、创建测试 PR，确认所有检查都通过
使用免费/开源工具。尊重已有配置。保持执行快速。
本站实战工作台
把对话变成四次可检查的交棒
设计明确用户问题与交互；开发把契约变成最小改动；审查主动寻找错误假设；发布验证真实环境并保留回滚。一个人可以承担多个角色，但不能跳过角色之间的证据交接。
示例：双语偏好设置
设计产物包括两种语言文案、Cookie/SSR 行为、键盘路径和验收。开发产物是范围清楚的 diff、迁移与测试。审查者不重写功能，而是挑战语言回退、缓存键、隐私和移动端。发布者使用已验证构建、备份、临时端口烟雾检查和原子切换。
DESIGN: 决策记录 + 验收
↓ gate: 范围批准
BUILD: diff + 自动证据
↓ gate: 测试/构建通过
REVIEW: 风险清单 + 修复结论
↓ gate: 无未处理阻断
SHIP: 备份 + 烟雾检查 + 回滚指针
Gate 必须能阻止前进
若测试失败仍能进入发布，Gate 只是装饰。定义阻断级别与例外授权：谁能接受已知风险，接受多久，如何追踪。不要让开发者用“本地看起来可以”替代独立审查。
发布验证环境差异
生产问题常来自环境变量、反向代理、数据库状态、构建运行时和缓存，而非源码。切换前在临时端口启动新构建；切换后检查中英文页面、API、PM2/进程和错误日志时间戳。不要用真实删除操作做视觉烟雾测试。
回滚是发布步骤，不是事故备注
记录上一 release、当前 symlink、数据库备份与兼容窗口。代码可回滚但破坏性迁移不可回滚时，发布方案本身不合格，应拆成兼容迁移与后续清理。
本课交付 release-runbook.md，让另一位工程师不读聊天也能执行、验证和回退。可靠流程的价值，是每次交棒都留下下一角色能核验的事实。
最后安排一次桌面演练：由未参与开发的人照 runbook 操作到切换前一步，并指出任何依赖口头知识的空白。