作为常年用Capistrano部署Rails应用的老鸟，这个场景我太熟悉了——分批部署时新旧版本共存，用户一会儿看旧版一会儿看新版，体验糟透了，搞不好还会因为数据兼容问题出bug。下面分享几个我实际项目里验证过的靠谱解法：

1. 原子符号链接切换（首推方案） #

Capistrano默认用符号链接指向当前版本，但默认流程是部署完一台就切一台，这就是问题根源。我们要改成所有服务器先完成部署准备，最后统一切换符号链接，做到"原子更新"。

具体配置步骤：

• 打开你的deploy.rb，调整部署流程，把符号链接切换的步骤挪到所有服务器都完成代码拉取、依赖安装、资产预编译之后：

  # 移除默认的单服务器symlink步骤
  Rake::Task['deploy:symlink:release'].clear_actions
  
  # 重新定义symlink任务，让它在所有服务器上并行执行
  task 'deploy:symlink:release' do
    on roles(:all) do
      execute :ln, '-sf', release_path, current_path
    end
  end
  
  # 确保在所有服务器完成updated阶段后，再执行统一切换
  after 'deploy:updated', 'deploy:symlink:release'
  

  这样所有服务器会先把新版本代码准备好，最后同一时间切换current符号链接，用户几乎感觉不到版本变化，完美解决体验不一致的问题。

2. 配合负载均衡器做滚动更新 #

如果你的服务器前面有Nginx、HAProxy这类负载均衡器，那可以用"先摘流量再部署"的方式：

• 部署某台服务器前，先把它从负载均衡的可用节点池中移除，确保没有用户请求打过来；
• 部署完成后，再把它加回节点池，接着处理下一台服务器。
• 你可以自己写脚本集成到Capistrano，或者用现成的capistrano-loadbalancer插件，示例配置大概是这样：

  # 部署前移除目标服务器
  before 'deploy:starting', 'loadbalancer:drain'
  # 部署完成后重新加入
  after 'deploy:finished', 'loadbalancer:enable'
  

  这种方式不仅能避免用户看到新旧版本，还能在部署过程中做健康检查，确保服务器没问题再放回流量。

3. 会话粘性（临时应急方案） #

如果上面两种方案暂时没法落地，会话粘性可以当临时补丁：

• 在负载均衡器上配置基于Cookie的会话粘性，让同一个用户始终访问同一台服务器。
• 这样用户要么全程看旧版，要么等服务器部署完后看新版，不会中途跳版本。
• 但要注意：这只是掩盖问题，不是根本解决——如果服务器出故障，用户还是可能被分配到其他服务器，而且会话粘性也会影响负载均衡的效果，长期来看还是推荐前两种方法。

额外提醒：数据库迁移要兼容 #

最后别忘了，代码切换没问题了，数据库迁移不兼容照样出问题。一定要遵循"先兼容、再部署、后清理"的流程：

1. 先部署一个兼容新旧数据结构的版本（比如新增字段设为允许为空，不删除旧字段）；
2. 执行数据库迁移；
3. 再部署完全依赖新数据结构的版本；
4. 最后清理不再使用的旧字段或表。
   这样即使切换过程中有少量用户访问旧版本，也不会触发数据库错误。

内容的提问来源于stack exchange，提问作者Bình Trương