Basic and simple explanation of Dev Ops


Lately i’ve been running into this a lot. People don’t have a clue what Dev Ops actually is. Found this article and thought it put it pretty simple for people to understand.

The difference between Agile and DevOps
Posted by leontranter
difference between agile and devops
devops is here to stay

DevOps is one of the hot topics at the moment, and is well on its way up the hype cycle curve. Some are even saying it replaces Agile, thus spelling the end of Agile software development. That isn’t true, though if you’re interested in agile, you should start learning about DevOps. Why? Because although it doesn’t replace agile software development, it complements it very, very well. This article will explain the difference between Agile and DevOps.

DevOps is not a tool
DevOps is not a buzzword or a tool or a product. I cannot emphasise this enough. Some vendors and snake oil salesmen will tell you that it is… “buy our complex deployment toolset and you can haz DEVOPS WOOO LOLZ!!”. Don’t listen to them and don’t believe them. You can’t tool your way out of shitty processes and bad ways of working.1

DevOps is rather an attempt to rethink the value chain of software development, especially the end part of the chain (getting it out to customers), and how it fits into an organisation.

DevOps is a rethinking of how we configure and deploy software
Traditionally in software development (whether Waterfall or even Agile), there were “development people” who built software. They would move software through various environments, possibly via manual processes, or possibly via automated processes like build pipelines. Usually this would be involve moving software from a dev” environment, then to some kind of “test” environment, and then probably to some kind of “staging” environment. And that was all fine, but that was as far as they could go. Why? Because on the other side of staging was the legendary land of Production. It is the mysterious land where magic, opportunity, threats and risks abound. It is the part of the map with “Here Be Draggyns” written on it. And it’s a place where developers are not allowed to go.

Instead, they do a big “handover” to an Operations team. And the Operations team were responsible for doing a bunch of “deployment” activities to move the code from the Staging environment to the Production environment. This deployment was complicated, more so than all of the other deployments, because:

the production infrastructure was very different to the dev or test or even staging infrastructure
there had to be extra checks and balances and processes to make sure it was all ok because hell, this was production!
this deployment was done by different people, who had usually never seen or heard of any of this software before. It was thrown “over the fence” to the operations team. Who didn’t usually understand the software and wouldn’t know what to do if it stopped working.
At this point, people stopped doing “software development” activities and instead did “software deployment” activities. And the people who did that were different to the people who had done the development activities.

DevOps breaks the boundary between development and deployment
So DevOps tries to fix all this. It says:

what if we could put software into “containers” (like a mini virtual server and OS that the software lived inside) and the containers got shipped around to different environments? then moving a container from test to staging to prod wouldn’t really matter, because the software is still sitting inside the same container and thus doesn’t care where it is.
what if we had streamlined checks and tests and processes for every environment so moving to production was not a big deal?
what if we had automation of not just our tests, but all of our configuration management, environment management, and release management?
This is the key one: what if the people moving it to production and looking after it once it is there, worked closely with the people who built the software? Or even better, were the same people who built the software?
This is a major rethinking of the structure and roles in a software organisation. It basically says “you build it, you run it”. You are responsible for it working in dev, in test, in staging, AND IN PRODUCTION. And if you do all this properly, with not just automated tests like a good Agile kid, but also by turning your infrastructure into software by containerisation (is that a word? urgh unfortunately, I think it is), then doing this should be a simple process.

Devops complements agile instead of replacing it
DevOps does not replace Agile or Lean. It complements Agile and Lean very well, by eliminating waste, removing handovers, and streamlining deployments to enable faster and more continuous deployments to PRODUCTION. Many organisations do Agile, automated testing and continuous delivery but only push their pipelines as far as staging. Because the Operations people say “hey hey you can’t cross that line. That’s our territory: you stay in yours, and we look after ours”.

Agile is the bit in between Lean Startup / Design Thinking and DevOps
If you have an idea for a startup and you want to operationalise and scale it, you need to do three things:

you need to find product / market fit, i.e. find if there is a sufficient market for your idea
then you need to quickly build your idea
finally you then need to release, manage and scale up your idea.
There are three good techniques for doing these things:

Use a mix of Lean Startup and Design Thinking for your product / market fit
Then use some form of Agile Software Development for building your idea
Then use DevOps for releasing and managing it in production.
I hope this clarifies the difference between agile and DevOps: more specifically, how DevOps complements, but does not replace Agile.


I’ve enjoyed this blog:

Especially since they have a beer category :stuck_out_tongue:

And this quote

"I’ll tell you EXACTLY what DevOps means.

DevOps means giving a shit about your job enough to not pass the buck. DevOps means giving a shit about your job enough to want to learn all the parts and not just your little world.

Developers need to understand infrastructure. Operations people need to understand code. People need to fucking work with each other and not just occupy space next to each other."

John E. Vincent


I wish I could throw multiple “likes” on a post because that quote that @andycleff posted was priceless.

One of my mentors said DevOps is so many things, but the core principle behind it is that developers and operations collaborate daily. How’s that for a DevOps Manifesto?

DevOps is yet another example of agile being adaptive and going to the next level. Collaboration between business+dev+operations = business agility. The ones that embrace it, will be the survivors!!!


I would try to explain DevOps as, “the cross section between development and operations where repeatable processes are automated; build process, deployment process, infrastructure provisioning and setup, automated testing, etc.”

Unfortunately I think this is a marketing ploy meant to prey on those who think development and operations have to be separate.

Personally, I believe Agile teams need to do development, QA, and operational activities to be efficient and deliver value quicker. The place of a Sys Admin has been absorbed and incorporated into the Agile process already.

Creating a separate team or role for DevOps is an introduction of slowness and inefficiency in a process intended to deliver product value sooner and get customer feedback faster.


Some great DevOps tutorials for beginners.


As long as people talk about DevOps by looking at the operations people and the development folks, there is no real progress. It will always be the others.

Same as with Development and Quality Assurance, there is not the one or the other. If you want to get it right, it needs to be integrated. By the everyone has to be concerned about how to build products, which work.

As you might see, this is more about mindset than about process and RACI. You might understand, this is exactly encouraged by Agile. DevOps is just a Derivate to extend Agile beyond development.

In my teams operability is becoming a concern of my teams. My teams must understand, that issues in operative systems need to be handled by them. There are system administrators and project administrators outside of the teams, who take over setup task. The concern to ensure working products stays with the team even though.

(Sorry, I did not read all replies and linked articles, while I wanted to add my point to this discussion - feel free to blame me for this, I will understand)