Understanding DevOps: Building and Running Software as the Core of Continuous Delivery

As someone promoting the concept of continuous delivery, I view DevOps not as the primary concept but as a crucial movement that helps us achieve continuous delivery.

The core DevOps idea—"you build it, you run it"—means that the people who create software must also be responsible for its operation, which has real implications for collaboration and impact.

DevOps has many definitions; one useful definition is that it is the combination of people, processes, and technology to deliver continuous value to end users.

In my view, DevOps is a way to achieve continuous delivery. It is not the only way, but without the collaborative core of DevOps, continuous delivery becomes very difficult.

Without continuous delivery (CD), DevOps has little meaning; it is not a role or a technology, nor does it define a team. Before the basic idea of continuous delivery emerged, vague uses of DevOps made the term confusing.

The goal of DevOps is to help us achieve continuous delivery, addressing the same challenges and reinforcing each other. Keeping a system in a releasable state means more than just building new features—it also means staying releasable when the environment changes.

This requires detecting changes in the environment, understanding them, and reacting by adjusting the system so it remains releasable.

Our system must be technically and functionally correct enough to provide value to users; if it crashes under load, it no longer adds value and cannot be truly released. Therefore, we must track production behavior to ensure changes are safe and meet user expectations.

We need to stay vigilant, continuously monitoring our software because we never know when a change might make the software un‑releasable.

The most effective way to keep a system permanently releasable is to detect problems early, before they become disasters.

By continuously tracking usage, we can spot changes and early warnings of increased demand.

We can plot trends and anticipate demand direction, allowing us to increase capacity before hitting limits, which is far better than waiting for a crash.

Knowledge gained from production behavior will inevitably change how we build software.

Development teams must understand how software runs and be able to react to events; they are best positioned to implement measures based on production insights.

From an efficiency perspective, production data is complex and unpredictable, and we often lack time to react, so we should keep development teams in the feedback loop to see what happens in production.

I recall working on an unstable production system that was slow and sometimes crashed; by observing logs and patterns, we wrote code to highlight warning signs and added alerts, allowing us to restart services before a crash and reduce impact.

This technical practice of DevOps lets builders see the value of their work from a user perspective, fostering ownership and motivation.

Changing how we record errors makes it easier to detect crash precursors, improving communication and monitoring for developers.

Developers should build and run software directly, but many teams know little about the production environment that hosts their code.

Therefore, there are two sensible responses: either control the environment or write defensive code that can survive host changes.

These responsibilities belong to the development team, not solely to operations; only by keeping infrastructure up‑to‑date can operations protect the software.

Similarly, product managers or sales teams should not be expected to handle technical details of isolating applications from OS or configuration changes.

Development teams must understand the optimal runtime environment; architecture and infrastructure are not tasks for non‑developers. Cloud computing exemplifies this, offering self‑service, software‑driven infrastructure that can be version‑controlled and orchestrated.

Letting development teams define production configuration makes system changes easier, though some large enterprises may be skeptical.

Shifting many responsibilities to developers can lead to organizational inefficiencies if handled incorrectly; a flow‑aligned team topology is a better model, giving responsibility for user‑facing changes to cross‑functional teams supported by platform and subsystem teams.

This subtle shift does not offload platform responsibilities; those teams still monitor and run the systems in production.

However, the controversial point remains: if software fails at 3 am, who is responsible? The answer is the person who built the software.

No one wants a 3 am phone call, and even the best operations team reacts slower than the original developers who understand the system best.

When problems arise, developers can be on‑call, and the experience of handling a midnight incident motivates them to prevent future occurrences.

Ideal organizations allow everyone to see the outcomes of their decisions and act to correct sub‑optimal results.

Thus, being woken up at 3 am to fix an issue creates pressure to build better software, reinforcing the DevOps principle that the builders own the responsibility for quality.