Tags: , , , | Categories: Articles Posted by RTomlinson on 10/25/2012 6:28 AM | Comments (0)

I'm still amazed that there are software companies out there that are delivering software far too infrequently. Most of the time there are no valid excuses for monthly or quarterly (or more) deployments. If the business isn't demanding a faster time to market then the Dev/Operations team should be continuously evaluating and improving their processes for the benefits that continuous delivery give.

Historically writing, testing and delivering software have been scary for me and the teams that I have worked in. In the past I've worked in teams where we would write a month's worth of software, have a test team test the release, fix those bugs, test again and then release. The process was long and painful and we dreaded the release and the following few days were nervous ones.

Since then I've been on a path to continuous delivery and work with a great team who see the value in doing so.

Why releasing often is so important

Here's just a few points:

  • Continuous feedback - With every check-in we build and run tests (unit and other variants) and continue in our deployment pipeline. The sooner developers code is integrated, compiled and tested the sooner we can fix issues. This also holds true for deployments.
  • Problems are localized - When problems do occur it's usually pretty easy to spot if only a few changes are being deployed at any one time. With larger deployments, if the shit hits the fan, then it's going to take longer to diagnose and resolve.
  • Competitive advantage - Not much explaining here. If you can release features incrementally to your customers the advantages are two-fold. They benefit from the features themselves and they benefit from a learned user experience. That is to say that smaller changes are easier to adapt to than larger rollouts of features.
  • Deployment confidence - The more you do something the more confident you get in doing it. The same goes for most tasks and skills. 

How often is often?

This really depends on many factors but when you have changes waiting daily there really isn't any reason not to release daily. There are many release strategies that you should consider. The most common are release branching or releasing from trunk. In the case of the latter it is common to use feature toggles for unfinished or unreleasable code but this is too big a subject so I'll save for another post.

At tombola, we release daily for each country. Everything is driven from our TeamCity build server that runs custom MsBuild scripts to compile, transform configs and deploy (using MsDeploy) to several environments (including the cloud). 

teamcity build

For live deployments we do blue/green deployments. That means that we hit the run button for the live configuration that is inactive (see image above). The load balancer will then drain out the users from the active node and bring the inactive node up to make it active. The benefit of this approach is the ability to roll back very quickly if we have any issues simply by switching the nodes back.

How to get there?

The process of getting to daily (or even weekly) releases doesn't have to be taken in one leap. Continuous integration is usually the first step. CI products like TeamCity are free and extremely configurable and easy to get up and running. Start by building your product on check-in and informing your developers when issues occur (using something like TeamCity tray notifier). Then move on to automated deployments to your developments environments. This will give you the confidence in the process over time to add automation to your stage/QA deployment pipeline.

Ultimately the key is to evaluate your processes. If you have processes that take a long time and hold the pipeline up then look at addressing those first. If you have a test team that is a bottle neck, look at what you can automate with regard to testing or look at who's remit testing is and see if you can disperse it amongst other teams.

Dev/Ops should be introspective and be focussed on continuous improvement in their development and deployment processes. Your deployment process is never perfect and is never set in stone.

blog comments powered by Disqus