Deploys that took an afternoon now take minutes and no specialist

Business context

A property listings platform runs on twelve staff, four of them developers. The site serves landlords and renters, and new listings go live all day. Releases were infrequent because they were painful, and the team knew it. They asked for a CI/CD setup for small teams: something four developers could maintain without hiring a release engineer. We handled it as part of our cloud and delivery work.

The problem

Deploys happened over SSH from one developer's laptop, following a step list kept in a note. A release took about two hours and had to happen after hours. Only one person knew the whole process, so holidays were planned around releases. The written instructions, such as they were, lived in a chat thread and had drifted from reality months earlier.

There was no staging environment. Bugs reached customers before the team saw them, and the first sign of a bad deploy was a support message. Rolling back meant another manual session, with no guarantee it would restore the previous state.

What we built

We automated the path from merge to production. Every pull request now runs tests and builds a container image. Merging to the main branch deploys to a staging environment and posts a preview link in the team chat. A person checks that link, then approves the production deploy with one click.

Terraform describes the infrastructure, so the servers and environments are reproducible rather than hand-built. Docker keeps staging and production consistent, which removed a class of bugs where something worked in one place and not the other.

Error tracking and uptime checks alert the team's chat within minutes. A rollback button returns to the previous image, and this is the change that shifted how the team felt about releasing. When a build fails, the developer can see which step stopped it without logging into a server.

We also wrote a runbook: what each alert means, who to call, how to roll back. It is deliberately short, one page.

We kept the pipeline configuration in the repository and the credentials in the platform's own secret store, so nobody has to copy a password onto a laptop. Any developer can open the pipeline file and read every step, which is how the process stopped belonging to one person.

Rollout

• Week 1: Mapped the current release steps and wrote them down as they actually happened, not as the note claimed.
• Week 2: Added tests and the build pipeline, running it on every pull request without deploying.
• Week 3: Stood up staging and the preview links, and moved the infrastructure into Terraform.
• Week 4: Turned on production deploys, alerting and the runbook, then watched the first ten releases closely.

Before and after

Step	Before	After
Release	Manual SSH, about 2 hours	One click, about 9 minutes
Staging	None	Every merge gets a preview link
Rollback	Another manual session	One button, previous image
Errors	Found by customers	Alert in chat within minutes
Knowledge	One developer	A runbook anyone can follow

Results

Deploy time fell from about two hours to nine minutes. The team went from roughly two releases a week to seven. Errors were detected in about four minutes instead of hours, and no failed deploy reached customers after the first month.

The bigger change was who could deploy. Three developers now release without asking the one who used to do it alone. Incidents during the change window were zero.

Deploys also stopped being a late-night activity. Releases happen in the middle of the afternoon now, which the team says is the part they notice most.

Lessons learned

• The runbook mattered as much as the pipeline. It removed the single person everyone depended on, which was the real risk all along. The cloud bill review we did for a SaaS startup reached a similar conclusion: the fixes that last are the ones written down.
• We underestimated how much the tests would need cleaning up. The first suite passed every build because half the tests checked nothing at all. A week of deleting weak tests did more than adding new ones.
• The team did not trust automatic deploys at first. Letting them approve each production release for a month built enough confidence to make it automatic later.