Notes on a small team's deployment pipeline

Most small teams ship the same way: someone connects to a server, drags files around, and hopes the rollback zip is still on someone's laptop. I wanted to understand whether a six-stage flow — develop, dev/CI, staging, pentest, production, rollback — could remove that anxiety without making the process feel like enterprise theatre.

The interesting part was not the tooling. It was watching where ownership ambiguity quietly created the most risk, and how just naming the owner at each stage changed the team's behaviour.

What it looks like in practice

I wrote it up as a working internal site rather than a Confluence page, because nobody opens a Confluence page on the day they actually need it. The checklist below is the kind of thing a developer can scan before requesting environment access — one page, ten items, owner per row.

What changed after rolling it out

Three things showed up almost immediately. First: people started asking different questions. Instead of "who owns this", the discussion shifted to "is this checklist still accurate". Second: the pentest stage stopped being an afterthought. Once it was a named stage with a documented owner, the team treated findings as deliverables, not interruptions. Third: rollback stopped being a heroic act. The rollback stage forces you to plan the rollback before you plan the deploy — which is the only time it actually gets planned.

The SOP is a living document. The version visible at the top of the page is v1.2 — and that number matters. It means the team owns it, edits it, and disagrees with it when reality has changed. A frozen SOP is a dead SOP.