Every conference talk about DevOps shows the same slide: a CI/CD pipeline diagram with neat boxes and arrows. Code goes in one end, deployments come out the other. It looks clean. It looks simple. And it completely misses the point. DevOps isn't a pipeline. It's a culture shift that changes how development teams and operations teams relate to each other. The pipeline is a side effect.
What You Need to Know
- DevOps is a cultural and organisational change, not a tooling decision
- The core shift: developers take responsibility for what happens after deployment, and operations enables developer velocity
- Most organisations that claim to "do DevOps" have adopted the tools without the culture
- For small NZ enterprise teams, the practical benefit is faster, safer releases with fewer people involved
The Old Model
In the traditional model, developers write code and throw it over the wall to operations. Ops takes the code, figures out how to deploy it, deals with the infrastructure, and manages it in production. When something breaks, ops calls the developers. The developers say "it works on my machine." Everyone is frustrated.
This separation made sense when deployment meant shipping physical media and infrastructure meant racks of servers in a basement. In 2018, it makes no sense at all. Cloud infrastructure is provisioned with code. Deployments are automated. The boundary between "writing the software" and "running the software" has dissolved.
But organisational structures haven't caught up. Many enterprises still have separate development and operations teams with separate managers, separate budgets, and separate incentives. Development is measured on features shipped. Operations is measured on uptime. These incentives are fundamentally in tension.
What DevOps Actually Means
Developers Own Production
This is the shift that matters most. When the developer who wrote the code is also responsible for it running successfully in production, the quality of that code changes. Logging improves because the developer knows they'll be the one reading the logs at 2am. Error handling improves because the developer will be the one paged when it fails. Performance matters because the developer sees the production metrics.
The fastest way to improve code quality is to make the person who wrote it responsible for running it. Nothing concentrates the mind like being on call.
John Li
Chief Technology Officer
Operations Enables Velocity
In the DevOps model, the operations function shifts from gatekeeper to enabler. Instead of receiving deployment packages and figuring out how to install them, ops builds the platform that lets developers deploy safely and independently.
Self-service infrastructure provisioning. Automated deployment pipelines. Monitoring and alerting that developers can configure themselves. The operations team's job is to make deployment boring, reliable, and fast. Their success metric isn't uptime in isolation. It's how quickly and safely developers can ship changes.
Shared Accountability
When development and operations share accountability for outcomes, the adversarial relationship dissolves. Nobody throws anything over a wall. Developers understand operational constraints because they experience them directly. Operations understands development velocity because they're measured on it.
The Tooling (Because Everyone Asks)
Yes, there are tools. They matter, but they're secondary to culture.
Continuous integration (Jenkins, GitLab CI, CircleCI) ensures every code change is built and tested automatically. This catches integration issues within minutes, not days.
Continuous deployment (or delivery, depending on your risk appetite) automates the path from tested code to production. At minimum, the deployment process should be a single command that any developer can execute.
Infrastructure as code (Terraform, CloudFormation, Ansible) means your infrastructure is versioned, reviewable, and reproducible. No more snowflake servers that nobody knows how to rebuild.
Containerisation (Docker, Kubernetes) provides consistent environments from development through production. The "it works on my machine" problem becomes solvable because every machine runs the same container.
Monitoring and observability (Prometheus, Grafana, ELK stack) gives both developers and operations visibility into system behaviour. Not just "is it up?" but "how is it performing, where are the bottlenecks, and what changed?"
46x
more frequent deployments for elite DevOps performers
Source: DORA State of DevOps Report, 2018
The NZ Enterprise Reality
Most NZ enterprise teams are small. Five to fifteen developers. One or two people with operations responsibilities, often part-time. The full Google-scale DevOps transformation isn't realistic and isn't necessary.
What is realistic:
Automate deployments. Even a simple shell script that deploys to production consistently is better than a manual checklist. Get to the point where deploying is boring and routine, not a stressful event that requires a meeting.
Make developers responsible for monitoring. The developer who builds a feature configures the alerts for that feature. They're the first call when something goes wrong. This doesn't require a formal on-call rotation. It requires a cultural expectation.
Version your infrastructure. Even if you're running on a single cloud server, define it in code. When that server needs to be rebuilt at 3am, you want to run a script, not follow a wiki page that was last updated eight months ago.
Invest in CI first. Automated testing on every commit is the highest-value DevOps practice for small teams. It catches bugs before they reach production and builds confidence in the deployment process.
The Culture Change Is the Hard Part
Every organisation I've worked with can adopt the tools in weeks. Jenkins, Docker, Terraform - the technology is well-documented and the learning curve is manageable.
The culture change takes months, sometimes years. Getting developers comfortable with production responsibility. Getting operations comfortable with letting go of deployment control. Getting management comfortable with teams that cross traditional organisational boundaries.
Start with the culture. The tools will follow naturally. Start with the tools alone and you'll have a very expensive CI/CD pipeline that deploys the same broken code faster.