企业审批CASE 01
“新增合同审批”如何从需求走到上线？
用户正在做什么
产品提出金额分级审批和撤回能力。
业务会出什么问题
只有页面稿时，开发可能遗漏状态规则、权限、通知和验收边界。
技术怎样介入
SDLC 覆盖需求、设计、开发、测试和 Release；Acceptance Criteria 明确每条可验证结果。
产品与设计怎样落地
设计交付应包含状态机、角色矩阵、异常和回退流程。
M4 · Chapter 12
软件研发与交付流程
理解一个需求如何从讨论、设计和代码进入真实生产环境。
先看哪些场景
企业审批、研发协作、订单与支付、部署与云
它是什么
软件交付是一套把需求转化为可验证版本，并安全发布到用户环境的协作流程。
为什么需要
产品质量取决于需求、代码、测试、版本和环境共同对齐，单次交付稿无法覆盖全部过程。
位于哪一层
横跨产品、设计、开发、测试、发布和运维。
和谁连接
SDLC、Git、Repository、Commit、Branch、Pull Request、Build、CI、CD、Release 和 Environment。
项目里怎么出现
新增筛选功能会经历需求澄清、设计、开发分支、代码评审、测试、灰度和发布。
Learning Outcomes
学完这一章，你应该能
- 理解软件开发生命周期
- 看懂 Git、Branch、Commit 与 Pull Request
- 理解 Build、Artifact、CI 与 CD
- 理解环境、版本、发布和回滚
12.01
一个功能如何走完生命周期？
需求会经过定义、设计、实现、验证、发布和持续观察。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
开发前需要明确用户目标、业务规则、边界和验收标准。设计与技术方案形成可执行方案，开发完成后进入测试和验收。
上线后还要观察错误、使用数据和用户反馈。软件是持续迭代的运行产品，发布只是一个版本节点。
Discover → Define → Design → Develop → Test → Release → Operate → Learn
System View
需求与目标
方案与设计
开发实现
自动与人工测试
发布审批
上线监控
反馈迭代
Designer Lens
设计稿需要与需求、接口、状态和验收条件一起进入研发流程。
SDLCAcceptance CriteriaRelease
12.02
Git、Repository 与 Commit
Git 记录代码如何随时间变化，并支持多人协作。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
研发协作CASE 01
为什么每次修改都要有一个 Commit？
用户正在做什么
开发分别调整表单校验、接口和样式，需要记录变化历史。
业务会出什么问题
直接覆盖文件无法知道谁改了什么，也难以撤销某次改动。
技术怎样介入
Git Repository 保存历史，每个 Commit 形成有说明的变更快照。
产品与设计怎样落地
设计资源也可以使用版本和变更说明，减少“最新版到底是哪份”。
Repository 保存项目文件和完整版本历史。Commit 是一次有明确意图的变更快照，包含作者、时间和说明。
团队可以比较版本、追溯问题、恢复旧代码和并行开发。设计文件的版本管理思想与此类似，但代码合并更依赖文本差异。
Working Files → Commit History → Shared Repository
System View
repository
A ── B ── C ── D
每个节点都是一次 Commit
可以比较、回退和建立分支Designer Lens
设计与开发确认问题时，版本号、Commit 或构建号比“最新版”更准确。
GitRepositoryCommit
12.03
Branch、Merge 与冲突
分支让不同功能在同一项目中并行开发。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
研发协作CASE 01
两个人同时修改同一个支付页面会发生什么？
用户正在做什么
一人增加优惠券，一人调整支付方式，两条 Branch 同时修改相同行。
业务会出什么问题
Merge 时可能出现 Conflict，系统无法自动判断应该保留哪个版本。
技术怎样介入
团队在独立分支开发，合并时人工理解差异并解决冲突。
产品与设计怎样落地
需求拆分和组件边界清晰，可以减少多人修改同一区域。
开发者从主分支创建 Feature Branch，完成后再合并。多人修改同一代码区域时可能产生冲突，需要判断最终保留的逻辑。
长期分支容易偏离主线，团队通常频繁同步并保持小批量提交。分支策略会影响发布节奏。
Main → Feature Branch → Review → Merge → Main
System View
主分支
→
创建功能分支
→
提交多次变更
→
同步主线
→
解决冲突
→
合并
Designer Lens
设计变更越晚、范围越大，开发分支和测试的返工成本越高。
BranchMergeConflict
12.04
Pull Request 与 Code Review
合并前通过可见讨论检查实现、风险和质量。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
支付逻辑为什么不能写完就直接上线？
用户正在做什么
开发修改退款金额计算和幂等处理。
业务会出什么问题
一个细小错误可能导致重复退款或金额异常。
技术怎样介入
通过 Pull Request 展示 Diff，Code Review 检查规则、测试和安全，达到 Approval 后合并。
产品与设计怎样落地
复杂业务要在 PR 中附上流程、截图和验收结果，设计师可参与体验 Review。
Pull Request 展示变更内容、目的、测试和影响，审查者可以评论、请求修改或批准。自动检查也会在此阶段运行。
Code Review 关注正确性、可维护性、安全和一致性。它也是知识共享和架构约束的执行入口。
Feature Branch → Pull Request → Automated Checks + Human Review → Merge
System View
变更说明
关联需求
预览或截图
测试结果
风险与回滚
审查评论
Designer Lens
复杂交互可以在 PR 中附预览链接、录屏和验收说明，减少仅靠静态截图沟通。
Pull RequestCode ReviewApproval
12.05
Build 与 Artifact
源码需要经过构建，生成可以发布的产物。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
部署与云CASE 01
开发源码为什么不能直接交给浏览器和服务器运行？
用户正在做什么
前端包含 TypeScript、模块和资源，后端也依赖特定库。
业务会出什么问题
源码需要转换、打包并锁定 Dependency，才能形成可重复发布内容。
技术怎样介入
Build 生成前端静态文件、可执行包或容器 Image，这些输出统称 Artifact。
产品与设计怎样落地
版本页面和缓存策略要与构建版本对应，避免新旧资源混用。
前端构建会打包、压缩和优化资源，后端可能编译成二进制、JAR 或容器镜像。Artifact 应可版本化、可追踪并能在不同环境重复部署。
Build 失败通常来自依赖、类型、编译或测试问题。将同一个 Artifact 推进测试和生产，可以减少环境差异。
Source + Dependencies + Build Config → Versioned Artifact
System View
源码
→
安装依赖
→
类型与静态检查
→
编译/打包
→
测试
→
生成 Artifact
Designer Lens
设计验收时记录构建号，可以确保讨论的是同一版本。
BuildArtifactDependency
12.06
CI 与 CD
自动化流水线让每次变更都经过一致检查和发布步骤。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
研发协作CASE 01
提交代码后，为什么测试和部署可以自动发生？
用户正在做什么
团队每天合并几十次改动。
业务会出什么问题
人工逐次测试、打包和上传容易遗漏，也难以保持一致。
技术怎样介入
CI 自动构建与测试；Continuous Delivery 保证随时可发布；Continuous Deployment 可自动进入生产。
产品与设计怎样落地
自动化失败需要明确阻断原因，发布通知要包含影响范围。
Continuous Integration 在代码提交后自动执行格式、类型、测试、构建和安全扫描。它尽早发现问题，保持主分支可用。
Continuous Delivery 保证版本随时可发布，Continuous Deployment 可以在检查通过后自动进入生产。团队会结合审批和风险等级选择自动化程度。
Push → CI Checks → Artifact → CD Pipeline → Environment
System View
CI
- 合并前后自动检查
- 测试与构建
- 保证主线质量
CD
- 产物进入环境
- 发布审批或自动部署
- 支持回滚与追踪
Designer Lens
自动化交付可以提供稳定预览环境，让设计验收更早发生。
CIContinuous DeliveryContinuous Deployment
12.07
环境、发布策略与回滚
版本要经过不同风险环境，并以可控方式进入真实流量。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
新版结算页怎样只给 5% 用户试用？
用户正在做什么
团队想验证新流程，同时控制支付风险。
业务会出什么问题
一次全量发布会把潜在问题暴露给所有用户。
技术怎样介入
Canary Release 逐步放量，Feature Flag 控制人群；异常时关闭开关或 Rollback。Blue-Green 可快速切换两套环境。
产品与设计怎样落地
设计新旧流程兼容、实验标识、数据口径和回退后的用户状态。
Development 用于开发，Staging 用于接近生产的验证，Production 服务真实用户。Blue-Green、Canary 和 Rolling Release 可以降低一次性切换风险。
数据库变更需要向前兼容，Feature Flag 可以把代码发布与功能开放分离。出现异常时，应能快速回滚或关闭功能。
Dev → Staging → Production；Canary Users → More Traffic → Full Release
System View
发布到 Staging
验收
少量灰度
观察指标
逐步放量
全量或回滚
Designer Lens
灰度期间要明确哪些用户看到新版本，避免设计验收和用户反馈混淆。
Canary ReleaseBlue-GreenFeature Flag
Chapter Recap
本章小结
- 01软件交付贯穿需求、设计、开发、测试、发布和运营。
- 02Git 用仓库、提交和分支管理代码历史。
- 03PR 与 Code Review 形成质量和协作入口。
- 04Build、CI、CD、环境和发布策略共同控制上线风险。
Practice
把认知变成一张图
为“新增项目筛选器”写一条从需求到上线的交付链，并标明设计在哪三个节点参与。
Quick Check
随堂检查
QUESTION 01
Pull Request 的主要作用是什么？
PR 是代码变更讨论、自动检查和合并的协作入口。
QUESTION 02
Canary Release 指什么？
灰度发布先让小部分流量使用新版本。