How one team keeps five platforms in production
On-call rotas, a shared deployment pipeline and a rule that nothing ships without a rollback. What running our own products taught us about running yours.
Five products, one engineering team, and none of them allowed to wake anybody at three in the morning without a good reason. That constraint shaped almost every decision we describe below.
One pipeline, not five
Every platform ships through the same pipeline. A change to AzenPlay and a change to SmartSec take the same route to production, run the same checks and produce the same artefact shape. Nobody has to remember how a particular product deploys, because there is nothing product-specific left to remember.
The cost is real: making five quite different applications agree on one build contract took longer than writing five bespoke scripts would have. The payoff is that a person who has never touched a codebase can still ship a fix to it safely.
Nothing ships without a rollback
A deploy that cannot be undone is not a deploy, it is a commitment. Ours stage the new build alongside the old one, swap them with a rename, and keep the previous release on disk. Reverting is another rename.
This sounds obvious written down. It is not what most teams actually do, because the interesting work is in the feature and the boring work is in the escape hatch.
The rota is the architecture
- If a service pages someone, it gets an owner and a runbook the same week.
- If it pages twice for the same reason, the fix goes ahead of feature work.
- If nobody can say what a service does, it gets deleted.
That third rule has removed more code than any refactor we have run.
What transfers
None of this is specific to iGaming, or analytics, or connected devices. It is the same answer every time: make the risky operation boring, make the boring operation automatic, and let the people who understand the domain spend their attention there instead.