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?
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!