部署Deployment

选一种策略，亲手把 v2 推上生产

部署 = 把构建好的产物放到服务器，再把流量按某种策略切过去。选一种策略，点「部署 v2」，用「推进」一步步放行实例；中途注入健康检查失败，看它如何回滚到 v1。

面板教会的事

把刚才操作里出现的因果关系，提炼成可复述的几条。

• 部署是产物 + 环境 + 流量切换：同一个构建产物，放进生产环境、把流量切过去，才叫部署——不是 SSH 上传文件。
• 策略决定炸多大：一次性出问题 = 全站宕；滚动 / 蓝绿 / 灰度都让流量只流向已通过健康检查的实例，把影响面切小。
• 健康检查是放行闸：每个实例必须先通过健康检查才接管流量；失败的不放行，自然不会被用户看到。
• 回滚就是反向部署：指标变差或健康检查失败时，把流量拉回上一版本；蓝绿是切指针、滚动是再换一轮实例，本质上都是一次部署。

什么时候用

出现这些信号，先想策略，而不是先点「上线」。

• CI 全绿、产物已构建 → 自动部署到 dev / staging；上生产前再选一次策略。
• 改动风险高、影响核心路径 → 优先灰度或蓝绿，留出观察窗口和秒级退路。
• 小项目、内部工具、能接受几十秒宕机 → 一次性最省事，不必上重型策略。
• 上线后指标变差（错误率、延迟、转化）→ 立刻回滚，别在流量上调试。

部署不是万能开关：如果改动涉及破坏性数据库迁移，回滚代码也救不回已写的数据——这种发布要把迁移单独拆出来做兼容与回滚预案。

怎么用

从代码合并到生产全量的最短路径。

1. 代码合并 → CI 跑测试构建出 artifact（构建产物），同一个产物推向各 environment。
2. 选策略：滚动（默认稳妥）、蓝绿（要秒级回滚）、灰度（大改动先小流量验证）、一次性（仅限能容忍宕机）。
3. 部署系统按策略逐实例替换，每个实例过 健康检查 才放行；失败的不接管流量。
4. 盯关键指标一段时间；异常就触发回滚——它是预演好的「反向部署」，几秒到几分钟回到上一版。
5. 保留每次部署的版本号、时间和可访问 URL，方便定位「这次是哪个版本带来的」。

正反例：同一份 v2，只改策略

差异只在「用哪种策略放出」，看回滚代价。