WORKED EXAMPLE · CLOUD
A deploy path that behaves the same every time
A manual release path replaced by coded environments and a tested pipeline for one service, with rollback conditions written down.
THE SITUATION
The company shape
A product team runs one main web application and a small set of background services in a single cloud account. Staging was built by hand and has drifted from production.
Releases depend on one engineer who knows the manual steps. Rollback has never been rehearsed, so every release carries a risk nobody can describe precisely.
DISCOVERY
Weeks 1 to 2
We would map the estate: environments, services, dependencies and the owner of each production service.
We would compare configuration, data shape and deploy steps across development, staging and production, and read the recent deploy history.
Together we would choose one service that changes often and has a clear rollback boundary as the first path.
The rollback conditions for that path would be written down before any code changes.
BUILD
Weeks 3 to 6
We would write the infrastructure for the chosen service's environments as code, in the team's repository.
A pipeline with checks, approvals and the agreed rollback conditions would replace the manual steps for that service.
One real change would travel through development, staging and production on the new path, observed at each stage.
The platform owner would run a release on the new path themselves, using the runbook, before handover.
AT THE END
What the client would hold
Cloud & Modernization
A modernization plan, coded infrastructure, a deployment pipeline and an operating runbook.
Cloud and DevOps
A coded environment baseline, deployment pipeline and platform runbook.
LIMITS
What we would have said no to
A rewrite into microservices
The problem is an unrepeatable deploy path, not the shape of the application. Splitting it would add moving parts before the path is safe.
Changing cloud provider
Moving providers would not fix drift between environments, and it would multiply the work.
Every service at once
The first increment covers one service. The others follow the same path once it has worked in production.
A cutover weekend
Changes go out in small steps with a rollback decision each time, not in one event that has to go right.
Bring your own situation
Describe what you run and where it hurts. We reply with how the first two weeks of cloud work would look for you.