从“能跑”到“敢交付”：我重新理解生产化

我以前很容易把生产化理解成“把程序部署出去”。但当产品开始被真实业务依赖，问题就不再只是构建是否成功，而是：这次到底发布了什么，依据什么发布，谁有权做这件事，如果结果不对，能不能确认并恢复。

三种规则不能混在一起

我现在会把交付判断拆成三层：

• 平台约束：某个平台硬性要求的版本、签名、分发或兼容规则；
• 可靠交付目标：来源、产物、验证、授权、结果和恢复都可核对；
• 团队选择：分支策略、版本名称、发布节奏和人工批准频率。

平台事实不能靠习惯猜，可靠目标也不等于必须使用某一家 CI，团队选择则要尊重现有责任和权限。把三层混在一起，最容易出现“看起来专业，但没有解决当前风险”的流程。

一个最小闭环

我会按这样的顺序思考：

确定交付单元与影响
→ 查现状和权限
→ 固定来源与产物
→ 验证风险相关路径
→ 核对必要批准
→ 发布
→ 从用户访问面验证
→ 观察并准备恢复

静态内容、客户端、服务端和数据库的风险完全不同。静态页面重点是构建、链接和真实访问；客户端要考虑升级、签名和旧版本；服务端要看运行镜像、依赖与健康状态；数据库还要确认破坏性变更和恢复证据。

权限比“理想流程”更先

我曾经把一个局部交付单元想象成拥有整个仓库的控制权，甚至差点把公共 CI 和主线一起纳入方案。后来补充了真实权限后，正确做法变成：保留团队治理，只在自己负责的范围内建立可复现的交付线。

这件事让我重新确认：分支可写不意味着 CI 可改，更不意味着可以部署生产。流程的第一步不是设计得多完整，而是先知道自己对哪些对象真正拥有责任和权限。

上传成功不是用户成功

Git 提交、标签、构建产物和线上页面不是同一个东西。一个二进制上传成功，不代表用户拿到的是正确版本；一个 Git 标签存在，也不代表所有影响运行的配置和依赖都被包含。

所以我会把最终验证放到用户访问面：用真实入口确认页面、版本、健康状态和关键行为，必要时保留失败信息和恢复路径。

生产化对我来说不再是“让探索变慢”，而是让快速迭代有一个能够被核对的落点：探索可以快，交付必须说得清楚。