Deployment & Releases
A button instead of a checklist: every build takes the same route out.
- CI/CD
- Rollback
- Repeatable
How it works
Releasing should be boring. If it is exciting, something about the procedure is wrong.
One route for everything
From the main branch to production, everything runs through the same pipeline: tests, build, deploy. No side routes for urgent cases — the urgent ones are precisely where mistakes happen.
The way back first
Before we build a route out, we build the route back. Returning to the previous version has to be a command you can still execute correctly at 11pm.
Database changes
Migrations run automatically and are written so the previous version still works against the new schema. That keeps the way back open even when the data model has changed.
Mobile is slower
With apps, store review sits in between. We set things up so features can be switched on after release — then a date does not depend on another company’s review queue.
- A decision on who is allowed to approve a release.
- A maintenance window, if your operation cannot take changes during business hours.
A delivery pipeline anyone on the team can operate, with a way back to the previous version.
If you skip this
Manual releases happen rarely, because they are unpleasant. Rare releases mean large batches, and large batches go wrong more often — the fear of releasing produces exactly what people are afraid of.
Questions about this step?
A conversation costs nothing and takes half an hour. Afterwards you will know whether we are a fit.