The pipeline works, mostly. That is what makes it hard to fix.
It is slow, it fails for reasons nobody can predict, one person understands it, and changing it feels riskier than living with it. Deploys have quietly become something you schedule.
A deploy means following a document, and the build takes so long nobody runs it before pushing.
Change lead timeTests fail often enough that a red build is assumed to be noise, so the signal that should stop a release no longer does.
Change fail rateNobody can say what is in production, who put it there, or which commit it came from.
UntraceableStaging and production differ in ways nobody wrote down, so passing staging predicts nothing.
Change fail rateThere is a rollback procedure in principle. It has never been run for real.
Recovery timeAgent-written pull requests went up, and the review burden went up with them.
Review loadOn that last one, DORA’s 2025 finding is worth knowing: AI acts as an amplifier. It magnifies what a strong delivery system already does well, and magnifies the dysfunctions of a weak one. A team whose gates were thin does not get faster when the volume of pull requests doubles — it gets less safe. Source: DORA
Fixing a pipeline is not buying a platform
CI/CD Pipelines
One team, one stack, one pipeline estate. Somebody has a pipeline that is slow, fragile or unowned, and wants it fixed.
SDLC Golden Paths
The same work standardised across many teams, so six teams stop maintaining six different pipelines.
Infrastructure as Code
The Terraform the pipeline deploys. Frequently bought together, because the two problems are hard to tell apart from the inside.
Buying only this one is a normal outcome. It is the most common way a client meets us, and it does not require agreeing to a platform strategy first.
Build it, test it, deliver it, deploy it
Triggers from version control, a reproducible build rather than one that depends on a single machine, image tagging that ties an artefact back to a commit, and layer and dependency caching so the build is quick enough that people wait for it. The most appreciated deliverable here is the least glamorous — making the build several times faster.
The stages that run your tests: parallelisation, caching, sharding, quarantine so one known-bad test stops blocking everyone, coverage reporting, and rules about which failures genuinely stop a release. We do not write your test suite — see below.
Deployment into staging and other pre-production environments made genuinely comparable to production, database migration handling, and artefact promotion so the thing you tested is the thing that ships. Terraform and Helm as the mechanism.
Production deployment through GitOps with Argo CD or Flux, or your existing runner where GitOps does not fit. Progressive delivery where it earns its place — canary, blue/green, feature flags to separate deploy from release — and a rollback executed at least once for real before we hand over.
We build the stages that run your tests. We do not write the tests.
The pipeline around the tests
The stages that run them. The security and policy checks are different — those we do author.
The test suite itself
We are infrastructure and platform engineers rather than a software house, and the same split applies here as on Application Modernisation.
The work that cuts across every stage
Security and policy gates
Static analysis and dependency scanning, container image scanning with Trivy, infrastructure-code scanning with Checkov or tfsec, policy as code through OPA, and secret detection. These checks we write.
Secrets and access
Secrets out of pipeline configuration and into a vault or your provider’s secret store, short-lived credentials through OIDC rather than long-lived keys sitting in CI, and pipeline access through your existing identity provider.
Evidence for auditors
Every deploy leaves a trail and every change passes an approval gate, so what an auditor asks for is a query rather than a scramble. To be precise about it: this is what the pipeline produces. It is not a certification, and it is not ours to hold.
Migrating off a legacy CI
Usually Jenkins. Phased, with both systems live until the new one is trusted, because a big-bang CI migration is how delivery stops for a fortnight.
Measured at both ends
From a merge to running in production.
How often you can ship without drama.
The share of deploys that need a fix afterwards.
How long to recover when one goes wrong.
Work redone because a change did not hold.
We have not yet published a before-and-after table from a completed engagement; when we do, it will carry the five metrics and how each was measured.
We measure, we build, and then we leave
We measure before touching anything: the five DORA metrics from data you already have, plus where the time actually goes in a build and where the failures actually come from. You get a written baseline and a scope in priority order.
The agreed work, in your own repositories, with the existing pipeline alive until the new one has earned trust.
Documentation, runbooks, and a team that can change the pipeline without us. Then we measure again, against the same baseline.
There is deliberately no fourth step where we stay on indefinitely. This is scoped engineering work.
What you are actually choosing between
Your own platform team
They can do this. Everyone agrees the pipeline needs work, and it has lost the prioritisation meeting to product work every quarter for two years. We are not better than your team — we finish, because it is the only thing we are doing.
Keeping on patching
Free, until it is not. Each patch is sensible on its own; the aggregate is a pipeline nobody understands. The cost is engineer-hours per deploy times deploys, plus the incidents a tested rollback would have shortened.
A generalist DevOps contractor
Will build you a pipeline. Whether your team can change it afterwards depends entirely on who turned up, and the failure mode — a working pipeline nobody can modify — looks exactly like success for about six months.
Your CI vendor’s professional services
Deep on their own product, and structurally unable to tell you that the product is a poor fit or that half the problem is the test suite.
Some teams should not buy this engagement
A team deploying once a quarter and content with that does not need this engagement, and we would rather say so here than bill for finding out.
Tick the ones that are true
Four questions. Your answers stay in your browser.
The questions that come up first
Which CI/CD tools do you support?
GitHub Actions, GitLab CI including self-hosted, Jenkins, and the cloud-native runners — AWS CodePipeline and CodeBuild, Google Cloud Build, Azure DevOps Pipelines. We work in the CI you already have rather than moving you to a favourite, and we will tell you when we think a move is worth making.
Can you migrate our legacy setup?
Yes, and it is the most common engagement. Phased, with the old system running until the new one is trusted. Nobody should stop delivering for a fortnight to gain a faster pipeline.
Do you do GitOps?
Argo CD or Flux, where it fits. It usually fits when the target is Kubernetes and usually does not otherwise — treating GitOps as universally correct would be easier to write and less useful to you.
What security do you implement?
Static analysis and dependency scanning, image scanning, infrastructure-code scanning, policy as code, secret detection, secrets in a vault rather than pipeline configuration, short-lived OIDC credentials instead of long-lived keys, approval gates, and a full audit trail.
Do you offer an SLA, and are your pipelines compliant?
We do not publish an SLA. On compliance: we build the controls and the evidence trail an auditor asks for, and we do not hold — or claim on your behalf — SOC 2, ISO 27001 or HIPAA certification. The distinction costs a sentence and is worth it.
Will this slow us down while you do it?
Briefly and visibly, or not at all, depending on the work. Your existing pipeline keeps running throughout. We would rather tell you what the disruption is than promise there is none.
Will we be locked into you?
Your repositories, your CI, your cloud, your credentials. Nothing we build depends on OpsHero continuing to exist.
Talk to an engineer
Not a salesperson. You will get a read on your pipeline, where the time is actually going, and what the work would involve.
- A baseline across the five DORA metrics, from data you already have
- Where the time goes in a build, and where failures actually come from
- A scope in priority order — what is slow, what is unsafe, what can wait
- Everything delivered into your own repositories