Deployment checklist: how to update a website and roll back if it fails
Published on 2026-10-26 by frfrand
Practical deployment plan, smoke tests, migrations, and rollback
The typical Friday deploy: the build finishes fine, but the login stops working, and only then does someone ask if there was a backup. A simple checklist avoids repeated errors, especially when the project has a base with real clients.
Let's get down to earth: what it means, how to test it, and what happens when you use it with clients or real information. Most problems are not fixed with a magic button, but with steps you can repeat and measure.
What is a Pre-Deployment Checklist and why it matters
Publishing code is a sequence of checks: version-controlled code, tests, migrations, variables, services, monitoring, and a rollback plan. You don't need a huge corporate process; just steps your team can actually execute and verify.
One thing is for a demo to work for five minutes, and another is to sustain a service every day. For that, you need limits, permissions, activity logs, and procedures to resolve failures without improvising.
Implementation or diagnosis example
# Verificaciones orientativas
git rev-parse --short HEAD
python manage.py check
python manage.py test
sudo nginx -t
sudo systemctl status miapp
curl -fsS https://api.ejemplo.com/health
# Confirmar antes compatibilidad de migraciones y datosIt is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimal permissions, and make sure no sensitive key ends up in a log or repository.
How I would put it into operation
- Identify the commit and the person responsible for the deployment.
- Run tests and prepare migrations compatible with both the previous and new versions.
- Verify a restorable backup and a rollback plan for code and schema.
- Publish first to staging or a controlled environment and run smoke tests.
- After deployment, verify login, database operation, webhook, and error rate before closing the incident.
After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or an established metric. If something does not work, check what the first failure was before retrying in a loop.
An example that may appear in a real project
A booking platform publishes a new payment method. The backend changes the payment schema, the frontend shows a new button, and a webhook confirms it. The checklist forces testing an end-to-end booking before announcing that it is finished.
If that application has multiple clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools should not bypass privacy and authorization limits.
The most common mistake
Do not confuse reverting a commit with restoring data: if a migration deleted a column, returning to the previous code may fail just the same. Use schema-compatible changes and a safe procedure.
A configuration with good defaults helps, but does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and mid-process failures.
Where does ArduMaker fit in?
With ArduMaker you can link the Git repository, VPS, service, and domain. Document the published commit and a smoke test, even if the panel says "successful deployment."
With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to bring operations together in one environment, although business logic and security rules remain the responsibility of the software.
What I would measure to know if it improved
I would not measure only "works/doesn't work." I would also review resource consumption, errors, response times, or API usage, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.
If a piece of data looks strange, check the sample and the time window. An average can hide extreme cases, and a single successful run does not prove that an automation can handle thousands of requests.
Frequently asked questions
Do I need a large infrastructure to get started? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.
What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume that external APIs are always available.
How do I maintain control? Log important events, separate permissions, and keep a proven procedure to undo changes or recover information.
References to follow
The final idea: automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.