Ask A Question

Notifications

You’re not receiving notifications from this thread.

Move a Legacy App in Production to a local Development Environment

Travis Smith asked in Rails

I'm working with a legacy Rails app (Ruby 1.9.2 and Rails 3.2.8). The app only exists in production. There isn't a development environmnt or repo I can use to setup my dev environment. I'm on an OSX 10.13 machine and I've installed Ruby 2.1.0 and Rails 3.2.8 (farthest back I could go without installation errors). Now I'm having trouble getting the files into the proper place and starting the Rails server.

Does anyone have any tips or a step-by-step guide location for this type of situation?

Thanks!

Reply

Hey Travis,

In this situation, I'd connect to the server and pull down a copy of the code that's currently running as soon as possible. Create a new git repo and add all the code there so you've got it safely stored away on Github, etc.

You'll probably also want to make a copy of the production database and save it locally. If you import it to your local database, you'll have a copy of production data that you can use to get up and running probably a bit quicker. Just keep in mind that you'll want to make sure you don't email or charge customers from your local copy, so it would probably be good to sanitize emails and other information.

I would probably then try to setup an actual deployment process, either using something like Hatch, Heroku, or a tool like Capistrano to make sure you can deploy it safely to a separate server or something. That way you can verify that deployments work without affecting the production app.

At that point, you can try doing a deployment over the existing codebase or you may want to deploy to a new directory and point the webserver to the new directory on the same server.

So in general:

  1. Create a git repo with all the code
  2. Backup the database
  3. Setup deployments the way you'd want it going forward
  4. Do a test deployment (include a small change so you can see if it worked)
  5. Verify that code is running correctly on the server (run it on a different port)
  6. Swap the production webserver to the new deployment

I might be forgetting some things, so anyone else with ideas, please jump in. 👍

Reply

Thanks, Chris!

This takes a few things I was thinking about and ties them all together nicely.

Reply

Would you recommend keeping the dev environment as similar as possble to the current production environment to avoid errors or would it be better to try and upgrade to newer versions of Rails, etc? I'm having trouble currently trying to keep everything locally in sync with the production versions (the production Ruby version doesn't work with my OSX version, etc).

Reply

First, keep it exactly the same. You want to make sure that every adjustment you make is going to be fine in production, so don't make any significant changes.

If it's minor versions of Ruby that are different, that's fine. They don't have to be perfectly the same. Gem versions matter a lot more.

Reply

Is this a scenario where a Vagrant or Docker development environment would be a good fit? So that I could run the same version of Linux and then keep the versions of everything exactly the same as they are in production initially?

I saw your Vagrant guide and thought that might be just what I need.

Thanks again.

Reply

Yeah, Vagrant is probably what you'd want in this case. Docker is more for you to containerize your app so it could run anywhere, not necessarily for mimicking your existing production host.

You'd just want to install the same OS version as prodcution and the same packages in Vagrant.

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 81,842+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.

    Screencast tutorials to help you learn Ruby on Rails, Javascript, Hotwire, Turbo, Stimulus.js, PostgreSQL, MySQL, Ubuntu, and more.

    © 2024 GoRails, LLC. All rights reserved.