Boring deployments are a feature
You can learn a lot about an engineering organisation by asking one question: what happens on release day? If the answer involves a checklist, a specific person who "knows the steps," a window when nobody else should touch anything, and a slightly elevated heart rate — the deployment process is carrying risk that belongs in software.
What boring looks like
A boring deployment has four properties. It's identical every time — one pipeline, no manual steps, no "just this once" SSH sessions. It's reversible — rollback is a tested command, not a theory. It's observable — within minutes you know from dashboards, not from users, whether the release is healthy. And it's frequent — small releases shipped often carry less risk each than a quarter of changes shipped at once, because the diff you're debugging is one day's work, not ninety.
None of this requires exotic tooling. GitHub Actions, a container registry, and discipline get most teams there. The hard part isn't technology; it's refusing to accumulate manual exceptions.
The Kubernetes question
Kubernetes deserves a paragraph because it's where small teams most often buy complexity they can't operate. It solves real problems — scheduling, self-healing, rolling updates — and we run it happily where the workload justifies it. But a three-service application with steady traffic doesn't need a cluster; it needs a container service the cloud provider operates for you. The honest sizing question is not "will we need this at scale?" but "who fixes this at 2 a.m. today?" If the answer is "the one developer who set it up," the platform is bigger than the team.
Pipelines are the team's memory
The under-appreciated benefit of putting everything in the pipeline is that the pipeline becomes documentation that cannot go stale. How is the database migrated? Read the workflow. What environment variables exist in staging? They're declared, versioned, and reviewed. When the person who set up the system leaves — and eventually everyone leaves — the pipeline stays.
That's the standard we build to: a deployment any team member can run on a Friday afternoon without telling anyone. Not because Friday deploys are brave, but because when they're genuinely safe, the word "brave" stops applying.
← All insights