CI/CD Pipeline Setup in Two Hours: Why Only 21% Manage It
Only 21% of teams can get a working build and deploy pipeline into a new environment in under two hours. The missing time is not technical: it is waiting between teams. A golden path with self-service removes most of it.
A new service is ready to leave the laptop of the person who wrote it. What is left is getting it running in a shared environment: build, scan, test and deploy. In most organisations this step is not measured in minutes. It is measured in tickets.
One ticket to create the environment. Another for credentials. Another for the security scan. Another for approval from whoever runs the infrastructure. Each with its own queue.
What the report says
The survey was carried out in February 2026 by Coleman Parkes, commissioned by Harness, among 700 engineering practitioners and managers at large enterprises in the United States, the United Kingdom, Germany, France and India. It is a self-reported figure, not a measured one, but the pattern it describes is familiar.
The same report shows where the delay sits. More than three quarters of respondents, 77%, say teams often need to wait on others for routine delivery work before they can ship code. And 69% admit to wasting time on slow or unreliable pipelines, which they link to burnout.
Two hours as a measure of dependency
The time it takes to get a new pipeline working rarely measures a team's technical skill. Setting up a continuous integration and continuous delivery (CI/CD) pipeline is well-established knowledge. What the time measures is how many teams and tickets sit between the code and the environment where it will run.
That is why hiring more people to answer tickets does not shorten the path. It adds capacity to the queue, but the queue remains.
Where the time goes
The steps that usually depend on another team are much the same from one organisation to the next:
- Environment: creating the space where the service will run, with networking and permissions.
- Credentials and secrets: getting access to databases, queues and external services.
- Security: dependency and image scanning before any deployment.
- Pipeline configuration: writing, or copying and adapting, the build and deploy definition.
- Approval: sign-off for the first deployment to a shared environment.
Each step is reasonable on its own. The problem is the sum of the waits.
And waits do not add up in a straight line. A ticket that stalls at the end of the day only moves again the next morning. A ticket that comes back with a question returns to the back of the queue. The waiting team switches to another task in the meantime and, when the answer arrives, has to pick the context up again. The result is that a path of five simple steps can take several calendar days without anyone having worked on it for more than an hour.
There is also a less visible effect. When getting a service running is expensive, teams avoid creating new services and keep adding features to the ones that already exist. The architecture ends up being decided by the cost of the queue rather than by the design that would make sense.
The golden path
The Cloud Native Computing Foundation (CNCF), in its white paper on platforms, describes a concrete answer: a reusable workflow for building, scanning, testing, deploying and observing an application, offered with an initial project template and documentation. That bundle is what is often called a golden path.
In practice, the team does not write a pipeline from scratch. It starts from a template that already integrates build, security scanning, testing and deployment, and adjusts only what is specific to the service.
Self-service, with rules
The same CNCF paper sets out two properties that change the time equation.
The first is self-service: platform users should be able to request and receive capabilities autonomously and automatically, without manual work from another team. An environment or a database requested through a command or a form, and delivered with its credentials.
The second is being secure by default. Security rules and approvals live inside the template rather than being requested case by case. The platform team decides the rules once; each product team applies them by activating the template.
This combination turns a chain of tickets into a single controlled step.
What the golden path is not
The golden path is not an obligation or a straitjacket. The CNCF paper is explicit: a platform should be optional and composable, and should allow product teams to provide and manage their own capabilities outside the platform's offerings when necessary. The template serves the common case; the unusual case remains possible, with more effort and more responsibility for whoever chooses it.
Nor does it hand operations over to product teams. The same source states that a platform should encapsulate implementation details, and that its users must not be responsible for operating the services it offers. The team activates the template; the platform team maintains what sits underneath.
How to measure it
Three simple measures are enough to know whether the path is getting shorter:
- Time from request to first deployment of a new service in a shared environment.
- Number of steps that wait on another team along that path.
- Share of pipelines that follow the template, against those written from scratch.
Stability belongs alongside these. A pipeline that is quick to create but slow or unreliable to run brings the waiting back, and that is the time 69% of respondents say they lose.
Where to start
There is no need to build a complete platform to shorten the path. A practical route starts with four steps:
- Pick the most frequent type of service, the one the organisation creates most often.
- Map the current path for that service, from request to first deployment, with every wait identified.
- Turn the step with the longest wait into self-service, keeping the rules that already existed.
- Measure again the time from request to first deployment, then repeat with the next step.
Each round removes one queue from the path. The complete template emerges from the sum of these rounds, not from a project designed from scratch.
Five questions before calling delivery autonomous
- Is there an approved pipeline template any team can activate without a ticket?
- Are security scans and approvals built into the template?
- Is a new environment created through self-service, credentials included?
- Does anyone measure the time from request to first deployment?
- Is there a team or an owner responsible for maintaining the golden path?
Conclusion
Two hours is not a hard technical target. It is an organisational one. As long as getting a service running depends on a chain of tickets, delivery speed is set by the slowest queue, not by the team that wrote the code.
The difference between buying capacity and building a platform that works is covered in Platform Engineering Outsourcing, and when it makes sense to reinforce the in-house team is covered in DevOps as a Service, when it makes sense. To review the path to production and design the golden path, it is possible to book a Clarity Session, with no commitment.