DevOps is making sure your services are fast, secure and most importantly, always available. So it involves everything that comes part of it: putting in automated tests, builds, code reviews, setting up multiple environments and more.

This reminded of the famous scene from Silicon Valley:

I've seen many different definitions too. What most have in common can be roughly summed up as "programming the operations."

That would be defining in code everything that has to do with the infrastructure (target architectures, databases, servers, etc.) of an application and how it should be deployed (testing, containers, VPSs, etc.).

This is how I would define DevOps: The act of getting the code that's checked in on version control, to a beta or a production environment, combined with maintaining and provisioning of infrastructure (setting up load balancers, HTTPS certificates etc).

The way I like to think about it, is that DevOps is a combination of culture, processes and tools with a simple goal in mind: reduce the time from an idea/change to its deployments live for real users.

This implies many constraints:

• more autonomy on for the developers, they should not be blocked to release code.
• less manual QA (because it takes a lot of time),
• ...

In order to remove the operational complexity for the developers, many tasks and processes need to be automated (starting with CI and CD, but also including in these more tests, more security checks)

Because the developers have more impact on the prod environment, this also implies more automation of everything: even compliance and network configuration might need to be automated if such configuration are also automated.

Finally, because the number of moving parts increases, and the pace of change also increase (which is the goal!), that implies that failures will happen more frequently. And that's a fact. Any complex system will fail at some point, and the more dynamic (chaotic) it becomes the more likely this becomes. Teams need to accept, embrace and prepare for failure. The goal is no longer to avoid failures (although trying to not fail is still useful!), but rather to make sure the systems support failures and are able to deal with it. The direct consequences are all the devops-related tasks with more automation: better monitoring and alerting, self-healing/self-recovery, ...

The mean time to recover (MTTR) becomes a very useful metric, because if a platform has frequent outages, but where a given service is not broken (maybe just some latency increase or a small increase of the error rate), and if the slightly degraded state only last a couple of seconds (or minutes), it's not an issue if this happens every day. On the other end, a system not designed to avoid failure but not to deal with it might have very few outages... but what if your service is then down for hours?!

All to say that devops is first and foremost a cultural thing: all the tools can only be useful if all the team adopt a devops mindset: try to ship the code fast, try to avoid failure, but make sure anything that could be automated to prevent failure and to restore them is done. That's the only way to be able to confidently deploy fast and often, and therefore to reach that goal of reducing the time from an idea (or a change request) to its deployment in the end-user's browsers.