The 5 enablers of ‘DevOps as a practice’

What is DevOps? A practice? Yes.

This is a short series of three also fairly concise articles exploring what is meant by the emerging and ever popular term “DevOps”.  In this second post we look at DevOps as a practice.

In the previous post, entitled Devops as a culture we identified the ‘three ways’, along with touching on the need to get the culture right.  However, to deliver on DevOps as a practice we need some tangible guidelines to follow.  As a result of my interactions and consultancy work with a number of retailers and IT service providers, combined with relevant research and discussions with regarded thought leaders in the DevOps space (many who can be found here: https://twitter.com/lloydholman/following), I believe that DevOps as a practice can be more formally defined and achieved by 5 key enablers.

Note: The below is relatively link heavy, by all means read through without following them, however the links I have provided are genuine external resources I have gained significant knowledge from over the years and I encourage you to do the same to gain further context.

The 5 key enablers of DevOps as a practice1:

  • Continuous Integration, the process of integrating developers code changes frequently into a common mainline (trunk), resulting in the execution of, at minimum an automated build and test phase and ideally initiation of the Commit Stage of a Deployment Pipeline.
  • Continuous Delivery, the ability to deliver high quality software with frequent, small and reliable software releases.  The dependency on a Deployment Pipeline is fundamental here.

Note: Continuous Delivery is not the same as Continuous Deployment which is a natural progression (but not an absolute requirement of DevOps as a practice) and suggests that all automated builds satisfying a given quality are promoted to a Live environment.

  • Continuous Testing, naturally as the Deployment Pipeline is flexed, builds are promoted further up towards Live. Quality gates to proceed up an environment should get progressively higher and higher, think Unit, Integration, Performance and Load testing and what is required to satisfy them, continuously testing throughout the pipeline is imperative to stabilise changes and prove software is ready for the wild.
  • Continuous Monitoring and Measuring, would you drive in the dark with your car lights off?  The answer is, I hope, NO.  Let’s monitor and measure at an infrastructure and application level then so that we’re not hosting software blind.  Adopt sensible monitoring and alerting at an operational level and empower developers to measure anything, so they can spot trends/patterns and provide real business insight.  Monitor and measure in test environments and fail builds in the Deployment Pipeline that break baseline thresholds.
  • Infrastructure as code (IaC) / Infrastructure as a Service (IaaS), the practice of treating infrastructure configuration as a first class citizen (version controlled, packaged and versioned).  Infrastructure commissioning, patching and configuration should be a non-event, i.e. automated, repeatable and deterministic in the same way as we expect application code to be.  Imagine statements or dependencies such as “Application Version 2.1.x.x is compatible with Environment Version 1.1 and above”.  IaaS suggests a self-service offering, the mainstay of cloud providers such as Azure and AWS but also a valuable internal capability where an organisation self-hosts.  In these cases the development and test teams and the business as a whole are customers of the IaaS offerings which are commonly built and supported in combination with the dev and ops teams, further strengthening the DevOps culture.

All five enablers require a significant amount of well thought out and maintainable automation, in particular with regards to build, test and deployment to target environments, not to mention full buy in to Devops as a culture across the organisation.

Talking about the key enablers is one thing, however in subsequent posts I aim to provide detailed technical implementations based around the enablers.  If you’re reading this in the future, take a look at the tags below, I may just have done it.

1. Sanjeev Sharma has a series on ‘Understanding DevOps’ that does a fantastic job of discussing some (and more) of these enablers in more detail ‘https://sdarchitect.wordpress.com/2012/07/24/understanding-devops-part-1-defining-devops/