需求评审过了，开发也写完了，为什么用户还不能用？
因为“代码写完”“测试通过”“部署成功”，各自只说了一部分工作。代码要进入团队版本，变成能运行的产物，经过验证，再放进正式环境。少看一环，进度就容易理解岔。
跟进需求时，听见“已经提交”“测试还没过”“等发版”，最好知道对方说的是哪一步、还缺什么条件。看懂这些差别，才能判断接下来该等谁、补什么、问什么。
下面沿着这条路，用八组图解，把容易混淆的地方拆开。
01 先看全貌：一条需求怎样走到线上
产品、研发和测试先说清范围与验收要求。之后开发实现功能，团队检查代码和运行结果，确认发布条件，再交给用户。
图里按主线排列，实际工作可以并行、返工。测试会提前参与需求讨论，代码合并的时点也按团队约定安排。
02 “代码提交了”，到底到了哪一步？
保存文件，改动还在工作区；暂存，选出本次要交的内容；commit，把它记进本地仓库；push，再同步到远端。
MR 是合并请求：请团队审查这批改动，并按规则合入目标分支。因此，commit、push、发起 MR、合并 MR，各有各的结果。听见“提交了”，还得问清是哪一种。Git 本地提交、远端协作
03 自动检查，是谁在干活？
同事评审代码里的逻辑和实现。自动化流程运行配置好的构建、测试等任务。GitLab 记录并安排任务，Runner 在执行机器上运行命令，再回报结果。
CI 关注频繁集成改动并自动验证；CD 将通过准入的候选版本继续交付到目标环境。检查、构建和部署规则通常由研发或平台人员配置。自动化做到哪一步、何时触发，都要看配置。GitLab CI/CD、Runner
绿色的“通过”还要看检查范围和对象。有的 MR 检查只跑源分支，组合后的代码需要另做相应验证。MR 流水线
04 自测、联调、测试、验收，为什么检查好几遍？
自测先看自己的改动；联调把各部分接起来；测试从需求、风险和影响范围出发检查；验收再确认交付是否满足约定的使用需要。
这些工作会交叉，不必等一个角色完全结束，另一个才出现。测试同学也会写自动化脚本，产品验收也可以和测试一起做。图里分的是关注点，质量还得由团队一起负责。ISTQB 测试与验收说明，§1.5、§2.2
05 提测交出去什么？修好了又怎么回来？
提测要交出能开始验证的版本，并说明改动范围、测试入口、所需账号和数据、自测结果及已知问题。否则，测试还没开始找 bug，先得四处找信息。
发现问题后，团队先定位原因。涉及代码修复时，要把修改构建、部署到新的测试版本，再开始验证。复测确认原问题修好了没有，回归检查相关部分有没有受到影响。缺陷改成“已修复”，流程还没走完。ISTQB 确认测试与回归测试，§2.2.3
06 大家说的是同一份版本吗？
分支会随着新提交继续变化。提交号可以定位代码；构建按项目要求处理代码和依赖，产生可部署的文件、软件包或容器镜像；产物标识再定位这次实际部署的内容。
环境是运行它的地方，里面还有各自的配置和依赖。交接时，最好能把代码、构建产物和部署环境对应起来。“测的是这个分支”提供的信息，还没有“哪个产物正在这个环境运行”明确。构建产物与环境
07 测试、预发、生产，差在哪儿？
测试环境方便检查功能和影响；预发尽量接近生产条件，进一步验证配置、依赖和发布步骤；生产环境真正为用户提供服务。同一份代码，换了配置或依赖，表现仍可能不同。
团队可以按项目需要设置环境，也可以通过其他发布检查承担预发验证。应尽量让同一候选产物逐级验证；补了代码或重新构建，就要核对变化，补做受影响的验证。GitLab 环境说明、部署验证建议
08 部署了，就等于所有用户都能用了？
部署让版本在目标环境运行；功能开放决定哪些用户什么时候能用。两者可以分开：先部署，再通过开关或灰度逐步开放。每次扩大范围前，都要看验证与运行结果。部署与渐进发布
CD 也不等于所有步骤无人确认。持续交付可以保留人工发布决定；持续部署则让符合既定条件的改动自动进入生产。持续交付与持续部署
部署后先快速验证关键路径，再观察错误、响应速度和用户反馈。Ops 负责运行保障，环境、部署、监控和恢复都是工作的一部分；可以由运维、平台人员或研发承担。出现异常时，先控制影响、恢复服务，再定位修复。涉及数据变更时，还要单独考虑兼容与恢复。灰度观察、恢复注意事项
跟进进度时，问清三个东西就更容易对上话：现在是哪份版本，在哪个环境，接下来还要验证什么。