Push a change that touches the database, and roll it back if it goes wrong
A CSS fix is not the problem. The problem is the deploy with a migration in it, at 17:40 on a Thursday, when everyone who could help has gone home.
The ordinary case
Connect the repository, map the branch, push. The build and the deploy run in front of you with live progress, and the history keeps the commit and the author, so you can see what went out and who sent it.
On production, the build then waits for someone to press Approve before it replaces what's live. If you'd rather it went straight through, you can switch on auto-approve in the configuration.
Deploys are usually quick, so deploying twice in an afternoon is no big deal.
The risky case
When the change touches the database, the order matters more than the tooling.
- Rehearse on real data. Rebuild staging from production, push there, and run it with the modules and the volume you actually have, not last quarter's.
- Gate production on your own tests. Require CI to pass makes the platform wait for the test run your repository already has. A failing run leaves the instance untouched and still serving. It is set per instance, so production can be gated while a staging branch keeps deploying freely.
- Take a backup before the production deploy. It costs a minute now and it is the thing you will want in ten.
- Deploy behind maintenance mode if the change needs quiet, then turn it off. Visitors get a holding page rather than a half migrated screen.
If it goes wrong
Start with the part that catches people. Rollback swaps the running image for an earlier one. It does not touch the database. If the deploy migrated data, rolling back the code alone leaves new data under old code, which is usually worse than either.
So for a deploy that touched the database the sequence is: roll the image back, then restore to the moment before you deployed. That is what the backup in step three is for.
For everything else, roll back to any of the last three successful releases. You do not have to wait for a failure first, a healthy release rolls back just as well, which is what you need when the problem is not an error but a behaviour nobody expected.
A failed deploy can be retried with the same inputs rather than reassembled by hand.
Worth knowing
Not every deploy is the same size. Swapping the running image for a new one is fast. A full rebuild, where the image is built again from your repository, happens when your dependencies change and takes longer, with the same live progress on screen.