Practice
Deployment should be boring.
CI/CD, containers and infrastructure as code, delivered with the observability and runbooks that make them safe to hand over. Releases become routine instead of events.
- Kubernetes
- Terraform
- GitHub Actions
- Argo CD
- Helm
- Prometheus
- Grafana
- GitOps
What we hear
The conversations that bring people here.
Releases go out on a Saturday, because that’s when we can afford the downtime.
Head of Engineering
Two people know how to deploy it. One of them just resigned.
Engineering Manager
Staging stopped resembling production about a year ago.
Platform Lead
What we do
Four things, done properly.
CI/CD pipelines
Build, test, deploy and roll back as one automated path — the same path for every environment, so a release is a routine operation rather than a decision.
Containers & Kubernetes
Containerising services for scalability and portability, with the cluster configuration, scaling policy and resource limits set deliberately rather than by default.
Infrastructure as code
Environments defined in Terraform and rebuilt from the repository, so the thing running in production is the thing described in version control.
Observability & on-call
Metrics, logs and traces wired to alerts a human can act on, with runbooks for the alerts that actually fire.
What’s different now
Where AI-assisted delivery actually changes this practice.
Specific to this work, not a paragraph repeated across every page.
Pipeline, IaC and runbooks in one pass
These used to be three sequential projects, and the documentation was whichever one got cut. They are now produced together, because producing them together is no longer the expensive option.
Every service, not just the important ones
Onboarding a service to a pipeline was manual work repeated per service, which is why estates end up half-automated. That repetition is the part that compresses most.
Old services included
Containerising a service nobody remembers writing used to be a research exercise. It is now a normal ticket.
Tools, technology and platforms
What we run it with.
Where you already have a pipeline, we work inside it — we would rather inherit your Jenkins than spend three weeks arguing for ours. Where there is nothing yet, this is what we reach for.
Selected work
What changed, in the client’s terms.
Three recent engagements from this practice.
From a three-hour deployment to ten minutes
Deployments were done by hand. Each release needed several stakeholders available at the same time, dependencies were tracked informally, and the window was two to three hours with downtime inside it. Read the case study→ Blockchain infrastructure · MonitoringWatching blockchain nodes from the outside in
The platform’s whole service is the condition of its customers’ blockchain nodes: endpoint health, status visible in real time, and CPU, memory and disk read early enough to act on. Read the case study→ Identity management · Observability
An observability stack built to order
A complex cloud estate with no central place to see it, producing millions of logs an hour that were effectively unqueryable during an incident. Read the case study→A two-week paid pilot
Fixed price, on a real piece of your backlog. You keep the output whether or not you continue.