tags:

views:

433

answers:

2

would you move files from DEV to Prod or QA to Prod? How do you use svn export in your environment? Any handy scripts that you can share?

I looked at other threads but they do not have enough information.

I want to know the best practice to push app/db updates to production environment from QA or DEV or Staging. This is a LaMP environment.

A: 

There are many ways to do this, depending on the application and environment.

In a LAMP environment, I often create an account on the production server and check out the development files as if I were developing there, do the build, and then deploy locally.

  1. The application may be deployed as a non-privileged user.
  2. The user account may possibly be deleted after deployment for security reasons.
  3. This is usually a pretty easy method if you are comfortable with doing things remotely, say by ssh.
Glenn
but, say you don't have access to production environment.
CodeToGlory
If you don't have access to the production environment, then you must have specifications for it. Without knowing what these are it is difficult to answer your question.
Glenn
+2  A: 

Well, first off, I wouldn't move files directly from dev or qa to production. Like your question implies, I would deploy a tagged release from your SCM (subversion, in this case) directly to your respective environments.

Broadly speaking, I would recommend looking in to a specialized deployment tool, like Capistrano. There is a bit of an up-front time investment to learning the tool and setting up your deploy scripts, but the power of being able to say "cap deploy qa" or "cap rollback production" later on to change your running version in a matter of seconds will a) more than repay that initial time investment, and b) save your butt when things go wrong.

To directly address your question, though, if you were doing it by hand I would recommend a process something like this (with sudo inserted where necessary):

  1. Have a /opt/my_app/ directory with multiple subdirectories containing different versions, and a "current" symlink to whichever one is live.
  2. Point your apache configuration to /opt/my_app/current
  3. To roll out a new version, run something like "svn export https://my_repo/my_app /opt/my_app/1.2.3" (assuming the new version was 1.2.3).
  4. Change the symlink: "rm /opt/my_app/current; ln -s /opt/my_app/1.2.3 opt/my_app/current"
  5. Restart Apache or other processes as necessary.

Database updates are a more interesting question. Personally, I love Rails's Migrations for this. If you were doing it by hand, you might include a couple shell scripts in your project to update the db and roll it back, respectively, but keeping those versioned correctly would be sort of tricky, since they would be specific to only one particular version. I'd recommend using an existing system like Migrations (which can be used separately from Rails - I've seen it as the only Ruby component of some Java-based projects), or asking that as a separate question.

John Hyland
Thanks for your response. Makes a lot of sense.
CodeToGlory