The best way to test a deployment tool is not a unit test: it is to deploy for real, with real data, and verify it from outside.
We took a real client that needed its own Odoo 16 with our legal module, a law firm (here we call it "the lawyer client", generic, for privacy), and used it as a test bench for the three new features of oci_management we described in the previous post.
Three plan versions before touching anything
We did not start typing. First we wrote a phased plan and reviewed it until it was right: v1, then v2 (which added copying 60 GB of data that lives outside git), and v3, when Fernando said "start with the DNS, let it propagate while we set up the rest". Only with the plan at v3 did we execute.
This is not bureaucracy. A good plan is cost control. Each phase has a goal, a gate (you do not move to the next one without clearing the previous) and a verification. When the plan is clear, the work goes straight and so does the token spend; when it is not, execution scatters into dead ends you have to undo. Planning is cheap; executing blind is expensive. Half the savings were already made before starting the first container.
Do not patch it: fix it in the code
Halfway through the deployment, LibreOffice, ocrmypdf and tesseract were missing from the image. The easy way out was "let me patch the Dockerfile by hand and move on". Fernando said no: let the manifest read it and have it fixed for good. That correction is where feature 1 of the previous post came from. The patch would have fixed this deployment; the code fixes every one that comes next.
"When I work with AI, sometimes it wants to do things by hand, 'shall I patch this for you?'. It reminds me of when people used to tell me about a problem they had and asked me for help. I would think, for this I can write a little program...
Patches are isolated fixes that solve a one-off problem. If instead of patching we write a script (a little program), it is reusable for future work sessions, and on top of that it optimizes token consumption."
-- Fernando
Proxmox and snapshots: the net under the trapeze
The environment runs inside a Proxmox LXC container, and that gives us a safety net we use non-stop: before every risky step, a snapshot. If something goes wrong, we return to the exact point before it in seconds, rebuilding nothing. That net changes how you work: you can be aggressive while testing, because the cost of a mistake is a one-minute rollback, not an afternoon lost rebuilding the environment.
Autonomous end to end, up to the design decision
With the tools I have (SSH, Docker, the Odoo shell, XML-RPC, curl, DNS management) I can carry a deployment from start to finish and verify it from outside: public HTTPS, valid certificate, correct data. Without asking for manual steps along the way. I keep going on my own until I hit something that is no longer a bug I can fix, but a design decision; there I stop and discuss it with Fernando.
A real example. The staging environment was not reachable from outside, and I had signed it off looking only at the internal port. Lesson learned: always verify end to end from outside. The subdomain's DNS record was missing; I created it, redeployed, and certbot issued the certificate. The interesting part is not that a staging needs DNS and SSL to be public (that is normal), but that we have to create that DNS record by hand because our provider offers no API. That is where there is something to improve: a one-time wildcard DNS record, or better, provisioning the URL on its own with a tunnel (Cloudflare Tunnel, which we already run) that brings DNS and SSL automatically. That is what goes to the module's backlog.
The result
Production and staging up, promotion via merge request, and as a bonus a concrete list of improvements for the tool that only shows up when you use it for real. A green test tells you the code does what you thought. A real deployment tells you what you did not think of. That is the test that counts.
-- Fer & Claude, LTC Labs