Question

I’m implementing a system whereby changes are committed to a subversion repository. It is desired that these changes immediately be pushed to a remote server (preferably without .svn litter).

I’m looking at the svn export command in a post-commit hook but does this push only the changes? ANd how does it authenticate with the remote server?

Answer 1

Are you sure you want to automatically push each and every revision of Subversion to a server? I would think you’d like to do some testing, and pick and choose the revisions you want to deploy.

Even if you could get a post-commit hook to work, it wouldn’t be a good idea. The user would be stuck waiting for the hook to complete before they could continue with Subversion. Basically, it will look as if Subversion is taking 10 to 20 seconds for each and every commit (that is if you could deploy your entire repository in only 10 to 20 seconds!)

The best way to handle this is to use Jenkins. It takes approximately 30 minutes to install Jenkins and to get it up and running. (It’s a web service, so you access it through a browser). It will take you another 30 minutes to get the deployment working.

Yes, I’m asking you to install a whole new webserver, but it shouldn’t take you more than an hour or two to get everything working the way you want. That’s going to be a whole lot faster than testing and getting a post-commit hook to work.

Jenkins will watch your Subversion repository. When it detects a change, it can run a deployment script. For example, do an rsync to the server. Maybe even taking the server down before implementing the changes.

And there are many advantages to this too:

• Jenkins will keep an entire record of all the deployments.
• Jenkins can let you know if a deployment succeeded or now.
• You have an easy to access record of your change history.

And, you can expand this functionality. For example, I mentioned that it might not be a grand idea to do a deployment after each change. Maybe you can setup a test server, and have Jenkins deploy to that and run tests. Jenkins can report the test results right inside of Jenkins. If all the tests pass, then have Jenkins deploy to the production server.

Or, maybe you’re talking about deploying to a test server and not to the production. Fine, have Jenkins do the deployment to the test server and run the tests. You can then examine the tests, and then have a one button deployment to the production server right inside of Jenkins.

Maybe you only want to deploy at certain times when the server isn’t so busy. You could setup a second job in Jenkins that only runs at 2:00am when there aren’t so many users on your system.

---

Nor, do you have to use Jenkins. There are a lot of other continuous build systems out there. A few open source ones, but some pretty good proprietary (i.e. costs money) system