Es una de las condiciones que más encarece cualquier trabajo sobre un sistema heredado, y casi nunca aparece en la conversación inicial: no hay dónde probar. El único servidor es el que usan los clientes.
Cuando eso pasa, cada cambio se convierte en una operación nocturna con plan de reversa, y el ritmo del proyecto se divide entre tres.
Por qué no lo hay
Casi siempre por una de estas razones, y ninguna es pereza:
- Costaba dinero y nadie aprobó el gasto de un servidor que «no produce».
- El sistema depende de integraciones con terceros que no tienen ambiente de pruebas.
- Los datos son sensibles y nadie quiere una copia fuera de producción.
- Nadie sabe cómo levantar el sistema desde cero, así que no se puede replicar.
Esa última es la más grave, porque significa que si producción se cae del todo, tampoco se sabría reconstruirlo.
Montarlo, por partes
No hace falta un clon perfecto. Un ambiente de pruebas útil se puede construir por etapas, y cada etapa ya sirve:
1. Que arranque
El objetivo mínimo: que el sistema levante en otra máquina, aunque sea con la base vacía. Solo eso ya documenta el proceso de despliegue, que normalmente no está escrito en ninguna parte.
2. Con datos parecidos
No hace falta copiar producción entera. Basta con un subconjunto que contenga los casos reales: un cliente de cada tipo, una factura de cada situación, los casos raros que siempre rompen.
Si los datos son sensibles, se anonimizan. Cambiar nombres y documentos no altera el comportamiento del sistema y elimina el riesgo de tener una copia con datos personales.
3. Con los terceros simulados
Cuando el banco o la entidad de control no tienen ambiente de pruebas, se sustituyen por una pieza que responde lo mismo que responderían ellos. No prueba la integración real, pero sí todo lo que hay alrededor.
Mientras tanto: cómo trabajar sobre producción sin romperla
Hasta que exista ese ambiente, hay disciplinas que reducen mucho el riesgo:
- Cambios pequeños y frecuentes, nunca un paquete grande. Si algo falla, se sabe qué fue.
- Respaldo antes de cada cambio, y probado que se restaura.
- Un plan de reversa escrito antes de tocar nada, con el tiempo que tarda.
- Ventanas acordadas con la operación, no elegidas por conveniencia técnica.
- Leer más y cambiar menos. En un sistema sin red de seguridad, la mayor parte del trabajo es entender.
El argumento para conseguir el presupuesto
Un ambiente de pruebas cuesta lo que cuesta un servidor pequeño. Lo que ahorra es más fácil de defender si se cuenta así: sin él, cada cambio se hace de noche, con dos personas despiertas y un plan de reversa. Con él, se hace un martes por la tarde.
La diferencia, medida en horas de un año, paga el servidor muchas veces. Y es la primera inversión que recomendamos en casi todo proyecto de retoma.