Is there such a thing as DevOps best practice?

ecs-admin 13th January 2016

DevOps is notorious for being difficult to define. Even among those who deal with DevOpsenvironments on a daily basis, there’s a fair amount of disagreement about what exactly DevOps entails and how best it can be adopted. There are certain features that everyone agrees form part of DevOps, like bringing Development and Operations teams closer together, automating critical processes in both Dev and Ops, and implementing Continuous Integration and Delivery pipelines. But that’s exactly where the trouble comes in: though these are all constituent parts of DevOps, it’s impossible to define it using just one.

For ECS Digital, DevOps comes down to three vital components: people, processes and tools – in that order of priority. So, with that in mind, is there such a thing as best practice in DevOps? In this blog, by looking at the common ground in all DevOps implementations, we’ll try to answer that question as best we can.

Build as much common ground as possible.

The original goal of DevOps was to eliminate the silos that typically existed between Development and Operations in order to overcome bottlenecks in the software development and deployment process. As DevOps has matured, this has grown to encompass all stakeholders in the software delivery value stream. If DevOps as a term was coined today, it may as well have been called DevBizTestQaSecOps – but I’m sure you’ll agree that doesn’t roll of the tongue quite as easily.  Traditionally, these groups worked in complete isolation from one another. This made collaboration virtually impossible and created unnecessary back-and-forth between departments. And to make matters worse, groups often find out about imminent changes at the last minute, resulting in unplanned delays. The Net result: longer project time-frames and slower time to value for customers.

Establishing an organisational culture that allows its people to flourish is the single most important objective of DevOps. Adam Jacob (CTO at Chef) says “sad people build sad products, which in turn creates sad companies.”  It will be difficult to implement effective processes across an organisation if its groups work in isolation, and automating a poor process will ultimately be a waste of effort. The common ground across all groups in the software delivery value stream is the desire to deliver the best products, services and updates as possible to customers as fast as possible. The objectives and accountability of these groups, and even their structure, needs to be adjusted to ensure this is the case.

The other key aspect of DevOps culture is ensuring that people feel empowered to innovate.  Fear of failure is a key inhibitor of innovation. One of the most successful entrepreneurs of recent years, Elon Musk, says, “If you’re not failing you’re not innovating enough.” Etsy are famous for introducing blameless post mortems where learning from failures (which are unavoidable) and improving the mechanisms that caused them is key.  Without this, understanding the true cause of issues is unlikely and the chance of a repeat occurrence increases. A true DevOps transformation relies on each member of the team changing the way they see their role within the context of the organisation.

Identify specific best practices for the unique context of your organisation.

Another reason it’s hard to come up with a concrete definition for DevOps is that the specifics of how it is adopted can vary greatly depending on the organisation. The same is therefore true for best practices: what works well for one business might be a disaster for another. Continuous Deployment may be perfect for Etsy and Flickr but may be impractical for highly regulated companies such as banks – in this case, Continuous Delivery where releases are always deployable to production, rather than being automatically deployed to production, may suffice. Ensuring the involvement of your subject matter experts in the re-engineering of critical processes will maximise their buy in and smooth adoption.

DevOps tools aren’t just limited to hardware and software.

There’s a running joke at ECS Digital that pizza and beer can be considered DevOps tools. It’s a tongue-in-cheek comment, obviously, but there’s truth to it: the objective of a DevOps tool is to bring traditionally disparate groups together to create better software, faster. If sharing a round of beers and ordering some pizza helps make your groups more productive, brings them closer together, and facilitates a better end-result, you’ve achieved the purpose of a DevOps tool. Part of the reason we like to use this example is to illustrate that the term ‘DevOps tools’ isn’t limited to just hardware and software. Think outside the box when it comes to the way you implement DevOps in your organisation – you might be pleasantly surprised by the results.

ECS Digital is a DevOps consultancy with 12 years’ experience implementing both enterprise and open source DevOps solutions for companies all around the world. If you’re interested in finding out more about our approach and our unique insights on how to successfully transform your organisation by adopting DevOps, contact us to request a DevOps Maturity Assessment

Found this interesting? Why not share it: