The most dangerous part of shipping software is the last mile - the moment an approved build becomes running infrastructure. Done manually, it is the step where environments drift, a forgotten config breaks production, and rollbacks turn into panic. The goal is to make that last mile so automated and observable that releasing is a non-event. Here is the shape of how we do it: Pulumi for infrastructure, AKS for runtime, and deployment events that are health-gated and reversible.
Infrastructure as real code with Pulumi
We express infrastructure with Pulumi rather than YAML templates, because infrastructure has logic - loops, conditionals, shared modules - and a real programming language handles that far better than a templating dialect. The cluster, namespaces, and workloads are described in .NET, type-checked, and reviewed like any other code:
var deployment = new Deployment("orders", new DeploymentArgs
{
Spec = new DeploymentSpecArgs
{
Replicas = edition.Replicas,
Template = PodTemplate(image, edition),
},
});
Because it is code, an environment is reproducible: the same program applied to a different stack yields a consistent environment, instead of a hand-tended snowflake.
Edition-aware rollouts
Not every tenant or plan gets the same deployment. An edition - which features, which scale, which region - parameterizes the rollout, so the same pipeline produces the right shape for each target without branching logic scattered across scripts. The edition is data; the deployment program reads it and provisions accordingly.
Health-gated promotion
The rollout does not declare success because pods started. It waits on the readiness and startup probes we discussed in our health-checks work, and only promotes traffic once the new version reports genuinely healthy. If the probes do not pass within the window, the rollout halts instead of serving a broken version:
strategy:
rollingUpdate: { maxUnavailable: 0, maxSurge: 1 }
# new pods must pass readiness before old pods are retired
This is the difference between deploying and releasing - code can be on the cluster while traffic stays on the known-good version until health is proven.
Note: A deployment that reports success the instant a container starts is lying. Gate promotion on real health signals, or you will route users to a process that is up but not working.
Deployment events make it observable and reversible
Every stage of the rollout emits an event - started, promoted, completed, or failed - carrying the version and correlation id. Those events do three things: they give you a live, auditable picture of what is deploying where, they let downstream systems react, and they make rollback a first-class operation. Because the previous known-good version and its configuration are captured, rolling back is applying the prior state, not reconstructing it under pressure.
Wrapping up
The automated last mile rests on four ideas: describe infrastructure as real, reviewable code with Pulumi; parameterize rollouts by edition; gate promotion on genuine health signals; and emit deployment events so the whole process is observable and reversible. Put them together and the riskiest moment in software delivery becomes the most routine - which is exactly where you want it to be.
Want your deployments to be boring in the best way? Let's automate the last mile.
