The simplest way I can imagine is : « you have to maintain what you developed », or, «you have to make sure that the component you developed runs correctly in from the dev stack to the production stack, and all the intermediate stages » All the other parts are direct consequences: - the engineer as to be aware of the infrastructure components, he has to understand it correctly - pushing/updating updates should not require complex sysadmin skills (ie automation and abstraction of some plumbing is helpful)

This implies smaller dev cycles, smaller updates, easier to deploy. The container (Docker-related) paradigm shift is also very helpful to separate the concerns: once the infrastructure foundations are set (permissions, ...), updating/adding a service should no longer require advanced infrastructure skills.

This is a "from the top of my head" description and I'm pretty confident you'd find better answer on internet, but - from my point of view - the most important point is that mentality shift, where the software engineer is no longer conflicting with the sysadmin team, but rather mixing the skills and collaborating to manage his development in its whole lifecycle (from dev to running in prod, and handling the issues)

In one short sentence: it's a set of processes and tools that helps DEV and OPS teams work faster.

For me, devops is a culture, it's a way of thinking that both DEV and OPS teams has to adopt in order to work well.

The most important requirement is clear and transparent communications between the teams (it can begin with the definition of a common vocabulary, the required documentations for a software, logging and security policies...)

Then, using automation, implement tools to help the teams increase their productivity and work faster (continuous build for DEV, PAAS for DEV, simple delivery pipelines for OPS...).

The development cycle and the release/deployment cycle were earlier different and were managed by 2 different sets of folks. For eg, the dev team produced code and the sysadmin team upgraded/deployed it and managed the servers (operations) etc. Dev-ops is a movement, where these both are considered together so that the entire chain from dev to deployment happens seamlessly with automation . This is becoming possible, where there are frequent releases (following agile methodology) and also with virtualization technologies where the infrastructure (machines) can be managed with code, making automation easy.

In an nutshell, the development and operations coming together by way of automation.

Simple explanation of DevOps without the complications and information overload. ... DevOps is a concept with different interpretations and definitions, but when you get down to it, it's all about developers and operations teams breaking down silos and working together to innovate faster.

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.

DevOps is the posterity of light-footed programming improvement – conceived from the need to stay aware of the expanded programming speed and throughput deft strategies have accomplished. Headways in coordinated culture and strategies in the course of the most recent decade uncovered the requirement for a more all encompassing way to deal with the end-to-end programming conveyance lifecycle. It was complicated to write my thesis chapter on devops.