A deployment to a production Odoo system is a routine act that becomes an incident the moment it is done without a runbook. The runbook is short and mechanical, and the discipline is running it the same way every time, including the times it feels unnecessary. This is the playbook.
Before: the pre-deploy checks
- The change ran on staging. The exact change, on an environment that faithfully mirrors production. If it has not run on staging, it is not ready for production. This step is not negotiable.
- The change is in version control, and the commit being deployed is identified. You should know exactly what is shipping.
- Pick the window. Deploy when a problem can be noticed and handled: not at end of day, not before a weekend, not during the system's busiest hour.
- The rollback plan is written down. Before the deploy, not during.
The rollback plan, written first
Decide, in advance and in writing, how you would undo this. For most Odoo deployments that is two things: the previous code commit to return to, and a fresh database backup to restore if the change altered data or schema. The rollback plan is written before the deploy because the moment you need it is the moment you are least able to think clearly. A deploy without a rollback plan is not a deploy, it is a bet.
During: the deploy sequence
- Take a fresh backup. Immediately before the change, not last night's. Confirm it completed.
- Deploy the code and run the module update so Odoo loads the new Python, XML, and assets.
- Watch the logs through startup. A module that fails to load says so here, clearly.
After: the smoke test
The deploy is not finished when the server restarts. It is finished when you have confirmed the system works. Run a short, fixed smoke test: load the main pages, run one transaction through the core flow, and specifically exercise the thing that just changed. The smoke test is the same every time, so that "it passed" means something. If it fails, you execute the rollback plan you already wrote, calmly, because you wrote it.
The note for the file
None of this is clever, and that is the point. A deployment runbook is valuable precisely because it is boring and identical every time. The incidents happen on the deploy where someone decided this one was small enough to skip the steps.