Question

Due to limited resources, I would like to implement the following on a single server currently running our production website. The goal is to implement version control and a testing server whilst still maintaining as secure a server as possible.

1. Setup a Subversion repository using
   Apache and SSL and a second virtual
   host to act as our test server using
   a different dns name and port.

2. Import production site into the repository and then checkout the files in both the production and test Document Roots.

3. Create a post-commit bash script to
   run an update on the test working
   copy and depending on whether a
   commit is labeled with a certain
   keyword, also run an update on
   production working copy.

I’m sure there will me some small implementation details I have forgotten, but is this a good strategy, ignoring any performance hit on the server? Anything I am missing?

Answer 1

I would advise against an automatic deployment to production based on a keyword in a commit message. It will be too easy to mistakenly push code to production and too difficult to determine when/why it happened.

I would prefer to see you write a script that can be executed manually whenever you are ready to push to production. This script will tag the code and export to production based on the tag. This will allow you to pull that tagged revision whenever you want and gives you a starting point if you need to create a branch for production support while you are in the middle of developing new functionality for your next major release.

PS. Unless you are pushing every commit to TEST, you should be tagging your push to test as well.