That I am including this in the rant category I will leave as an exercise for the reader to determine the cause.
Let’s leave aside all of things (SOLID principles for instance) that should be considered as basics in any software development process, I want to talk about configuration.
App.config. Web.config. Within .NET, almost any project is going to involve having values that will need to change as you deploy code from environment to environment (DEV, DEVINT, QA, PREPROD, PROD…do any of these sound familiar?).
Except they shouldn’t.
I want to advance as a general principle/goal that you should never, ever need to change any values related to configuration as part of your deployment process. Certainly not manually, and hopefully never even as an automated process (based on string matching for instance).
I started out my professional career as the head of an Operations Department. Working on ways to automate deployments was always a central goal. Why? Because any step that requires manual intervention is a perfect candidate for something to be screwed up. The guy who knows the magic combinations is out on vacation. The document listing the required changes is out of date. The up-to-date document will contain a typo.
None of this should happen. As always, there are areas where I’m sure this is harder to do than others. As technology changes, there will perhaps be cases where it isn’t possible to leave config values untouched. But for the most part, it should be possible.
SQL Connection strings? Use an alias. I typically create an alias called ‘Connect’ in every environment, and then set all connection strings to use that as the server name. Sure, you still have to manually create the alias in each environment, but it is a one-shot deal.
There are many other places that you can set ‘alias’ type variables. Environment variables and the Registry are obvious places. Need to have a SQL connection string that has to have SQL authentication? Instead of putting that in the config file, have code that reads from an encrypted registry key instead.
WCF endpoints, MSMQ names, file shares…okay, what about file shares? The QA server has a different path to where the outputted file needs to go from what you DEV against. Use the hosts file. Create a clearly non-standard definition in your hosts file that says that ‘Connect’ means ‘T174WBlah’.
And so on and so forth.
We/I certainly didn’t do this perfectly back in 2000, but we did do this back then, so there is no reason why it can’t be done today. Watching a software project hit a wall because the code that works in DEV doesn’t work in any other environment because no one can get all the manual config file changes down perfectly in a deployment is *painful*.
Again, it is a goal that might not always be perfectible. It takes iterations of improvement to find all the weak points.
But for the love of God, with not a lot of effort, you can eliminate almost all configuration issues across any environment in your, well, environment if you ‘think backwards.’ If it helps, use config values that seem stupid. Make the server name ‘Steve’ and then figure out how the config value stays ‘Steve’ from DEV to QA to PROD without needing to be changed, and the code still works. You can do it.