Amazon defines DevOps as a “combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”

It is of course true, but we find this definition to be slightly misleading. In opposition we have a practical opinion of an industry professional, defining DevOps as a

“combination or intersection of the Development and Operations functions, with a very narrow application. Many of the DevOps functions, however, can be automated. For example, manual operations such as integration, testing, or deployment can be replaced with automated scripts and fully automatic products”.

On the other hand, our expert claims: “automation means replacing manual operations with automatic ones. It can be applied at various levels within the organization”.

Clear as day, nothing to add here.

Do you like metaphors? We do! That’s why we have gathered some bright remarks from industry leaders. For instance, Mark W. Schumann from Blue Herring says: “DevOps is when you notice that everything in your fridge has rotted and you make a plan to stop wasting food. Automation is the app that coordinates your supermarket trips with your meal schedule and tells you what the optimal thing is to make for dinner”.

Another good one is from David Johnson (CTO of Mulytic Labs): “DevOps and Automation are similar to the difference between a car and an engine. An engine is necessary for the car to be useful, but you can have a car without an engine. That car wouldn’t do much and would likely be a waste of space, but it’s still a car. Similarly, you can have an engine without a car. The engine is important, but without a car around it, it’s not as useful as it could be.”

Pieter VanIperen (Managing Partner at PWV Consultants) also had a great point on this matter. Maybe not so picturesque but very comprehensive: “automation is something you can put in place without a human needing to do something. Whenever certain parameters are met, an automated system generates the appropriate response to the data input. On the other hand, DevOps is a subset of process automation, integrating developmental processes with IT operations. Because of that, DevOps should always require human knowledge – it can, does, and should use automated processes, but any decision-making should be done by humans”.

According to industry expert confession: “the ultimate goal of DevOps Engineers is to automate themselves out of their jobs”. This process suggests cultural and structural changes with emphasis on collaboration and the responsibilities sharing.

However, another key element of code delivering and integration is human knowledge. It would be wrong to roll out code to market without testing and securing it first. A human should be confirming the final push to production.

While being extensive and constantly developing some examples of Automation include:

Automated testing – making sure a pull request passes all the necessary requirements.

Automated software development – in cases when you can clearly see the nature of the project you might engage RAD (Rapid Application Development), code generation and MDA/MDD (Model-Driven Architecture/Development).

Automated deployment – for example, once you push a feature to a staging branch, you can also automatically push it to the staging server.

Fruitful DevOps culture implies a realignment of teams as per value stream they are supporting. Aligning development and operations teams together enables the historically separated departments to understand specifics, traps and pitfalls of each other’s work. The benefits of such a collaboration are obvious. First, it makes the product so much better. Second, teams immediately start noticing repeatable workflows.

Once these repeatable and consistent workflows are created automation comes into play, resulting in streamlined integration, testing and deployments.

Automation allows businesses to keep up with the imminent pace of innovation, but companies that conflate automation with DevOps run the risk of automating potentially flawed processes. In order to prevent that, all processes should be created in a broader DevOps collaboration. We call it a cultural shift to a DevOps mindset