I have been meaning to write about DevOps for sometime, mostly because until recently I actually had no real idea what ‘DevOps’ was, yet I kept hearing about it everywhere I went, and all over the many blog posts I frequent. But even with the term being branded about so much, I was surprised to learn that there isn’t really an agreed definition (yet).

Before I looked into it further, I just assumed DevOps was simply – Development being involved in (or taking over completely) the operations side of the business. Actually, I have worked in organisations where this was at least partially true, so that certainly fuelled my assumption further.

So the Development team do all the work to build the application, and then they presume the Operations team are so useless that Development actually take over all that work as well. I am sure the Operations team would be thrilled if this were true, to borrow a quote from South Park…:


Thankfully (at least for operations employees) my initial assumption above is false (mostly…). The next idea that I had was that ‘DevOps’ was a completely new role that an organisation would recruit for. In the same way that you recruit a DBA or a Systems Analysis, you now recruit a ‘DevOps’ guy… It turns out that this wasn’t really accurate either. I’ll borrow another image from South Park…


Ok enough messing around – what is DevOps? For me personally, I like to think of DevOps as an evolution from Agile. In fact, you could probably replace the ‘Agile‘ buzzword that was everywhere about 10 years ago today with ‘DevOps‘ and you would at the very least be on the right track. It’s more of a philosophy than anything else.

Much like Agile and Behaviour Driven Development, DevOps is very big on communication between teams, particularly between operations and development engineers in the entire service lifecycle, from the initial high level design right through to running live in production. I’m on a total role with these images….


But its not just about communication (obviously). DevOps is also characterised by operations staff being encouraged to make use of the same techniques and tools in their operations work as Developers do in development work. So things like automated infrastructure provisioning tools (e.g. Puppet and Chef), continuous integration tools (Jenkins, Team City etc.) and even establishing developer work environments that ultimately mirror production (Vagrant)… This image isn’t really relevant but it’s the best I could find that matches the theme….


One thing to mention at this stage. Although “Dev” is used as shorthand for developers, the term ‘DevOps’ really means ‘every person that is involved with software product development’, which can include QAs, BAs and many other kinds of roles.

A key area within organisations that DevOps tries to address, and reduce, is ‘Waste‘. I am planning to write another completely separate post on ‘Waste’ in relation to ‘DevOps’, but at an incredibly high-level, it is aiming to make an organisation and its staff more efficient. These aren’t even making sense anymore…


So there you have it. I would summarise by saying that the term ‘DevOps’ is a term loosely used to define a set of practices, tools and policies that encourage the improvement of quality and efficiency of Software Development within an organisation.

I am planning to write at least a couple more blog posts on DevOps (minus the South Park images, sorry!), because it really is such a huge area and I can’t really do it justice in a few short paragraphs, but I certainly want to talk more about how it identifies and removes waste (which leads to increased efficiency) and give an overview of some very specific tools that I would classify as “DevOps Tools” – look out for those posts in the near future!


Leave a Reply