I thought I would share an experience with you all...

Recently I had a deployment go out into production. At the time, the build went very smoothly; no issues with the deployments of the websites themselves, the db schema update and post update scripts went through without a hitch. Wonderful!

Or so I thought.

Came in the next morning (and isn't this how it always happens?), and about 9am we started getting suspensions in our BizTalk orchestrations. 'Access Denied'. Hooray for 401 errors! An awesome little birdie informed me of a very basic mistake and left me to figure it out. So I trawled through our staging folders, checking and double checking the folders and files. Then I saw the answer to this problem.

"Configs".

Oh yes, Id forgotten to copy the relevant production configs (specifically these ones defined what service accounts had access to the web sites) into the staging code. The parent web.config was OK, but the inner ones within the web sites had the dev service accounts listed in the file. Silly me.

So, an emergency change (blurgh) later and we had the proper configs in production, and all was (relatively) well.

Once the dust had settled, I decided to fix things so we never, EVER had this sort of issue again. And so, this brings me to the title of this entry - Automation is your friend. I modified our deployment script to copy the configs to the staging folder, and THEN copy the code to the relevant production servers. Problem solved :)

This got me thinking about automation in general, and how amazingly wonderful it is. Repeatability is what we, as developers, should aspire to. Because repeatability equals successful tasks, which means less time troubleshooting random or unexpected issues. Just for fun, I thought Id list some of the automation tools we use:

  • CruiseControl.NET (Continuous Integration)
  • Powershell (IIS/BizTalk Deployments)
  • Batch Files (Bits and pieces that dont quite fit, although the more I use Powershell, the more I realise that batch files are reduntant in my eyes)
  • SQLCMD (For SQL Script execution)
    We also recently started using SQL Stored Procedures to automate some of our basic scripting tasks, as our main application is very reference-data driven, so when we are creating new entities, the amount of SQL we need to script is dramatically cut down. This is the second most awesome thing Im proud of in terms of what we've introduced to make our lives easier.

The most awesome thing is Powershell. Words cannot describe how much I fricking love this tool, and the power it gives you over your PC. While we are currently only using this for IIS and BizTalk deployments, the utter potential of this scripting language, where EVERYTHING is an object (this is where it has a HUGE advantage over normal batch file scripting) and can be accessed as such is mind blowing. I spent a good few days learning the basics before creating my first IIS deployment script, and it worked perfectly and (in my opinion) is alot more readable than batch files (its a weird thing to say I know, but hey).

Its amazing how many developers dont use automation in their environments. The ability to quickly (but sometimes painfully, depending on which CI tool you use) create a preview environment with a copy & paste job is amazing, and adds value to the client like you wouldnt believe. The ability to be dynamic and reactive to a client's needs is essential in this day and age, and automation is a huge step forward towards those wonderful ideals.

CruiseControl.NET is our CI tool of choice, and to be honest Im not a big fan of it. Its completely XML driven (which can be a blessing or a curse depending on your taste), which makes it a bloody pain in the ass to troubleshoot sometimes. Saying that though, I do have a pretty decent handle on it now. But thats mainly a result of blood, sweat and tears trying to figure these issues out, as the log files arent always helpful. Ive recently introduced to a tool called psake. Psake is a powershell driven (yay!) scripting tool to create build scripts, without the messy XML. The syntax is clean and straightforward, and after my previous weekend of troubleshooting a rogue msbuild task (and trawling through rather large XML error logs), Im seriously considering the switch. This, in combination with a CI server called TeamCity (by the JetBrains mob) is my next personal project of investigation to see if its appropriate for our team.

So next time you have a tedious, repetitive task that needs to get done consider automating it, as which ever automation tools you choose to use its definitely a step forward from managing (or attempting to manage) everything yourself, manually.

Night all :)