Faster releases. Without losing track of what's in production.
Several deployment tools run side by side, every team has its own branching model, and moving a version between environments is finished by hand. It slows every release down — and worse, nobody can say from one place which version runs where, where it came from, and who approved it.
Two questions run through everything here.
The lead time from merge to a running version, how often you deploy, and how many manual steps sit between a commit and production. The usual finding is a promotion between environments that someone still finishes by hand.
Change failure rate and rollback time, how many deployment tools run in parallel, how many applications are actually reconciled rather than only declared, and how many releases carry a full chain of evidence — signed commit, SBOM, signed image, policy gate, approval record.
Every engagement starts by measuring both gaps and ends by closing them. One caveat on the evidence: a check that prints a warning and deploys anyway proves nothing. It counts once the pipeline can actually stop a release.
A version reaches production in three moves: build it, promote it, run what you declared.
Build it
A commit becomes an artefact with a provable origin — assembled, scanned and signed by a pipeline, with a bill of materials for what is inside it. What reaches the registry traces back to the code it came from.
Promote it
The version travels through development, integration, acceptance and production on a defined route, with approvals scaled to risk and a lifecycle that says what is active, what is in maintenance and what is switched off.
Run what you declared
What runs is what's declared in Git. Change something by hand in the cluster and the controller reconciles it back automatically. (If you'd rather be alerted first and decide yourself, that mode is available too — it's a deliberate setting, made per application.)
What we deliver
Four ways to engage
The same lifecycle as everywhere at G2F — assessment, build, operations, enablement — focused on one question: can you say from one place which version runs where, and who let it in?
01
AssessDevOps Capability Assessment
An independent read of how a change really reaches your production.
- An as-is map of the change path — which deployment and CI tools run in parallel, where promotion is still done by hand, how branching governance differs between teams, and what the pipeline is missing to prove where an artefact came from.
- The Flow gap and the Control gap — where the path stalls and where the trail is lost. Real findings look like this: secrets managed centrally but certificates renewed by hand, unsigned commits, pipelines scattered with no central view of failures.
- To-be recommendations — a consolidation plan, standardised pipelines, a supply chain gate, version lifecycle policy and an approval model scaled to risk. Including what makes an open-source component defensible to an auditor.
- A prioritised roadmap — every recommendation ranked by impact and by how hard it is to implement, sequenced into phases, with a management summary for the board.
02
BuildA consolidated, provable change path
A targeted implementation of one layer of the change path, typically a follow-on from the assessment. What you keep is a path your own team deploys through.
- Consolidation and standardisation — parallel deployment tools become one main route, with standardised templates and one branching model. What isn't worth migrating gets an end-of-life date.
- Repository structure — the first and most expensive decision of a GitOps delivery: code separated from the deployment declaration, environments as overlays, a promotion strategy — decided at the start.
- Reconciliation actually switched on — an app-of-apps structure, so adding an application is a change in Git, not the cluster, with sync, self-heal and drift alerting enabled per application, and the controller chosen inside the delivery.
- Supply chain gate and secrets — SBOM in the container build, signed images, configuration validated before deployment; report mode before enforce. Secrets arrive from outside the repository.
- Progressive delivery — designed, not delivered. Canary and A/B releases with a defined success criterion, so rollback is triggered by data, not a phone call. Not yet implemented in production.
03
OperateChange-path maintenance & on-demand
A change path decays more quietly than infrastructure. Pipelines start failing, the team gets used to restarting them, and the gate gets stepped around just this once.
- Maintenance of pipelines and workflow templates as environments and tool versions move underneath them.
- Pipeline visibility run proactively — failures get picked up before a team reports them. A missing central view of CI/CD was an explicit finding at a real banking client.
- Enforcement of the version lifecycle, release support for demanding deployments, troubleshooting and on-demand consulting blocks. Typically part of a wider support arrangement rather than a standalone line item.
04
TrainGitOps training for your team
Your team should own the change path after we leave.
- Training for your internal team on GitOps principles — the declarative model, repository structure, promotion between environments, and what changes in daily work once the cluster stops being changed by hand.
- Built around your environment and your stack, not a generic curriculum.
- Hands-on inside the delivery: your team takes over the pipeline and the GitOps repository as it is built.
We run this ourselves
The change path we design for clients is the one we run ourselves. It is declared in two Git repositories and ArgoCD puts it into the cluster: commit, push, and the environment follows. Sync and self-heal are switched on, so a change made by hand is corrected automatically. Secrets live outside the repository in OpenBao. The controller is the only component installed by hand; everything else comes from Git.
Delivered
Where we've done this
Change paths we've assessed, consolidated and run — for banks, regulated fintechs, critical infrastructure operators and SaaS product companies.
🇨🇿
A three-area DevOps capability discovery for a bank — as-is analysis, target architectures and a phased roadmap.
Read the case study →
ArgoCD driving application deployment into a Kubernetes platform in a regulated fintech — multi-environment configuration in production, and the same declarative path used to bring applications back after a recovery.
Read case study →
A GitOps concept and a controller comparison — manual versus GitOps, ArgoCD versus FluxCD — with an app-of-apps structure and a demo application wired to Git.
An automated deployment pipeline for a multi-tenant SaaS product — a change path built clean for a product team, rather than consolidated out of legacy.
Can you say which version runs where — and who approved it?
A DevOps Capability Assessment maps the change path as it really works, measures the Flow gap and the Control gap, and hands you a prioritised roadmap with a management summary for the board. Three areas, or just the first. Most first conversations take 30 minutes. No pitch, no deck.