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.

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.

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:

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.