METHODOLOGY

DevOps

A culture and set of automation practices that merge development and operations so the same team builds, ships, and runs the software, with fast feedback from production back to the code.

Last reviewed: byKevin Riedl wiki ↗

DevOps started as a reaction to a specific dysfunction: developers threw code over a wall to a separate operations team, ops got blamed when it broke, and the feedback loop between writing software and running it was broken. DevOps closes that loop. The team that builds the software also ships it and runs it, and the pain of operating something flows straight back to the people who can fix it.

In practice that culture is enabled by automation: CI/CD so changes flow to production safely and often, continuous delivery discipline so every build is shippable, infrastructure as code so environments are reproducible instead of hand-built snowflakes, and observability (logs, metrics, traces, alerts) so the team sees what production is actually doing. None of these tools are DevOps on their own. They are what makes the culture survivable.

The “DevOps engineer” job title is mostly a misnomer, and a revealing one. DevOps is not a role you hire to sit between dev and ops, that just rebuilds the wall with a new name. What most “DevOps engineer” postings actually want is a platform or infrastructure engineer who builds the automation other developers use. Useful person, wrong label. If your org has a DevOps team that owns deploys so developers do not have to, you have ops with a rebrand, not DevOps.

Worked example of “you build it, you run it” working as intended: an engineer ships a change on Thursday, gets paged at 2am Friday when it causes a slow memory leak, and spends the early hours fixing their own code. That is unpleasant once. It is also the most effective code-review system ever invented, because that engineer will never ship that class of bug again, and the next time they design something they will think about how it behaves at 2am. When a separate ops team absorbs that pain instead, the person who could prevent the next leak never feels the consequence of the last one, and the same mistakes recur indefinitely. The pager is not punishment; it is the feedback loop.

Wavect’s take: DevOps is a way of working, not a department. We build the automation that lets a small team own its software end to end, and we treat “you build it, you run it” as the default. See our full-stack development work for how that plays out in practice.

// FAQ

FAQs

A culture that merges development and operations so the same team builds, ships, and runs its software, with fast feedback from production back to the code. It is enabled by automation: CI/CD, infrastructure as code, and observability. The point is closing the loop between writing software and operating it.
Not really, and the ‘DevOps engineer’ title is usually a misnomer. DevOps is a way of working, not a role you slot between dev and ops, that just rebuilds the wall. Most ‘DevOps engineer’ jobs are actually platform or infrastructure engineering: building the automation other developers use. The label is wrong, the work is real.
When an org creates a separate DevOps team that owns deploys so developers do not have to. That is the old dev-versus-ops wall with a new name. DevOps fails whenever the people building the software are insulated from the pain of running it, because the feedback loop that justifies the whole approach is gone.