Why every time a new hype comes out and after some time of rolling out as the next best thing after sliced bread, we start reading that “it is not about xxx, is about people/organization/process”?

Our human need to label things, put a name, over-structure it or formalize something usually leads to misunderstandings and frustrated expectations.

The “DevOps” is no different.

Some started talking about DevOps. People Jumped on board. Then realized:

  • that their developers think Unit Testing is running the application and prove that what is coded is working.
  • That testers are in fact the users
  • That integration is done at production environment
  • That needed environments/data/setup are available half way through the project, and everything requested has now changed and provision has to start again…

…and reached the conclusion… “it is all about cultural change…”

You are not doing it right mate! and do I have bad news for you: DevOps will not make it right.

It is the other way around. Do it right, and DevOps will come.

To make it clear I am all in favour on the principles of DevOps: Deliver to end user, apropos, quality Software, Faster. It is, at least, a good framework for a good setup. A target destination.

As engineer I like to believe that there is always a cookbook, a recipe, an algorithm or framework to help me out solving the problem at hand.

So there is a lot of appeal in the naming DevOps. Here we have it, the best thing after sliced bread – DevOps the way to go!

A lot of blogs and posts try to enlighten us about the “3 pillars of DevOps”, the “5 key success factors on DevOps”, “how to implement DevOps”.

Stop!

The 3 pillars of DevOps are: Automation, Automation, Automation.

The 5 key success factors for DevOps are: “automation, automation, Automation , Automation, automation”

The…  well, you get the point.

Let’s face it. Dev ops is all about tools. No two ways about it. It is about tools that automate well-defined Continuous Delivery Process.

Where it all starts: Automation.

If you are a CIO and you are immersed in conversations…:

  • About the completeness of user stories
  • about the quality of Unit Tests…
  • that Continuous Integration failed…
  • That the SCM server requires upgrade…
  • where People keeps nagging you for sponsoring some try outs with Docker, microservices containers…

You most likely doing DevOps already and should continue doing whatever you have been doing.

Otherwise, if your people think Chef is a new restaurant, you can take DevOps out of your radar! See! One less problem to solve. DevOps is not for you! Yet…

But you should pursue it. Automate! and then, Automate some more.

Let automation drive your change.

  • Does it require an organizational change? Probably.
  • Will it require a strategy a Balanced Score Card to implement that strategy? sure it helps!
  • Will it require people to comply with it? yes.
  • Training? Yep!
  • Top-level commitment? no doubt.

But doesn’t everything else? These are all the same pass part out recommendations one receives every time change is needed.

Offcourse that if you automate a bad process you will have a faster bad process, correct, but if you don’t automate you still are left with a slow bad process.

Let the tools drive the improvement. Yes, a fool with a tool is still a fool, but…in most cases tools can provide that little leverage that changes from “always done it like that” to “Always wanted to do it like that”.

Build it and DevOps will come.