Mar 10 2009
The SharePoint Adrenalin Moment
I’ve been developing with SharePoint for about 9 month now, and by developing I don’t mean airy-fairy SharePoint Designer drag-and-drop, I mean proper getting your hands dirty in code because SharePoint doesn’t have an *cough* out of the box *cough* feature that does what you want.
Mostly, deployment is done in two stages, firstly to a UAT box and then to a Live box. Obviously the most efficient way to do this is to bundle your features into a solution which can easily be deployed onto any number of machines. But, it does mean you have to make sure you’ve got everything right. Untangling mistakes in your code can be a right royal pain in the arse.
By the time you’ve developed your solution, tested it out, deployed it to UAT and tested it again you should be fairly confident that when you come to deploy it on the Live server things should go pretty smoothly. And, touch wood, to date things have gone smoothly.
But I still can’t get over that rush of adrenaline that comes with clicking “Activate Feature” after deploying the solution on Live. In the second or two whilst the page waits to reload my mind runs through all the possible things that could go wrong and how long it would take me to unpick the changes my code might have got half way though. Then the page finally loads…..
….. “Feature Activated”, phew! Time for a lie down to clam my nerves.
Given my mainframe background, it always feels wrong when there’s a UI to deploy something live! Don’t ask me why, but it always feels more ‘serious’ when it’s done in script
When I was more involved in final deployment than I am now, there was a strict division of duties between development and deployment. No-one who developed the code was allowed to deploy it to a live system – there was a strict sign-off procedure where devs would put things in UAT, and only the operations dept (who after all get called out at 3am if something fails) could move it to a live server after formal sign-off from acceptance testing. It meant we had to provide completely automated procedures for deploying things, which usually meant scripts since often many things needed doing (db structure alterations, data migration, components on multiple servers etc). Most of the time you knew when a release was going live, but you didn’t actually do it – I think that’s actually worse in many ways!
You would dread seeing someone from the ops department walking towards you that day…
Normally, at the client I was working at yesterday, I do hand over the solution for deployment to the live server but the person that normally handles deployment to Live is away in Peru for three weeks.
SharePoint solution deployment does sound pretty much like mainframe deployment. All changes are in XML configuration files and code is in .Net assemblies, it’s just that you have a web front-end to click “Go”.