使用Capistrano 3部署Rails至Staging与Production的相关问题咨询

云上老周

2026-5-15

Rails 4.2 单人开发部署最佳实践

Hey，针对你的Rails 4.2.6 + Ruby 2.2.4应用部署问题，结合你独自开发维护、两台DigitalOcean服务器的场景，我给你梳理下清晰的方案：

一、正确的部署顺序：必须先Staging再Production

毫无疑问，先部署到Staging环境完成全量测试，确认没问题后再推到Production。原因很简单：

Staging是Production的镜像环境，能帮你提前发现本地测试覆盖不到的问题——比如数据库迁移兼容性、第三方API的环境配置差异、文件存储路径权限、服务器依赖版本冲突等。
具体步骤：
- 本地开发完成后，提交代码到Git仓库的开发分支
- 部署代码到Staging服务器，运行所有自动化测试（单元、集成测试），再手动验证核心业务流程
- 确认Staging环境完全正常后，再将相同的代码版本部署到Production
- Production部署完成后，做快速的冒烟测试（比如访问首页、核心功能接口），确保服务正常启动

完全没必要设置独立仓库，反而会增加代码同步的维护成本，容易出现版本不一致的问题。更合理的方式是：

用单一Git仓库+分支管理：
- main（或master）分支：仅存放经过Staging验证的、可直接部署到Production的代码
- develop分支：日常开发的主分支，所有功能开发完成后合并到这里
- 可选staging分支：从develop合并而来，专门用于Staging环境部署（如果需要更严格的预发布隔离）
部署时，Staging拉取develop或staging分支，Production拉取main分支即可，确保代码流转清晰。

针对单人开发的场景，简化但不马虎：

采用轻量的Git工作流：推荐GitHub Flow，流程简单易执行：
1. 从main切出feature分支开发新功能
2. 开发完成后，合并到develop分支
3. 部署develop到Staging测试
4. 测试通过，将develop合并到main，部署到Production
强制自动化测试：每次提交代码前，本地跑一遍单元测试；Staging部署后，跑全量的集成测试+E2E测试（比如用Capybara），避免带着Bug上线。
锁定依赖版本：严格维护Gemfile.lock，Staging和Production环境部署时，都运行bundle install --deployment，确保依赖版本完全一致。
隔离敏感配置：用Rails的config/secrets.yml或者dotenv gem管理环境变量（比如数据库密码、API密钥），Staging和Production的配置文件分开存放，绝对不要把敏感信息硬编码到代码里。

这些细节很容易踩坑，一定要注意：

数据库迁移要谨慎：Staging先执行rails db:migrate，确认迁移无问题后，再在Production执行；Production迁移前，务必先备份数据库（比如用pg_dump或DigitalOcean快照）。
应用服务器重启：部署完成后，必须重启应用服务器（比如Puma、Unicorn），确保新代码生效。用Passenger的话，可以简单执行touch tmp/restart.txt触发重启。
日志监控：Staging和Production都要定期查看日志（tail -f log/production.log），及时发现错误；可以配置日志轮转，避免日志文件过大。
定期备份：Production的数据库和用户上传的附件（比如public/uploads）要定期备份，备份文件最好存到外部存储（比如DigitalOcean Spaces），不要只存在服务器上。
环境一致性：Staging和Production的服务器环境要完全一致——Ruby、Rails、数据库、Web服务器的版本都要相同，避免出现“Staging正常，Production报错”的诡异问题。

内容的提问来源于stack exchange，提问作者Milind