How can I manage production/test/development configuration info using subversion?

Question

I'm working on a combined web/client app that has branches for production, test, and development. I'm using svn post commit hooks to deploy updates to the production and test servers. The client app needs to point to different urls depending on production, test, or development. How can I manage this using subversion? Options I've thought of are:

Option 1
Keep a file with branch-specific details that is never merged between branches.

This option is easier from a build management perspective but is prone to error since I have to remember to ignore that change every time a merge is performed.

Option 2
Create production, test and development builds of the client no matter which branch, and rely on svn hooks to pull down the correct binaries.

How do you handle this? Any better ideas?

Answer 1

Our application keeps a separate directory with configuration files for each deployed environment. When the build server runs the task to deploy for a specific environment it knows which directory to pull the config files from. The pointer to the correct directory is part of the build definition for the build server (in our case Pulse). Which branch the code is built from for that Pulse task is also part of the task specification. This makes the deploy server decision independent from the branch so as we release new versions servers and databases can be repurposed.

+ dev-server
+---jdbc.properties
+---build.properties
+ test-server
+----jdbc.properties
+---build.properties

The config files are not branched with the rest of the application (a sibling of trunk, branches, etc...). They have their own spot in the svn tree and are pulled in the each branch as a Subversion external definition.

We do it this way because each branch may have many servers deployed from it (dev, test, build, automation, etc).

Answer 2

My preference is to not check in project specific configuration files to the source control but instead keep the contents of environment variables and other configuration aspects in a common folder (in source control). The config files are then generated as part of the local build, build automation, or deployment scripts depending on what a given project, solution, environment might need at a given time. This can be done with simple text files, xml templates, or something more complex like the spark view engine depending on your needs. You can also do this by convention if templating is more complex than you need (and it normally is). This way, no matter where you are deploying code too you can define an environment specific configuration.

An example of by convention is to define custom config sections in your primary config files (web config, app config, etc.). You can then store a connection-strings-development.config, a connection-strings-integration.config, a connection-strings-testing.config, a connection-strings-pre-production.config, and a connection-strings-production.config in your primary source (or common folder). The build process would then drop the appropriate connections string config file renaming it to simply connection-strings.config.

Generating by template you would also have custom config sections with the same environment specific config files but instead of renaming on deployment you can simply rewrite a section of the base config file directly with the appropriate config file name.

Keeping your config files chunked up by environment though provides you with a great deal of flexibility especially once you start managing many sites that use the same or similar style of configuration. No matter what though, your configuration should be dictated by some aspect of your automated environment!