Engineering · DevOps and Containers
DevOps and Containers
Deployment is a copy. Files go onto a server, the server drifts, and rollback means restoring a backup and hoping. [Draft copy]
The problem
If deployment is a file copy, the server is the application.
Code reaches production by copy — a script, a pipeline step, or somebody with access. Over time the server accumulates a runtime version, a set of packages and three manual fixes that exist nowhere else. That configuration is now part of your application, and it is not written down.
"It works on staging" stops meaning anything, because staging is a different machine with a different history. Rollback is a restore. And the system cannot move to another host, another data centre or another cloud without a project, because nobody knows what the current one is actually made of.
What enterprise-grade looks like here
The deployable unit is an image, not a folder.
Containerising the application makes the runtime part of the artefact. The image carries the operating system libraries, the runtime version and the dependencies with it, so the thing tested in staging is the identical thing running in production — not a rebuild of it. That is what platform-agnostic actually means in practice: the same image runs on a developer laptop, on your own hardware, or on any cloud, because none of them is being asked to supply the environment.
Rollout then becomes a property of the tag. Images are immutable and tagged, so you deploy a known version, roll forward in stages, and roll back by pointing at the previous tag. No restore, no reconstruction, no drift — and a straight answer to "what exactly is running in production".
We are deliberate about the runtime. Docker Compose is enough for a great many mid-market estates, and we will say so. Kubernetes earns its complexity when you need real scale, self-healing or multi-tenancy, and costs you more than it returns when you do not.
This framing repeats on every capability page. It is the differentiator, and it reads consistently across all of them (§9 T3).
What we do
Five moves, in this order.
-
Containerise the application
A Dockerfile per deployable, built once, with the runtime and dependencies pinned. Build-time and run-time concerns separated so images stay small and scannable.
-
Make the image the only path to production
One artefact promoted through every environment. Configuration comes in from outside; the image itself never changes between staging and production.
-
Choose the runtime honestly
Docker Compose where that is sufficient. Kubernetes where scale, resilience or tenancy genuinely require it. We would rather talk you out of a cluster you do not need than sell you one.
-
Control rollout by tag
Immutable tags and a registry that keeps them, staged rollout with health gates, and rollback as a tag change rather than an incident.
-
Hand over the runbook
How to build, tag, promote, roll back and read the logs — written for the team that will be holding it at two in the morning.
[Draft copy]
What you end up owning
Documents and configuration, not a dependency.
| Deliverable | Owned by |
|---|---|
| Dockerfiles and compose definitions per service | Engineering |
| Image registry with a tagging and retention convention | Platform team |
| Kubernetes manifests or Helm charts, where used | Platform team |
| Rollout and rollback runbook | Operations |
| Environment configuration held outside the image | Platform team |
[Draft copy]
Tell us what you are being asked to prove.
Tell us how code reaches production today, and we will tell you what it would take to make that an image and a tag.
Start a conversation