Continuous Deployment

I had a chat with Brett Winterford recently, a journalist writing for IT News, about continuous integration and continuous deployment (article here).  The essence of our discussion was focused on the question “Can legacy enterprise teams move into CI/CD”.  The answer to the question has to be yes, for a couple of reasons.

First and foremost, our competitors can no longer be regarded as the same competitors we had when news was delivered daily in print and technology projects could run for three years (and did!) without seeming unusual – merely “big”.  Our competitors now are globally placed, and can set up a competitive news source about as quickly as you can make an omelette. That’s the benchmark.  If we can’t tweak a feature on one of our sites and test it live inside of 24 hours, we might just be dinosaurs waiting for a meteor.  Most of the newer digital media businesses can do this, and many of our legacy competitors are on this journey as well.  This is why it’s a baseline expectation, not a target.

Secondly, as we move into a world of KPI’s focused on site performance including competitive benchmarking we need to be able to call a slowdown worse than a particular measure a severity one issue, and ask the relevant team to stop their project work and turn their attention to the slowdown until the issue is resolved.  This can’t really work unless we can release the performance fixes and test them continuously – preferably using RUM (Real-user monitoring) and this couples these two objectives.

Third, in a recent restructure my team was expanded and now includes responsibilities from design through to support.  Part of the motivation for this is a desire for faster output.  I’ve had several people dispute this is feasible – on the basis that we are running at capacity already.  I believe we can achieve good results in a couple of ways though.

As we are all in one team now, we can lean out our management processes and push closer to pure agile / Scrum and ship a lot more smaller releases.  This will create a perception of velocity in its own right, but will also gain faster feedback – allowing teams to refine or pivot more quickly, and get to the right outcomes quicker.  Product managers will also be able to do their UAT incrementally instead of waiting for releases, which will lean out the UAT processes.

Lastly, testing as a function will change fundamentally in a CI/CD environment and our testers will be increasingly automation specialists who will work with the project teams to make sure they have tests in place.  This will mean more testing is automated, and done quicker than human hands can do it.

Leave a Reply

Your email address will not be published. Required fields are marked *