Deploy days have a rhythm. For the first few hours everything is calm: branches merge, tests run, someone makes tea. Then the clock moves towards the release window and the small questions start to pile up. Did we back up the database? Is that API key in production? Who is telling support?

None of those questions is difficult. They are just easy to forget, because they are not the interesting part of the work. A checklist fixes that — not a bureaucratic one nobody reads, but ten points you can run through in fifteen minutes and trust. Here is the version worth keeping in your repository.

Tests and a build you can rebuild

Start with the obvious, because it is skipped more often than anyone admits. Does the suite pass on the exact commit you are deploying, on a clean checkout? Green locally means very little if CI was never run or the branch still needs a merge.

Two rules are worth insisting on:

• Run the whole suite. "It's only a CSS change" has a long and unhappy history.
• Deploy the artefact you tested. Build once, then promote that same build through staging and into production, rather than compiling something new on release day.

The smoke test you will actually run

Write down five or six things a person should click after the deploy: sign in, load the dashboard, complete one representative action, submit the contact form, check the homepage on a phone. Keep the list short enough that nobody argues about doing it. Automate what you can, but do not pretend a green pipeline proves the login page works.

Backups you have restored, not just taken

A backup nobody has restored is a hope, not a plan.

• Take a fresh one immediately before deploying, and note the time somewhere the whole team can see it.
• Restore it somewhere harmless at least once a quarter, and time the process. That duration is your real recovery time, not the estimate in the runbook.
• Check the parts people forget: uploaded files, search indexes, queued jobs, and anything you would have to re-fetch from a third party.

If the release includes a database migration, decide now whether it can be reversed, and whether the old code would still run against the new schema. Migrations that drop or rename columns are the ones that turn a rollback into a proper incident.

Environment variables and configuration

Most "fine on staging, broken in production" bugs are configuration. Compare the two environments variable by variable before you deploy.

• Are all required keys present in production, with the correct values and no stray whitespace?
• Are secrets still in the secret store rather than copied into a file somebody will eventually commit?
• Has anything new appeared since the last release — a third-party key, a feature flag, a queue name, a storage bucket? Code that fails on a missing variable owns the first five minutes of your incident.
• Do the defaults fail safely? If a variable is absent, the app should refuse to start loudly rather than quietly connect to the wrong database.

Keep a documented list of every variable the app expects. It ages well and settles arguments quickly.

A rollback plan you can describe out loud

If you cannot explain how to undo this deploy in three sentences, you do not have a rollback plan.

1. The previous release artefact is tagged and stored somewhere you can reach in under a minute.
2. The command or pipeline job that redeploys it is written down, not remembered.
3. You know whether the database change can be reversed, and what happens if it cannot.
4. One named person can call it without asking three others first.

Agree a threshold in advance. If error rates or a key journey look wrong ten minutes after release, roll back and investigate with the pressure off. Rolling forward while users are affected is a decision, not a default.

Monitoring that finds trouble before your users do

Deployments fail quietly more often than loudly, so somebody has to be watching.

• Error tracking that alerts on new exception types, not just on volume. A stack trace that appears only after a release is a signal.
• A health endpoint covering the app and its critical dependencies — database, cache, queue — plus an uptime check hitting it from outside your network.
• Alerts routed to a person on shift, in a channel they actually read. An alert nobody sees is decoration.
• Searchable logs that include the release version or commit hash, so "did this start with the deploy?" takes seconds to answer.

If you have time for one item only, make it the error tracker. It is usually the shortest path from "something is wrong" to "here is the line of code".

Tell the right people

Small teams skip this because everyone sits within earshot. Then a deploy lands in the middle of a sales demo.

• Confirm the window with anyone who depends on it: support, sales, whoever is running a campaign that day.
• Post a short note when the deploy starts and when it finishes, with the version number and anything worth watching.
• If users might notice a blip, say so before it happens. A status page entry or a line in the support briefing beats an apologetic reply later.

Decide in advance who answers customer questions, and give them one sentence they can use.

The five-minute final pass

Run these in order before you press the button:

1. Tests green on the commit, artefact built and tagged.
2. Fresh backup taken, restore path known.
3. Environment variables checked against the list.
4. Rollback command and threshold agreed.
5. Monitoring and alerts live.
6. Support and stakeholders told.

Then deploy, watch for fifteen minutes, and leave unrelated changes alone until the graphs settle. Afterwards, write down anything that surprised you. The checklist is not sacred: every incident you have lived through should add or sharpen a line. A list edited once a quarter will do more for your team than most tools you could buy this year.

Photo: RDNE Stock project / Pexels