7.3 部署流程与版本管理

7.3 部署流程与版本管理

本节摘要：第三关：定班期。镜像标签纪律、环境晋升通道（测试到生产的单向水流）、滚动更新与一键回滚。本节回答一个生产级问题：怎么换版本不出事——以及出事后怎么体面地退回去。

换版本是高频操作，出事也出在换版本上

部署不是年度大戏，是日常班期——成熟团队一天发布多次。频率越高，流程质量越致命。生产事故的统计里，相当比例的故障不是代码问题，而是版本管理混乱：生产上跑的不知道是什么版本、想退退不回去、"最新"标签在部署前夜被人推过。本节把版本与部署的规矩立清楚。

标签纪律：版本的命名法

第 3.2 节讲过"生产用精确标签"，本节把它扩展成团队纪律。推荐的三级标签法：

# 三级标签：一个构建，三个名字各司其职
docker tag registry.example.com/team/myapp:${GIT_SHA} registry.example.com/team/myapp:1.4.2
docker tag registry.example.com/team/myapp:${GIT_SHA} registry.example.com/team/myapp:1.4
docker tag registry.example.com/team/myapp:${GIT_SHA} registry.example.com/team/myapp:latest

# 1.4.2   精确版：永久不可变，回滚与审计的锚点
# 1.4     次版本：随补丁漂移（1.4.2 -> 1.4.3），配置里可写，方便收补丁
# latest  便利别名：只给本地开发用，生产环境禁用
​

配套两条铁律：已发布的精确标签永不复用（同标签推不同内容是版本灾难之源）；部署清单里出现 latest 即算事故隐患（review 时直接打回）。纪律有了，环境晋升的通道才干净。

环境晋升：单向水流

健康的部署流水线像水渠：镜像只能单向晋升——开发构建，测试验证，生产接收。反向操作（生产缺什么补丁直接在生产上手工改）是腐蚀渠道的开始。容器化的晋升通道极其简洁：

# 测试环境的声明（compose.test.yaml 覆盖文件）
services:
  web:
    image: registry.example.com/team/myapp:1.4.2    # 测试钉精确版
    environment:
      - APP_ENV=testing

# 生产环境的声明（compose.prod.yaml 覆盖文件）
# services:
#   web:
#     image: registry.example.com/team/myapp:1.4.2   # 测试验收过的同一只箱子
#     environment:
#       - APP_ENV=production
​

测试验收过的镜像原样进生产——不是"重新构建一个类似的"，是字面意义上同一只箱子（同一哈希）。环境差异只出现在环境变量与覆盖文件里。这就是"在我机器上是好的"这句话在生产语境的终结形态：生产跑的就是测试跑过的那只箱子。

滚动更新：不断航的换箱

生产换版本的节奏学。小流量场景的标准动作是三步：拉新、起新、停旧（新箱子验证通过再放流量）。演示一遍：

# 生产机上的换版本三步（以 1.4.2 升 1.4.3 为例）
docker pull registry.example.com/team/myapp:1.4.3

docker run -d --name myapp-v143 \
  -p 8081:8000 \
  --env-file prod.env \
  --restart unless-stopped \
  registry.example.com/team/myapp:1.4.3

# 新箱子旁路验证（旧箱子还在 8080 服务着，业务不断）
curl -s -o /dev/null -w "%{http_code}" http://localhost:8081/health
# 200   <- 新箱子健康

# 切流：调整前置代理把流量导向新泊位（或直接换泊位映射）
docker stop myapp-v142 && docker rm myapp-v142
docker run -d --name myapp-v143 -p 8080:8000 \
  --env-file prod.env --restart unless-stopped \
  registry.example.com/team/myapp:1.4.3
​

Compose 场景更省事——改声明里的版本标签，一条命令滚动重建（6.3 节的差异机制自动只动该动的箱子）。多副本、跨机器的零停机滚动，那是自动化港区的看家本领，7.5 节眺望。

回滚：体面的退路

部署质量的真实标尺不是"能不能发"，而是**"能不能秒退"**。容器化把回滚变成了几乎免费的动作——退回旧版本就是"用旧标签重新起吊"：

# 回滚：把声明里的标签退回上一版，重申期望
docker compose down
# 修改 compose 文件中 image 标签 1.4.3 -> 1.4.2（或用上一版配置文件）
docker compose up -d
# 或者不借助 compose 的直接回滚：
docker run -d --name myapp-rollback -p 8080:8000 \
  --env-file prod.env --restart unless-stopped \
  registry.example.com/team/myapp:1.4.2
# 旧标签还在堆场上（精确标签永不复用保证了这一点），秒级退回
​

回滚的可靠性完全由标签纪律兜底：精确标签不可变保证了旧版本永远原样躺在堆场；数据卷独立于容器（第 5 章）保证了退版本不动数据。两章的功夫在这里合流——这就是体系化学习的回报时刻。唯一的复杂点在数据库结构变更：回退应用版本前要想清楚新版本是否改了表结构，这一层的回滚预案属于应用架构课的范畴，此处立牌提示。

最后给部署节奏一个务实建议：变更窗口固定化。哪怕技术上随时能发，也把常规发布集中到固定时段（如工作日上午），让"最近改过什么"有清晰的时间锚点——故障回溯时"昨夜十点发过版"这条线索，价值远超它的维护成本。紧急修复走快速通道随时可发，但同样要在发布台账里补记一笔。

本节要点回顾

• 三级标签法：精确版不可变（审计与回滚锚点）、次版本随补丁漂移、latest 禁止进生产。
• 已发布的精确标签永不复用——版本灾难的头号预防针。
• 环境晋升单向水流：测试验收的镜像按哈希原样进生产，环境差异只在覆盖文件。
• 小流量换版本三步：拉新、起新旁路验证、切流停旧；Compose 场景改标签重申期望即可。
• 回滚 = 旧标签重新起吊，秒级完成；数据库结构变更是回滚预案的独立课题。

班期定了，退路修了。下一节备应急预案：故障来了怎么分诊。