Deploy web app to staging - production with subversion

Question

We are building a web app and are almost ready to start deployment to a production server. We are using Subversion for version control and I'm now wondering what the best way would be to deploy to staging and later to production.

Right now we develop and test with 2 persons locally on our own machines and commit to our staging server which is our SVN server.

I know there is a post-commit.tmpl hook which can run a script? Does anyone know a good resource for that kind of scripts.

Any tips are welcome! We are looking for an easy way to deploy and possibly revert our code to a previous version.

Answer 1

Subversion is a version control system not a deployment system. Don't use it. Since you are doing everything manual right now (building & test) I would also deploy manually, that can also mean that you write some scripts that check the right version out from subversion and deploy it to whatever environment you want it to.

If you want to automate more, I would recommend a CI server or some sort of deployment solution for that. We are starting to use Hudson for testing and deployment (at least for the sandbox environment). We don't intend to use it for production. Because we did not check into the promotion plugin yet. When researching CI servers, I noticed that commercial systems usually offer a better support for release management.

Answer 2

There are several ways that you can do this:

Use a build server

I've heard of teams using CCNET.net or FinalBuilder Server for this. Basically, what happens is that the build script has code to push the latest build, every time somebody makes a check in. I wouldn't recommend this for production though. This should work fine for a staging environment though.

I'm not very familiar with build servers on Linux, but I know that there are a few. There's also Ant, and even Make scripts that could be used for this.

Put a working copy on the staging server

Just do a check out, and map the correct folder to be the root of the web app. Somebody on the team will have to manually update this working copy, but this gives you the flexibility to revert to a previous version if necessary.

Caveats

You'll need to make sure that you exclude the .svn folders when you pointing the website to the working copy.

I wouldn't recommend using a Subversion hook script for this. You can pretty much use any scripting engine that available in Linux to do post-commit scripts. I typed "post-commit hook script linux" in Google, and got some good hits.

Answer 3

This question is really a question about release procedures (and tools), rather than system administration, but here's my best answer:

Any recent version of Subversion takes excellent care of your configuration management needs, but, like Peter said, it's not a deployment tool. One option would be to build deployment into your regular build infrastructure (e.g 'make deploy') and manage your deployment rules alongside your code.

From a configuration management point of view, you need to keep track of everything your application needs to function, including code, external libraries (in specific versions), webserver, OS versions, etc. 'make deploy' should try to ensure all those things exist before it attempts to deploy a new version.

Tools like Hudson can also handle deployment for you, but you'll still need to tell it what to do and I simply prefer to keep my configuration management procedures as simple as possible. One example would be to let Hudson invoke 'make deploy' but store no other information in Hudson that you'd need to recover to recreate on additional machines.

How often are you going to be doing releases that need to be deployed? I would consider something along the lines of tagging your webapp into tags/ and having a post-commit mechanism that knows that tags/webapp-1.0.4 needs to be exported to your webroot. If your webapp is large, consider having the hook drop a special file in /tmp which a cronjob checks every minute and takes appropriate action on.

If you want more detailed answer, please elaborate on your release schedule, size of codebase, choice of language, OS environment and dependencies.