Continuous delivery models - where small but regular updates replace major yet infrequent software releases - are becoming more and more commonplace, with Microsoft adopting the model for Windows 10. We sat down with Dynatrace technical strategist Andreas Grabner at Dynatrace Perform 2015, to find out exactly how continuous deployment methods can be used in the enterprise.
So, what is continuous delivery?
The premise of continuous delivery is obviously to be able to ship code faster into production. If you have an idea as a businessperson, you want to make sure that it doesn’t take a year until the idea is out there, because in a year, you might have five other start-ups that came up with the same thing and they’re more agile. So continuous delivery means being able to deliver new capabilities faster to your end users.
This could be anything. Amazon is deploying every 11.6 seconds, which is ridiculously crazy, but the deployment here actually means maybe just deploying a new virtual machine into their private cloud to support the UK store.
It’s something that people need to understand, that when they do continuous delivery, delivering something sometimes just means a configuration change, or sometimes just means deploying a new virtual machine into a datacentre to handle more load.
What are the benefits of continuous delivery?
The cloud allowed people to more easily and more dynamically spawn environments that they need to do their automated testing and their automated deployments. I think that's the great thing about the cloud. It also allows people that run applications later on in production to globally distribute the app.
From a continuous delivery perspective, I think the main benefit is in being able to more dynamically spawn virtual machines in the cloud that can do, for instance, testing in a much faster way, to improve the feedback to the engineers that are checking the code, telling them if the stuff that they did was good or bad. This is one great thing about the cloud, or in general about virtualisation. I'm checking in code, I need to verify if this runs on five different platforms. Let's just spawn these five platforms for a short time, run the tests, get the feedback, and then we're done.
What are the drawbacks?
It could be easily misused if you don't have the right safety nets in there. Meaning if you've fully automated your pipeline, I'm an engineer and with a push of a button I can get my feature out there ... then I can basically cause huge damage for my business, especially if I don't have any feedback loops which will tell me if I actually have a problem.
Sometimes people push the button, something gets pushed out, then I go home as an engineer - because I'm not really interested in what's really going on, I may bring down the service and cause a huge impact.
Continuous delivery only works if you build in metrics that tell you 'is the stuff that I'm pushing out actually used: yes or no? Does it break anything else?' And if something breaks, then I need to roll back my changes.
The way it works is, you need to be able to react to bad deployments as fast as possible, and there's two ways. You can either roll back and take out that change - that's why it's so important to make these changes as small as possible - or you need to have a process in place, if you find out that there was a problematic deployment, to fix it as fast as possible and then roll forward.
Is continuous delivery right for everyone?
People sometimes blindly follow what they hear. They come back [from a conference] and they say ‘yes, we need to make sure that every code change gets pushed through the pipeline as fast as possible to deploy it’. But the challenge is, if you want to deploy faster, you may fail faster.
If you have a pipeline but there’s only crap going in, and nobody’s checking any controls… crap comes out at the end. We need to make sure that everybody along the pipeline is aware of the impact that they have when they implement features.
We need to level up developers and testers in particular to not only look at functionality. It should not only be driven by ‘we need to create these five new features in the next week, or in the next sprint’, but 'we need to create them in a way that they’re actually usable and that we can actually make money out of it'.
That’s why we need to put in metrics. You need to allow the business, the developers and the testers, to put in metrics to tell them later on when their stuff actually runs somewhere, how is it running? How does it impact anything else that’s running out there? Do we actually make more money now, or are people dropping off because they’re running into issues?
What kind of metrics should application owners use?
So, I'm trying to teach people metrics, both on web performance, because that's all about the digital experience… how they interact with our website, with the mobile apps, but on the other side, the more scalable systems we build, the more we need to look into the architecture and how software is written and architectured and deployed.
Therefore, I'm also teaching people things like 'hey, if you implement this new feature, do you actually look at how many round trips to the database you make, how many webservice calls, how many microservice calls you make, how much data is actually transferred between your microservices that may sit in two different datacentres?'.
When the code moves from the inception, from the developers box, to the continuous integration environment through the pipeline, this code needs to be analysed based on these key quality metrics. We basically try to play our part by providing these quality metrics automated, and therefore allow people to say 'good change/bad change? Do we push it through: yes or no?'.
Do you have a closing message for anyone looking to implement continuous delivery in their business?
Don't try to blindly copy the unicorns. The unicorns in this space are the Etsys, the Facebooks, the Amazons out there. It's great to learn from them, but what I hear more and more from the people I interact with, they tell me that they are sometimes forced by their management to copy what [the unicorns] are doing, but they're saying 'we are not Etsy, we are not Facebook'. So I think everyone needs to find their own way, and it doesn't happen overnight. I think it takes a lot of passion and dedication.
