Define DevOps: What is DevOps?

DevOps (a portmanteau of "development" and "operations") is a software development method that stresses communication, collaboration and integration between software developers and Information Technology(IT) professionals. DevOps is a response to the interdependence of software development and IT operations.

Nope. "software development method" doesn't do DevOps justice. Like this one

DevOps is the blending of tasks performed by a company's application development and systems operations teams.
The term DevOps is being used in several ways. In its most broad meaning, DevOps is a philosophy or cultural approach that promotes better communication between the two teams as more elements of operations become programmable. In its most narrow interpretation, DevOp is a job description for an employee who possesses the skills to work as a both a developer and a systems engineer.

many definitions neglect the technology automation aspects of DevOps. Culture is primary but its not everything.

Underpinning DevOps is the philosophy found in the Agile Manifesto, which emphasizes people (and culture) and seeks to improve collaboration between operations and development teams. DevOps implementers also attempt to better utilize technology—especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.

but it is cumbersome and not satisfying.

many will quote Adam Jacobs, saying “DevOps is a cultural and professional movement. The best way to describe devops is in terms of patterns and anti-patterns.”

DevOps is... an umbrella concept that refers to anything that smoothes out the interaction between development and operations.

...which I like.

One definition Jez Humble explained to me is that DevOps is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.”
That’s good and meaty, but it may be a little too esoteric and specific to Internet startup types. I believe that you can define DevOps more practically as DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

That doesn't work for me either. Arguably an organisation has ceased to function if Dev and Ops are not "participating together". What's important is how, and how well.
(I loaned Jez's book Continuous Delivery to a client so I can't check if there is a definition of DevOps in there. Anyone?)

...and so on.

Lots of talk and stories (especially stories) about what DevOps does and why we need it and what it is not, and what it is "about", but actual definitions of the term are hard to find.

This is deliberate, as many DevOps proponents will tell you, e.g. Jez again:

DevOps, a movement of people who care about developing and operating reliable, secure, high performance systems at scale, has always — intentionally — lacked a definition or manifesto.

In fact I suspect nobody dares define it now because that would be, like, uncool. But that's all a bit too hippy for me, and for many people who would just like to know WTF it is that everyone is talking about. Left undefined, DevOps gets to mean whatever anyone wants it to mean, including some pretty weird and wonderful blind-man-touching-an-elephant definitions from people who once read something somewhere.

So, unconstrained by such post-modernist ideals to let it be what it is to each of us, man,
here's my definition of DevOps.

Have at it. It will change - it was last updated 25/5/2017:

There is a lot of agreement in the industry that this should not mean a new organisational function: there is no “DevOps team” or "DevOps guy". (I'm prepared to make an exception to use the term for specialist advisors and toolmakers, as Jez Humble does. More here on how people use the term "DevOps" in role descriptions.) It is a change in the way existing teams work. It might mean organisational structure changes or not.

In practical terms DevOps can involve any combination of a wide range of ideas:

• Greater collaboration between Dev and Ops: united team, shared knowledge and tools, shared ownership of the production system, shared accountability for service...
• Accelerated feedback: tight feedback loops to let developers know there is an issue as early and quickly as possible. Minimise surprises/bugs in later testing or in deployment.
• Improved flow: get out of the way.
• Data driven: measurement to give objective feedback.
• Continual improvement: an Agile iterative approach, learning from mistakes, failing fast. Use of Lean and Theory of Constraints concepts.
• Reduced formality: close teamwork; a culture of trust, empowerment, professionalism, and accountability; flexibility over process.
• Fail fast: be able to fix failures so quickly that it is more efficient than preventing them
• Be prepared to fail: experiment and learn. My term: noble failure.
• If something is painful do it more often.
• Development owns as much of the lifecycle as possible, possibly including deployment to production.
• With ownership comes responsibility: developers “carry pagers” and fix production problems.
• Operations move to more of a supervisory capability, setting policy and controls and overseeing environments, with execution of many operational tasks performed by Development teams.
• Many teams - operations, security, networks, DBAs… - become toolmakers to Development, providing Dev with the capabilities to do their jobs using self-service facilities: tools, scripts, APIs.
• Automation is key to increasing deployment speed and frequency without sacrificing quality: automation of merge, build, test, approve, release, deploy. The extreme ideal is a "deploy" button which allows a developer to deploy through all environments, tests, and controls into production without intervention.
• Infrastructure as code is the ability to build some or all of an environment for an application/system (from Dev to Prod) using software (usually scripts and command lines), from the bare metal up: server, storage, operating system, database, metadata, data, network, shared services, code, identities, authorisations… The ideal is for a single package to contain the code for an application and an environment to run that application.
• Servers are cattle not pets.
• Continuous integration is the ability to test code against a production-like image at all stages of the lifecycle from early unit development so it is always guaranteed to work in Production (for some defined meaning of "always" and "guaranteed")
• ...and an aspiration of no forks: no branching of code; one version; no merges; no regression
  ...as part of that, developers check code back at least daily to ensure trunk is deployable so that...
• Continuous Delivery means code is always ready to deploy (for some defined meaning of "always" and "ready") and automatically advances as far advanced down the pipeline as possible, so that in the extreme case....
• Continuous Deployment means code is deployed to production at any time, unconstrained by windows or schedules.

If you want to know more about DevOps, best you read The Phoenix Project

My Kamu Project for sharing ideas between DevOps and ITSM.

More from the IT Skeptic on DevOps