Click here to monitor SSC
  • Av rating:
  • Total votes: 6
  • Total comments: 0
Chris Smith

Deploying Your Software Shouldn’t Feel like Visiting the Dentist

19 December 2012

 It is tempting to delay deployments but, the longer the delay, the more daunting they become. Instead they can be done easier and more frequently by automating the deployment mechanism where possible, streamlining the administration, and delivering valuable, incremental features.

For a project manager like me, the process of deploying software can be fraught with anxiety and dread. I can think of several times in my career where, in the shadow of an approaching release deadline, the thought of having to deploy our application was akin to contemplating an imminent visit to the dentist. In fact, even the mechanism for getting our ‘awesome new features’ into the hands of our users felt like pulling teeth.

The temptation is to deploy as infrequently as possible, just as the temptation is to visit the dentist as rarely as you can get away with it. You know you ought to go more regularly but you fear it’s going to be really painful. You may even have a haunting memory of a previous visit that ended up with your pearly whites on the receiving end of the dental drill. Personally, my teeth ache just thinking about it.

Not keen on visiting the dentist

Instead of visiting the dentist regularly, maybe at six monthly intervals, you might find yourself making excuses and putting it off. As a result, you never get around to that check-up and only drag yourself into the dental surgery two years later, when you’ve got a cavity the size of the Grand Canyon. I know I’ve done this, fully aware of the risk that it might happen and have subsequently chastised myself when it does. Ironically, the resultant marathon stint in the dentist’s chair contributes to the haunting memories that compelled me to avoid check-ups in the first place.

In the software development world, leaving an extended period between deployments of your software is just as risky an approach as forgoing regular dental check-ups. The bigger the gap between deployments, the larger the amount of work – code changes, database schema modifications, configuration alterations – that have not been validated by your customers. The greater the functionality and code delta between deployments, the more likely it will be that the new release has broken something serious, unleashing a horde of pointy-fanged bugs that are going to eat your time and leave your plan for the next development iteration in tatters.

Instead of worrying about the huge list of changes you’ve build up between releases, you can feel better by simply assuming that you got your decisions right. You can assume that you made a good call regarding which new features to add, how to design the user interface so it is ‘easy to use’ and whether the user is going to like it more when it’s drawn in mauve. However, you can only prove you got that stuff right by giving it to your users. The bigger the gap between releases, the more development effort you are gambling has gone ‘right’. When the release is finally out, your users are going to tell you if you got it right through sales figures, raised bugs, direct feedback and even social media. So, if you got that decision on drawing it in mauve wrong, that’s when the pain really starts.

Back in the dentist’s chair, the longer the gap between check-ups, the more food you’ve eaten between visits and the more unchecked bacteria builds up on your teeth. You’re assuming that you are brushing your teeth right and that your reticence to floss has not impacted too much on your dental hygiene. However, if you got that wrong, that’s when things get painful.

So, it seems sensible to deploy pretty often, right? The problem is, and where the metaphor decays (sorry), is that software development teams feel that deploying is harder than visiting the dentist. Deployment processes can be a significant overhead, especially when compared with dialing a phone number and turning up at your local dental surgery. There are code reviews to undertake, test plans to execute, documentation to write, numerous environments to update and administrative tasks to complete. Development teams would be forgiven for dreading a deployment process that consumes days of their life and invariably raises difficult questions and forces uncomfortable decisions.

Really, deploying should be less onerous, easier, cheaper and quicker than going to the dentist. In order to achieve this state, software development teams need to do three things:

  • Automate their deployment mechanisms,
  • Re-evaluate and streamline their administrative practices and processes,
  • Explicitly focus on delivering valuable, incremental features to their users.

Doing all that at once can seem daunting, so the best thing that a software development team can do is to start to make things better ‘now’. Even if they can only automate a small part of their deployment mechanism at the moment, or cut out a small section of their release documentation, or decide not to test an underused area of the application. As they chip away at the overhead of deploying, the closer they’ll get to the benefits of regular user validation and risk mitigation outweighing the time and effort cost. Plus, once you start deploying often, everyone will start to focus on removing the remaining overhead.

We’ve been making a concerted effort to apply an agile software development approach at Red Gate since mid-2008, but it was only last year that we challenged our development teams to deploy more frequently. In our efforts to meet this challenge we’ve made some mistakes and we deployed some releases that we shouldn’t have. However, we made incremental improvements, we removed or worked around bottlenecks in our deployment process and we added mechanisms that allowed us to spot problem releases.

The hand of deployment

It is worth mentioning that the single most important improvement we made was giving every team the power to deploy their software at the press of a button. Red Gate’s excellent DevOps team delivered a bespoke automated deployment tool that allowed us to do this. It involved significant investment on Red Gate’s part but it was worth it, as it means that my team can deploy our product – Deployment Manager – as often as they like. In effect, we are only limited by our ability to break work into discrete, valuable chunks and our users’ tolerance of software updates.

Software development teams should deploy as often as they can. Every month. Every sprint. Even every day, if your users would be happy with that. Reducing the gap between deployments reduces the amount of unproven changes that have not been validated by your users and lowers the risk of a single release having a plethora of pointy-fanged bugs ready to eat your time. Also, it means deployments will stop feeling like trips to sit in the dentist’s chair.

This article was originally posted on the Deployment Manager blog.
The next step for Deployment Manager is to improve support for SQL Server deployment.
Join the SQL Database Deployment Beta to get access to new features ahead of their launch and give feedback on how Deployment Manager could be improved.

Chris Smith

Author profile:

Chris is a Project Manager at Red Gate. He is currently working on the Deployment Manager project helping the talented development team working on that product to continuously improve and regularly deliver valuable software to our users.

Search for other articles by Chris Smith

Rate this article:   Avg rating: from a total of 6 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.
 

Top Rated

We don't need Source Control: we're Database Developers
 As part of our long-running series of articles where we ask working database developers how database... Read more...

The Proposals Conundrum
 When you work for a small software development (or any services) company, one of the major challenges... Read more...

David Heinemeier Hansson: Geek of the Week
 Ruby on Rails, the open-source web application framework, grew out of David Heinemeier Hansson's work... Read more...

Alex Payne: Big in the IT Business
 Alex Payne worked on developing Twitter for three years. When he started, it was a small side-project:... Read more...

Seth Godin: Big in the IT Business
 Seth Godin has transformed our understanding of marketing in IT. He invented the concept of 'permission... Read more...

Most Viewed

The Future of Reflector
 Simple Talk asked freelance writer Bob Cramblitt to sit down with the two people behind the agreement... Read more...

Linus Torvalds, Geek of the Week
 Linus Torvalds is remarkable, not only for being the technical genius who wrote Linux, but for then... Read more...

Bad CaRMa
 From hope and euphoria, to desperation, firings and the ultimate demise of a company. Tim Gorman charts... Read more...

Driving up software quality - the role of the tester
 Have you ever wondered what a software tester does? Helen Joyce, test engineer at Red Gate software... Read more...

Don Knuth and the Art of Computer Programming: The Interview
 Fifty years after starting the 'Art of Computer Programming', (TAOCP), Don Knuth is still working hard ... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.