Why does effective full-stack automation require a cultural change, and what did DevOps change?

Automation across the whole stack fails if development and operations stay separate teams with separate goals. DevOps merges them: programmers become responsible for deploying and running their code, and the (virtualised) infrastructure is treated as code.

Historically the split was clear. Dev built the applications, and Ops made sure they ran for users and the business. Before virtualisation this made sense, because infrastructure was physical hardware that needed specialist hands.

Once infrastructure became software (VMs, then containers and cloud APIs), the split turned into friction. Developers threw releases "over the wall", operations had to keep them running without having built them, and each side optimised for its own goal: change on one side, stability on the other.

From the early 2000s a movement began to treat development and operations as one unit:

• programmers are responsible for deployment and maintenance too,
• therefore the virtualised infrastructure is handled as code, with the same tools (version control, review, tests) as the application.

The tools alone are not enough. A pipeline that automates deployment is of little use if a separate team still has to approve and carry out each step by hand.

Go deeper:

• DevOps — Wikipedia — history, practices and the relation to SRE and GitOps.