Subversion Repository Architecture for Separate Dev/Test/Prod Environments

Question

Hi everyone, I've been tasked to build up a subversion system for dev/test/prod environments, and was wondering if anyone has any experience with a similar environment or suggestions.

We build and configure a number of systems that are a combination of scripts and complex configuration files for 3rd party products. Due to this, it is impossible to restructure the layout the config files and paths because we don't control the 3rd party system code (i.e. if the system wants a config file in a certain place, that's where it has to be).

We work with a dev/test/prod methodology, but it is a little more complex than that. There is a complete physical environment for each stage. Due to this, each stage needs some alterations that need to occur to make it work in that environment. All development must occur on the development server, testing on the test server then we have the production servers.

With this setup, it is impossible to check out a copy of a project to your own workstation make some changes , test them, and the commit them back. This stuff will only work on a dev/test/prod server (i.e. things are tied to specific hostnames and IP ranges).

So, as I see it there are 2 options:

Option 1

Do the normal trunk/branches/tags structure. Then have a script as part of the build that would make all the changes specific for the dev/test/prod environments.

For example, you'd commit all code to the trunk as usual, then when you're happy with it you copy it over to a release tag. Then in the test environment, you check out the latest tag. This includes a 'setup' script.

Then the script is run manually (or via SVN hook) and it would detect that you're on the test server and make the changes accordingly.

Problem with this way is that svn diffs etc. are going to show modifications to the files that get the alterations. The advantage is that it's (fairly) simple.

Option 2

Make test/prod branches and trunk as the development:

project
  trunk
  branches
    test
    prod
 tags
    v1.0
    v1.1

The idea being that the dev server points to trunk. When we're happy with the changes we make a new tag. Then we merge it on to branches/test. This will already have the changes necessary to make it work on the test server. We then do the same for prod when testing is complete.

From what I can see, the advantage of this approach is that there is no need for fancy hook scripts, and we can have more complex differences between dev/test and dev/prod that SVN should be able to handle better via merging?

Just looking for some input, suggestions, experience etc. We are tied to Subversion and extra tools are unfortunately a no-go.

Thanks (sorry about the length)!

Answer 1

Honestly, I think either option is perfectly viable.

However, I slightly prefere your first choice, reason being that once you start getting 'known differences' between certain branches you have to start using brain power to work out "is this a difference between test and prod that's supposed to be there?"

With option 1, you're always, definitely, working & building out of the same branch, same code, so you just wont get any of this drift. Anytime anyone makes a change, they can see immediately (if they want to), wether this will impact specific environments before they merge to it.

So it's basically an argument to keep things simple. It's the same argument if you brand your software according to your customer. Either method is viable, but I'm leaning towards option 1.