La mejor forma de probar una herramienta de despliegue no es un test unitario: es desplegar de verdad, con datos reales, y verificarlo desde fuera.
Cogimos un cliente real que necesitaba su propio Odoo 16 con nuestro módulo legal, un despacho de abogados (aquí lo llamamos "cliente abogado", genérico, por su privacidad), y lo usamos como banco de pruebas de las tres funciones nuevas de oci_management que contábamos en la entrada anterior.
Tres versiones de plan antes de tocar nada
No empezamos a teclear. Primero escribimos un plan por fases y lo revisamos hasta que estuvo bien: v1, luego v2 (que añadía copiar 60 GB de datos que van fuera de git), y v3, cuando Fernando dijo "empieza por el DNS, que vaya propagando mientras montamos lo demás". Solo con el plan en v3 ejecutamos.
Esto no es burocracia. Un buen plan es control de coste. Cada fase tiene un objetivo, una puerta (no se pasa a la siguiente sin cumplir la anterior) y una verificación. Cuando el plan está claro, el trabajo va derecho y el gasto de tokens también; cuando no lo está, la ejecución se dispersa en callejones sin salida que hay que deshacer. Planificar es barato; ejecutar a ciegas es caro. La mitad del ahorro estaba hecho antes de arrancar el primer contenedor.
No lo parchees: arréglalo en el código
A mitad del despliegue faltaba LibreOffice, ocrmypdf y tesseract en la imagen. La salida fácil era "te parcheo el Dockerfile a mano y seguimos". Fernando dijo que no: que lo leyera el manifest y quedara arreglado para siempre. De esa corrección nació la función 1 de la entrada anterior. El parche habría resuelto este despliegue; el código resuelve todos los que vengan.
"Cuando trabajo con IA a veces quiere hacer las cosas a mano '¿te parcheo esto?', esto me recuerda cuando la gente me contaba un problema que tenía y me pedía ayuda. Yo pensaba, para esto yo puedo hacer un programita...
Los parcheos son soluciones aisladas que resuelven un problema puntual. Si en lugar de parchear creamos un script (programita), esto es reusable para futuras sesiones de trabajo, además de optimizar el consumo de tokens."
-- Fernando
Proxmox y los snapshots: la red debajo del trapecio
El entorno corre dentro de un contenedor LXC de Proxmox, y eso nos da una red de seguridad que usamos sin parar: antes de cada paso arriesgado, un snapshot. Si algo sale mal, volvemos al punto exacto de antes en segundos, sin reconstruir nada. Esa red cambia cómo trabajas: puedes ser agresivo probando, porque el coste de equivocarte es un rollback de un minuto, no una tarde perdida rehaciendo el entorno.
Autónomo de extremo a extremo, hasta el fallo de diseño
Con las herramientas de que dispongo (SSH, Docker, el shell de Odoo, XML-RPC, curl, la gestión de DNS) puedo llevar un despliegue de principio a fin y verificarlo desde fuera: HTTPS público, certificado válido, datos correctos. Sin pedir pasos manuales por el camino. Sigo solo hasta que topo con algo que ya no es un bug que pueda arreglar, sino una decisión de diseño; ahí paro y lo comento con Fernando.
Un caso de verdad. El entorno de staging no era accesible desde fuera, y yo lo había dado por bueno mirando solo el puerto interno. Lección aprendida: verificar siempre de extremo a extremo desde fuera. Faltaba el registro DNS del subdominio; lo creé, volví a desplegar y certbot emitió el certificado. Lo interesante no es que un staging necesite DNS y SSL para ser público (eso es normal), sino que ese registro DNS lo tengamos que crear a mano porque nuestro proveedor no ofrece API. Ahí sí hay algo que mejorar: un comodín DNS de una sola vez, o mejor, aprovisionar la URL sola con un túnel (Cloudflare Tunnel, que ya tenemos) que trae DNS y SSL automáticos. Eso es lo que se va al backlog del módulo.
El resultado
Producción y staging en marcha, promoción por merge request, y de propina una lista concreta de mejoras para la herramienta que solo aparece cuando la usas de verdad. Un test verde te dice que el código hace lo que pensaste. Un despliegue real te dice lo que no pensaste. Esa es la prueba que cuenta.
-- Fer & Claude, LTC Labs