Thread by @christianhujer

It seems it's that time again to clear up some misconceptions about DevOps. A thread.

DevOps means Development Operations. If your team isn't doing both, development and operations of the same product/project, it's not DevOps.

DevOps is not about tools but about mindset. Using Docker, Kubernetes, Helm Charts, Packer, Terraform, etc, does not make you DevOps. Having the same team performing development and operations does.

If you have a Dev team, a DevOps team, and an Ops team, for the same product/project, your DevOps team is *definitely* not a DevOps team. If this is your setup, you've done the *opposite* of what DevOps means.

Using something that has "DevOps" in its name does not make your team a DevOps team. Your team uses Microsoft Azure DevOps? If it's not performing development and operations, it's not a DevOps team! No matter what they use. (And don't use Azure!)

If you have a team that uses "DevOps tools" like Docker, Kubernetes, Helm Charts, Packer, Terraform, but is doing this for other team's products/projects, that's again not DevOps: It's not development and operations in the same team.

DevOps is part of proper Extreme Programming. It directly relates to the XP practices Whole Team and Continuous Integration.

DevOps is also "hidden in plain sight" in Scrum. Scrum talks of a cross-functional team. Operations is a function. If you include it in your team, your team is more cross-functional.

Not all teams need DevOps. For example, if you're making a product that's used by somebody else, you're perfectly fine without. It may still be worth looking into it, there may be some tools and practices that could still be useful for you.

DevOps needn't be complicated. Deploying to prod at the end of your CI/CD script, after running all the tests, using

scp app.jar prod-server:
ssh prod-server systemctl --user restart app

could be perfectly sufficient for your team/context.

Simplicity. Travel light-weight.

Don't believe the management hypes. Major DevOps environments like Microsoft Azure DevOps are fundamentally flawed and need lots of workarounds to operate reliably (for example, their bash shells do not set errexit and pipefail by default).

And again, DevOps isn't for everyone. DevOps can significantly reduce the lead time from dev to prod. DevOps can increase the adaptation from feedback and thus, if done well, in some contexts even eliminate the need for support teams. But that depends on you and your context.

If you want to hear other people's opinions about this, check out @allenholub for example.