Cloud & DevOps

Deploys that are boring, and undo themselves when they are not

One artefact is built, scanned and promoted — staging automatically, production on your word. If a health check fails, the previous version is back before anyone has opened a dashboard.

One artefact, two live versions, and a health check deciding which one keeps the traffic. The live path carries the volume; the canary proves the next one.

The pipeline

One artefact, six gates, and a way back

Built once. Everything after that is a promotion of the same image — never a rebuild, because a rebuild means the thing you tested is not the thing you shipped.

01
Commit
Types, tests, architecture rules and dependency checks. A failure here never becomes an artefact.
02
Build — once
One image per commit. Nothing downstream ever rebuilds it, which is what makes the rest of this track mean anything.
03
Scan
Vulnerabilities and licences, before the image is allowed to move rather than after it has shipped.
04
Staging — automatic
No approval, no ceremony. If it passed the gates it is on staging, and staging is built from the same code as production.
05
Production — on your word
The one manual step, and it is yours. The same image, promoted; never a fresh build that has passed nothing.
06
Verify, or roll back
Health checks decide. If one fails the previous version is back automatically — before anyone has opened a dashboard.

Who it is for

You are probably here for one of these

A release is an event

Somebody stays late, everybody watches, and it happens monthly because it is too expensive to do weekly. Which means every release carries a month of changes, which is why it needs watching.

It worked on staging

Because staging was built by hand at a different time from production, and nobody can say precisely how the two differ. The list of differences is the list of things that will break.

Something is wrong and nobody can say what

The dashboard says CPU is fine. The customer says the page is blank. There are logs, and they are lines of text with no request to tie them to.

What we do

Named things, not capabilities

Every line below is something that exists when the work is finished — a service, an index, a check that runs in your pipeline.

Build once, promote: One artefact per commit, built once and never rebuilt per environment
Scanned for vulnerabilities before it is allowed to move
Staging automatically; production on your approval
The image that passed staging is the image that reaches production
Infrastructure as code: Terraform for what exists, Ansible for what runs on it
Environments that differ by variables rather than by history
Secrets held by the platform, never in the repository
Deploys that undo themselves: Health checks that gate promotion instead of reporting after it
Automatic rollback when one fails
Zero-downtime releases, and a traffic split when a release warrants one
Observability that names the failure: Structured logs tied to a request, not lines of text
Traces that cross service boundaries
Alerts that say what broke, not that a number moved

What you get

The things that are yours at the end

Objects rather than activities. Each of these is something you hold, in your own repository, whether or not we are still working together.

A pipeline that promotes rather than rebuilds

The artefact that passed your tests is the artefact that reaches your customers. Rebuilding per environment is how a green staging run stops meaning anything.

Infrastructure in code, in your repository

Reviewable, diffable, and reproducible from an empty account. The environments differ by variables you can read rather than by whatever was done to them in 2022.

A rollback you have watched work

Not a documented procedure — a failed health check, triggered on purpose, rolling back while you watch. A rollback nobody has ever run is a plan, not a capability.

A runbook, and alerts that name the failure

What to do at three in the morning, written by the people who built it, plus alerting specific enough to be worth waking someone for.

Stack

What this line is built with

Chosen per system rather than per company. Where two things sit together below, we treat them as interchangeable and pick on the day.

Clouds: AWSCloudflareVercel
Packaging and runtime: DockerPodmanKubernetesnginxLinux
Infrastructure as code: TerraformAnsible
Pipelines: GitHub ActionsArgo CD
Seeing it: PrometheusGrafanaOpenTelemetryDatadogSentry

Engagement

How it runs, and how it is bought

Most often fixed scope: a pipeline has a definable finish line, and discovery can see it. Teams without anyone to run it afterwards usually keep a small continuous engagement for dependency currency and incident support.

Fixed scope

A defined deliverable, priced once — after discovery has said what it is, never before. What is in, what is deliberately out, and what we are assuming about your data and your deadlines is written down first.

Suits A first version, a migration with a known end, or a pilot with a decision at the end of it.

Continuous delivery

A team on your work month to month. A written update every week and a working build you can open — not a status percentage, the thing itself, running.

Suits A product still finding its shape, or a system that needs to keep moving after it launches.

Team extension

Engineers inside your team: your repository, your conventions, your release process, your stand-up. A good deal of our work is delivered this way, so it is a shape we have real practice at rather than one we are trying on.

Suits A team that knows what to build and is short of the people to build it.

01
Discovery
1 week
How it builds, deploys and fails today — written down, including the steps that only exist in someone’s shell history.
02
Pipeline running
2–4 weeks
One artefact per commit, scanned, promoted to staging automatically.
03
Rollback proven
within the same window
A health check failed on purpose and the previous version back, watched by your team rather than described to them.
04
Production on your word
4–6 weeks
Promotion to production behind an approval, zero downtime, and a rollback that does not need one.

Indicative, and stated as ranges on purpose. What moves them is how many surfaces you need at once, how much of the existing system has to keep running, and how quickly decisions can be made on your side — never how many people we add.

Related work

Where this line has been used

All work

April 2024

SODVELONCON 2024

The 18th National Conference of the Society of Dermatologists, Venereologists and Leprologists of Nepal — Hotel Barahi, Pokhara.

A two-day national conference where registration, payment and attendance all had to work at once, in front of the delegates. Registration alone spanned nine delegate categories across three pricing tiers in two currencies, and once the doors opened the organisers needed to know who was in which hall, live, without a queue forming at any of them.

Web platform
Mobile app
Backend
UI/UX and graphics
On-site IT

Questions

Asked before, answered here

We are on AWS. Or a VPS. Does that change the answer?

The shape does not change — build once, scan, promote, roll back. What changes is what implements each step. A single VPS with containers and a health check gets the same guarantees as a managed cluster, at a fraction of the operational cost.

Do we have to move to Kubernetes?

No, and usually you should not. Kubernetes solves problems most systems do not have and adds ones they did not. We run it where scale or an existing team justifies it, and containers on a smaller runtime everywhere else.

How long until we can deploy on a Tuesday afternoon?

The pipeline is normally running to staging within a month. Deploying on a Tuesday afternoon is a question about confidence rather than tooling — that comes from the rollback working, which is why we prove it early rather than document it late.

Who owns the infrastructure afterwards?

You do, throughout. It is your cloud account and your repository from the first commit; we work inside them. There is no transition project at the end because there is nothing to transition.

What about secrets and access?

Held by the platform’s own secret store, never in the repository and never in an environment file passed around. Our access is scoped to what the work needs and revoked when it ends.

Start here

Tell us what you are building

Or what is breaking, or what has to go faster. You will get a straight answer from an engineer who would do the work.

Start a project