No-one said DevOps is easy – but the right tools can help

eBook: How to get outstanding results using a DevOps approach

It’s been hard to avoid the topic of DevOps in 2015 and according to Gartner, we can expect DevOps to become mainstream in 2016, with adoption by approximately 20000 of the world’s top organisations. The theory of DevOps promises much, but it’s important to keep some context here: some big barriers need to be addressed before successful application of DevOps is achieved.

DevOps has, in reality, been around for a while in one form or another, but the current lens on how the software development and operations teams could work better together has largely been prompted by a raft of new tools. The likes of Docker and Vagrant go a long way to unlocking DevOps’ potential, though of course are not enough all by themselves (more on that later). Another driver is the fact that development and operations just cannot carry on as two entirely separate and sometimes warring factions: the zeitgeist of continuous development, agile and faster-time-to-market requires a more collaborative approach.

This brings us to the nub of the challenge: applying DevOps methodology will only work if everyone has a shared understanding of what is being developed and what is entering production. Apart from cultural barriers, let’s not forget that they are usually using completely different software tools to do their jobs.

Continuous Delivery (CD) will help achieve this more transparent way of working. Already adopted by around two thirds of organisations in the UK and US (according to Evans Data Research last year), CD is all about creating a collaborative and timely method for taking software projects right from inception through to deployment. In practice, this means being able to release software into production at any given time. At the heart of CD is a development pipeline, within which can be included early feedback, incremental deployments and automated build tests, all of which accelerate release cycles.

Like DevOps, CD has in theory a lot to offer, but we’re still back to square one: both will only succeed with the right culture and right technology tools. Other organisations are better placed to comment on achieving that cultural balance, so let’s focus here on the tools. Here are some ‘best practice’ steps we’ve pulled together, based on working with customers who’ve successfully implemented DevOps, plus advice from leading experts in the field.

Successful DevOps – the right tools approach

Don’t limit thinking to just code – these days, there are a lot of different assets involved in most software-based products, such as documents, visual content, binaries and configuration scripts. These need to be managed together throughout the release cycle, otherwise there is a real risk of incomplete or faulty applications being delivered to customers.

Automate as much as possible and keep testing – The aim here is to be able to make changes, adjustments or updates fast, but securely and while minimising the risk of errors creeping in. The answer lies in having a unified continuous pipeline that automates as much of the process as possible, enabling failures to be fed back to the development team at an early stage so that they can make any necessary corrections. Uncovering problems in the development stage is more efficient than once assets reach QA testing. Of course, not every single element within a process can be automated, it’s a question of working out which can, and which will still need some manual intervention.

The search for a single source of truth– at the centre of any successful DevOps project should be a single, unified repository, which connects every person and asset, but more importantly, without creating overly rigidly working practices. Employees should be able to carry on using their own methods and tools, so the version control repository needs to be able to integrate seamlessly with all kinds of third party software and be technology agnostic. Given that most software projects are becoming larger and more complex, the version control repository also needs to be able to scale.

Track and trace – the benefit of tracking and traceability is that all the changes made at every stage of the release cycle, plus all the inter-dependencies, ‘travel’ together and are delivered as a single release. This makes debugging easier and also provides an ‘audit’ of what happened where, when and how. It’s also important to have a version control engine that supports rolling back to previous versions of the software, in case any problems or bugs are found.

Of course, the road to DevOps and associated practices such as Continuous Delivery involves multiple steps and no-one has ever suggested that it will be plain sailing and achievable overnight. However, as long as organisations are aware of the potential pitfalls and understand that getting the right blend of corporate culture, processes and tools is vital, then they stand a good chance of using DevOps as a real business advantage, not least of which is rolling out products quickly and efficiently.