The term DevOps  has become a major buzz word recently. I’ve read about what DevOps is to an Organization, a C-Level Leader, an Infrastructure Engineer, a Software Developer, and a Software Engineering Manager. And I’ve read how DevOps is a service, a department, a product, and a practice. I feel the term is unclear and we are left to figure it out on our own. In the vein eloquently described in an xkcd comic, here is how one engineer defines DevOps.

Defining DevOps

DevOps or Development Operations is the intersection between the traditionally separate Software Development and Operations team. This intersection encompasses physical assets like servers, networking, and deployment environments as well as software assets like source control, build servers, project management systems and communication platforms.

Individually, these assets aren’t very interesting. When we “glue” them together with Continuous Integration and Continuous Deployment processes they become very powerful. For example, a simple CI/CD process might be:

A simple DevOps workflow - Commit Code to SCM, Compile Code, if no errors then deploy to environment.

But WAIT! There’s more! If CI/CD is the glue between your systems then the steps you add to validate your application throughout the process are the like fibers that make the glue strong. Our goal is to surprise and delight our customers, steps like code review, unit tests, integration tests, end-to-end tests, static analysis, infrastructure scaling, logging, log processing, application monitoring, performance monitoring, and all the notifications you need are necessary to achieve our goal.

All of this is DevOps. You don’t need all of it to “do” DevOps but you need some of it. Most importantly, if you’re not doing any of this on a daily basis then you’re definitely NOT doing DevOps. DevOps is a practice, a kata, an idea. It’s something you have to do everyday.

Why is it important?

The intention of DevOps is to improve throughput and reduce errors. Automation is the simplest solution to me. We can automate anything we set our mind to. Let’s take a look at what our CI/CD process could look like when we set our mind to it:

An extended DevOps workflow

Everything above is an example of what you can automate in your back office. Emphasis on example. I recognize each and every team has it’s own nuances. The point is we should automate as much as possible to minimize manual, error prone actions.

It’s all good to talk about what we can do in the back office, it’s important and helpful, but what about our most critical systems, like production! We need to automate all deployment environments. Not just provisioning and configuring but monitoring, logging, and scaling. And each of these are may have their own process.


At this point I hope you realize you’re already doing DevOps in one form or another. Its always been there and now it has a name. It’s time we embrace the practice, make it a first class citizen in all professional development settings. Better yet, we need to invest in the practice, improve our throughput and eliminate unnecessary errors.

In my next post I plan to touch on who should implement DevOps, why, and what it means for a couple organization roles.