DevOps is a way of building and running software in which development and operations work as one team, automating the path from a code change to production so that releases become small, frequent and safe. Its core practice is the CI/CD pipeline: continuous integration, continuous delivery and, where it fits, continuous deployment.
This guide explains what DevOps is, how a CI/CD pipeline works stage by stage, the difference between continuous delivery and continuous deployment, how to measure delivery with the DORA metrics, and what changed by 2026 with platform engineering, GitOps and cloud cost control. It ends with when it makes sense to bring in an external DevOps team. For the cultural side of DevOps, see DevOps culture: communication, collaboration and integration.
TL;DR / Key Takeaways
- DevOps combines culture, practices and tools so that teams deliver software faster and more reliably, breaking down the silo between development and operations.
- A CI/CD pipeline automates build, test and release: every change is integrated, tested and made ready to deploy without manual steps.
- Continuous delivery keeps every change releasable; continuous deployment goes one step further and releases every change that passes the tests.
- DORA's five metrics measure delivery throughput and instability: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
- In 2026 the focus has moved to internal platforms, GitOps and cloud cost visibility, so that good delivery practices scale across many teams.
What is DevOps?
DevOps is an approach to software development and delivery that emphasises collaboration and communication between development and operations teams. AWS describes it as the combination of cultural philosophies, practices and tools that increases an organisation's ability to deliver applications and services at high velocity. At its core, it removes the hand-offs between writing code and running it.
In practice, DevOps streamlines the software development lifecycle, from code creation to deployment, by automating key processes and breaking down silos between teams. The same people who build a service share responsibility for how it is released, monitored and fixed in production.
The approach relies on continuous integration, delivery and deployment practices that automate testing and releasing new code. Because every change is tested and verified automatically before it reaches production, teams can release more often without increasing risk.
DevOps toolchain diagram by Kharnagy, Wikimedia Commons, CC BY-SA 4.0.
How does a CI/CD pipeline work?
A CI/CD pipeline is the automated path every code change follows to production. A developer commits code; the pipeline builds it, runs automated tests, packages a versioned artefact, deploys it to a test or staging environment, runs further checks and then releases it, either on approval or automatically. Monitoring closes the loop.
Pipelines differ between teams and products. A typical one has these stages:
- Commit: a small change is pushed to the shared repository, ideally several times a day.
- Build: the code is compiled and dependencies are resolved in a clean, repeatable environment.
- Automated tests: unit, integration and security tests run on every change; a failure stops the pipeline.
- Package: the build produces one versioned artefact, such as a container image, that is promoted unchanged through every environment.
- Deploy to staging: the artefact is deployed to an environment configured like production, through infrastructure as code.
- Acceptance checks: end-to-end, performance and accessibility tests confirm the change behaves as expected.
- Release: the change goes to production, with a manual approval in continuous delivery or automatically in continuous deployment.
- Monitor: logs, metrics and alerts show how the change behaves for real users and feed the next iteration.
The key rule is that the pipeline, not a person, decides whether a change is ready. If a step fails, the team fixes the pipeline or the code before doing anything else, so the main branch always stays in a releasable state.
What is the difference between continuous integration, delivery and deployment?
Continuous integration means merging code changes into a shared repository often and testing them automatically. Continuous delivery means every change that passes the tests is ready to release to production at any time, with a person deciding when. Continuous deployment removes that decision: every change that passes is released automatically.
| Practice | What is automated | Who decides to release | Best fit |
|---|---|---|---|
| Continuous integration | Merging, building and testing every change | Nobody releases yet | Every team, as the baseline |
| Continuous delivery | Everything up to a production-ready release | A person approves the release | Regulated products, scheduled releases, B2B software |
| Continuous deployment | Everything, including the production release | The pipeline, when all checks pass | Web products with strong test coverage and monitoring |
Continuous delivery is defined as the ability to get changes of all types, including new features, configuration changes, bug fixes and experiments, into production or into the hands of users safely and quickly in a sustainable way. Continuous deployment is only safe when tests, monitoring and rollback are strong enough that nobody needs to check each release by hand.
What are the benefits of DevOps?
DevOps gives organisations a faster time to market, better collaboration between teams, more reliable and higher-quality software, and a more efficient use of resources. The benefits come from smaller, more frequent releases: each one carries less risk, is easier to test and is faster to fix if something goes wrong.
- Faster time to market: automating the development and release process shortens the time it takes to deliver new features.
- Better collaboration and communication: removing the silo between development and operations leads to better software and fewer delays at hand-off.
- Higher reliability and quality: every change is tested and verified before it reaches production, so fewer defects reach users.
- More efficient use of resources: automation and less waste reduce manual work and costs.
How do you measure DevOps performance?
The standard way to measure DevOps performance is with the DORA software delivery metrics. DORA has identified five: change lead time, deployment frequency and failed deployment recovery time measure throughput; change fail rate and deployment rework rate measure instability. Tracked over time, they show whether delivery is getting faster and safer.
According to DORA, change lead time is the time a change takes from being committed to version control to being deployed in production. Deployment frequency is the number of deployments over a period, and failed deployment recovery time is how long it takes to recover from a deployment that fails and needs immediate intervention.
On the instability side, change fail rate is the ratio of deployments that require immediate intervention, typically a rollback or a hotfix. Deployment rework rate is the ratio of unplanned deployments that happen as a result of an incident in production. DORA replaced its earlier four-key model, which used mean time to restore, with this five-metric model.
What are the DevOps best practices in 2026?
The practices that matter most are small, frequent changes on a shared main branch, automated tests on every change, infrastructure defined as code, security checks built into the pipeline, and monitoring that tells the team how each release behaves. Tools change quickly; these principles have stayed stable.
- Small batches: integrate changes at least daily and keep branches short-lived, so conflicts and failures stay small.
- Test automation: unit, integration and end-to-end tests run in the pipeline; a failing test blocks the release.
- Infrastructure as code: servers, networks and configuration are defined in versioned files, not changed by hand.
- Security in the pipeline: dependency scanning, secret detection and static analysis run on every change, not once before release.
- Observability: logs, metrics and traces are part of every service, with alerts that someone owns.
The tools have changed, but the foundations have not. Continuous integration still follows the practices Martin Fowler described in his article on continuous integration: everything in a version-controlled mainline, an automated and self-testing build, and everyone pushing commits to the mainline every day.
What are platform engineering and GitOps?
Platform engineering is the practice of building an internal platform that gives development teams ready-made, self-service paths to build, deploy and run software. GitOps is a way of operating that platform in which the desired state of systems is declared in Git and software agents continuously reconcile the running systems with it.
The CNCF defines a platform for cloud-native computing as an integrated collection of capabilities defined and presented according to the needs of its users. In practice it means that a new service gets its pipeline, environments, monitoring and security defaults from templates, instead of each team rebuilding them.
The OpenGitOps principles define GitOps in four points. The desired state is declarative; it is versioned and immutable; it is pulled automatically by software agents; and it is continuously reconciled with the actual state. Every change to production then becomes a reviewed change in Git, with a full history and an easy rollback.
How does DevOps affect cloud costs?
DevOps makes it easy to create environments and resources, which is why it can also make cloud bills grow quickly. The fix is to treat cost like any other quality signal: tag resources by team and service, show cost per environment in the same dashboards as performance, and remove unused resources automatically.
Ephemeral test environments that are destroyed after each pipeline run, autoscaling based on real load, and switching off non-production environments outside working hours are the usual DevOps answers. Cost reviews belong in the same rhythm as delivery reviews, so that engineering and finance look at the same numbers.
This is the territory of FinOps, which brings engineering, finance and business teams together around cloud spend. WWG's FinOps optimisation service starts from an assessment of actual cloud spend, and our guide to cloud migration planning covers how to design costs in from the start.
When should you hire an external DevOps team?
An external DevOps team makes sense when releases are still manual and risky, when no one in-house owns the pipeline and infrastructure, or when a migration or new platform needs skills the team does not yet have. The goal should be a delivery path your own team can run, not a permanent dependency.
WWG's DevOps consulting services focus on making delivery repeatable: automating the build, test and release path, defining infrastructure as code, putting monitoring and alerting in place, and changing the practices around them so that releases stop being events. Concretely, we can help you:
- implement continuous integration, delivery and deployment;
- automate testing and deployment processes;
- improve collaboration and communication between development and operations;
- optimise resource use and reduce costs.
Sometimes you need capacity inside your own team rather than a project. In that case, dedicated DevOps engineers can own the pipelines, infrastructure definitions and monitoring alongside your developers.
Frequently Asked Questions
Is DevOps a job role or a culture?
DevOps is first a culture and a set of practices shared by development and operations, not a single job title. Many companies still hire DevOps engineers, who build and maintain pipelines, infrastructure and monitoring. The role works best when it enables every team to deliver on its own, instead of becoming a new silo between developers and production.
Which tools are used in a CI/CD pipeline?
A pipeline usually combines a Git repository, a CI/CD server such as GitHub Actions, GitLab CI or Jenkins, a container registry, an infrastructure-as-code tool such as Terraform, and monitoring and alerting tools. The specific tools matter less than automating every step and keeping the pipeline definition itself under version control.
Is DevOps only for large technology companies?
No. DevOps was first adopted by large web companies such as Netflix and Google, but its principles are now used by many traditional companies that want to adapt to the market. A small team benefits from automated tests and deployments just as much, because every manual release step it removes saves time and avoids errors.
Does DevOps replace the operations team?
No, it changes how operations works. Operations specialists move from handling each release by hand to building the platforms, automation and monitoring that let developers release safely. Responsibility for production is shared, so developers are involved when their services fail, while operations focuses on reliability, security and cost across all services.
If you want to make your releases faster and safer, write to us at info@wwg.it.
Sources
- Amazon Web Services, What is DevOps? — https://aws.amazon.com/devops/what-is-devops/
- Continuous Delivery (Jez Humble), What is Continuous Delivery? — https://continuousdelivery.com/
- DORA, DORA's software delivery performance metrics — https://dora.dev/guides/dora-metrics/
- Martin Fowler, Continuous Integration — https://martinfowler.com/articles/continuousIntegration.html
- CNCF TAG App Delivery, Platforms white paper — https://tag-app-delivery.cncf.io/whitepapers/platforms/
- OpenGitOps, GitOps principles v1.0.0 — https://opengitops.dev/
- Kharnagy, Devops-toolchain.svg, Wikimedia Commons (CC BY-SA 4.0) — https://commons.wikimedia.org/wiki/File:Devops-toolchain.svg
