Monitoring: A Constant in Continuous Deployment Environments
Test and Monitor | Posted August 19, 2013

If you were to ask 10 different developers what "continuous deployment" is you’d likely get a dozen different answers – and each one would probably be correct to some degree. Reason being that, as with so many other aspects of the Web, there’s more than one way to do it. Not surprisingly, this often leads to competing opinions around which approach is the best – a discussion we can save for a later time – but it underscores the larger point that continuous deployment is beginning to change the way business is being done online.

The fact that a number of high-profile organizations are already executing continuous deployment in some capacity, and with significant success, is proof enough that it has its benefits – but before we delve any deeper let’s lay out in plain English what exactly it is that we’re talking about. While there are a number of different flavors of continuous deployment, the basic idea is that once development is complete the code and new functionality is pushed to production, essentially testing it against end-users. This makes it absolutely imperative to monitor performance and functionality after deployment so that in the event of a bug updates can be rolled back quickly and with minimal impact.

Here’s a visual depiction of continuous deployment from IMVU:


Despite the safety net, a strong monitoring solution can offer many developers still see continuous deployment as a risky proposition, preferring the familiarity of a traditional "over-the-wall" approach where all design, development and QA is done prior to release and then pushed to production all at once. While this is the more common approach today, it’s probably only a matter of time before continuous deployment becomes the norm. The benefits it offers businesses are quickly making believers out of key stakeholders; fueled mainly by the ability to provide end-users with new features and functionality at a much faster rate than what can be achieved by even the most efficient implementation of traditional deployment techniques. As a result, continuous deployment is starting to become its own business case – just look to LinkedIn as an example.

How continuous deployment is actually rolled at an organization depends on a number of factors. Paul Biggar, Founder at Circle Continuous Integration, laid out several key variables that affect this implementation in his Mountain West RubyConf presentation earlier this year – these included:

  • How fast an organization is developing new features
  • The complexity of their code
  • The design and architecture of their software
  • Whether or not the application is service oriented
  • The number of engineers
  • The state of their monitoring

Biggar went on to provide examples - explaining how GitHub deploys new code and functionality to a small percentage of their users to monitor and test before adding it to their master production code. Facebook releases new code to all customers, but new functionality is flagged, allowing them to turn on new features for select groups of people. Given their extensive demographic data, Facebook can make a new feature available to an extremely focused demographic – think ‘single, employed males, ages 18-25, living in Boston with a dog’ kind of focused – to test and monitor before gradually rolling it out to additional users. Both are continuous deployment, but different sides of the same coin.

The one thing that all continuous deployment methods do have in common is the need for a strong monitoring solution. IMVU, a social entertainment company connecting users through 3D avatar-based experiences and a pioneer in the continuous deployment movement, has regularly emphasized the importance of monitoring when preaching the benefits of the practice. Biggar referenced IMVU when highlighting the importance of monitoring in his presentation – citing a situation where deployed code was functioning perfectly but conversions were dropping steadily. The issue was the result of a white ‘Buy’ button being deployed on a white background. This lesson served as one of the main catalysts for IMVU to include business metrics in their continuous deployment monitoring. Now anytime business metrics, or any other type of performance for that matter, goes wrong IMVU adds it to their monitoring to ensure the quality of future releases.

As continuous deployment continues to gain traction, the selection of a suitable monitoring solution will be critical to organizations’ success. They’ll not only require the capability to monitor the performance of systems and critical business metrics and transactions, but also the ability to know in real time when problems arise on their sites. Eric Ries, former co-founder and CTO of IMVU wrote, “No matter how good your deployment process, bugs can still get through. The most annoying variety are bugs that don’t manifest until hours or days after the code that caused them is deployed. To catch those nasty bugs, you need a monitoring platform that can let you know when things have gone awry, and get a human being involved in debugging them.’

With monitoring playing such an integral role in the success of continuous deployment, businesses preparing to make the transition need to ensure their current solution meets these criteria. Waiting to discover your monitoring solution isn’t up to par after deployment could be disastrous.

See also:


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox