Dónde probaremos los cambios cuando abramos CreaRack al público
Hoy los cambios se comprueban directamente en producción, y tiene sentido porque todavía no hay clientes. Este documento explica por qué eso tendrá que cambiar el día que abramos CreaRack al público, qué propone el equipo, si el servidor de pruebas que ya tenemos da abasto y cuándo conviene hacer el cambio. Complementa el apartado 6 de la guía «Cómo trabajamos».
1. Cómo se prueba hoy y por qué vale
Conviene distinguir dos tipos de prueba, porque se hacen en sitios distintos:
- Las pruebas automáticas, las comprobaciones que confirman que el código hace lo que debe, no se hacen en producción. Se hacen en el ordenador de quien hace el cambio y en el servidor de operaciones, que es la máquina del equipo que ejecuta esas tareas, antes de publicar nada.
- La comprobación final, mirar en la pantalla que el cambio funciona de verdad, sí se hace en producción, en crearack.com, justo después de publicar.
Hacer esa comprobación final en producción tiene sentido hoy por tres razones. No hay clientes, así que si algo sale mal solo nos afecta a nosotros. Producción tiene todos los servicios reales y los Agentes conectados, así que es donde el comportamiento es verdadero. Y probar en el ordenador de Edu, con todos los servicios de CreaRack en marcha, consume más recursos de los que ese ordenador puede dar.
2. Qué cambia al abrir al público
Con clientes reales, un error que llegue a producción ya no nos afecta solo a nosotros: lo sufre alguien que paga, con sus datos y su red. Y como hoy fusionar un cambio equivale a publicarlo, cualquier error que se escape de las pruebas automáticas llega directamente a los clientes. Hace falta un paso intermedio donde el cambio se vea funcionando antes de que lo vea nadie de fuera.
Ya tenemos un servidor de pruebas en Hetzner, el que en el Dashboard del Workspace aparece como «Staging». Tiene su propia base de datos, sin datos de clientes. Pero hoy recibe cada cambio a la vez que producción, así que no hace de paso previo: cuando un error llega a él, ya ha llegado también a crearack.com.
3. La propuesta
No hace falta un servidor nuevo para la versión pública. El servidor de producción actual ya es la versión pública: tiene la dirección crearack.com, las copias de seguridad y los Agentes de los clientes conectados a él, y trasladar todo eso a otro sitio sería una mudanza arriesgada que no aporta nada. Lo que cambia es el recorrido de cada cambio:
Pruebas automáticas
Igual que hoy: en el ordenador y en el servidor de operaciones.
Fusionar
Ya no publica para los clientes: publica solo en el servidor de pruebas.
Comprobar en pruebas
Se mira en pantalla, con datos realistas y un Agente simulado conectado.
Pasar a producción
Una persona da la orden explícita de publicar para los clientes.
Comprobar en producción
La comprobación final de siempre, ahora como segunda red.
Para que el servidor de pruebas sirva de verdad, necesita dos cosas que hoy no tiene:
- Datos realistas sin datos de clientes. El programa que creó en producción la empresa inventada de la demostración, Kestrelmoor Group, puede crear otra igual en el servidor de pruebas. Así habría armarios, equipos y pantallas con aspecto real sin tocar datos de nadie.
- Un Agente conectado. Mucho de lo que hace CreaRack depende del Agente, y por eso hoy solo se puede probar bien en producción. El Agente simulado que alimenta la demo podría enviar también sus medidas al servidor de pruebas.
4. ¿Da abasto el servidor de pruebas?
Se midió el 24 de septiembre de 2026, leyendo el uso real de las dos máquinas:
| Recurso | Servidor de pruebas | Servidor de producción |
|---|---|---|
| Procesadores | 2, casi sin uso (carga 0,1) | 4, casi sin uso (carga 0,1) |
| Memoria | 3,8 GB, con 2,0 GB libres | 15,6 GB, con 12,9 GB libres |
| Disco | 38 GB, ocupado al 87 %: quedan 4,7 GB | 150 GB, ocupado al 13 % |
| Lo que consume CreaRack | Unos 450 MB de memoria, sin datos | Unos 1,1 GB de memoria, con la demo y su historia de 60 días |
Procesadores y memoria sí dan abasto. Para que tres personas comprueben cambios no hace falta potencia: no hay tráfico de clientes. Añadir la empresa de demostración y su Agente simulado sumaría, según lo que ocupan en producción, alrededor de medio giga a un giga de memoria. Cabe en los 2 GB libres, aunque justo.
El disco es el problema real, y conviene saber qué lo ocupa, porque el servidor de pruebas hace hoy tres trabajos además de probar:
- Aloja el panel de despliegues, el programa que publica CreaRack en producción. Es lo que más memoria usa en esa máquina, unos 740 MB.
- Guarda las copias de recuperación del Workspace y del servidor de código: las del servidor de código ocupan 12 GB, una copia diaria de unos 720 MB que crece poco a poco, y las del Workspace, menos de 1 GB. Tres tareas automáticas trabajan ahí: la copia del Workspace a medianoche, el envío semanal de esas copias a Google Drive y una comprobación diaria de la documentación. El resto de tareas automáticas del equipo ya se trasladaron al servidor de operaciones en julio.
- Acumula programas y registros: unos 8 GB de imágenes de programas, 3,5 GB de registros y casi 2 GB de ficheros temporales de instalaciones.
El riesgo que importa: si el servidor de pruebas se llenara, no solo fallarían las pruebas. También dejaría de funcionar el panel que publica producción y dejarían de guardarse las copias de recuperación. Mezclar en la misma máquina las pruebas con dos piezas tan importantes es lo que hay que resolver antes de usarla como paso obligatorio.
Recomendación: cuando llegue el momento, dedicar un servidor pequeño y nuevo solo a las pruebas de CreaRack, que se pueda borrar y volver a crear sin miedo, igual que el servidor de operaciones. El servidor de pruebas actual se quedaría con lo que ya hace bien: el panel de despliegues y las copias de recuperación. La alternativa, ampliar el servidor actual, es más sencilla, pero mantiene mezclados en una misma máquina las pruebas, el panel que publica producción y las copias. El precio exacto hay que consultarlo en Hetzner en el momento de decidir.
Mientras tanto, y sea cual sea la decisión, conviene liberar espacio en el servidor actual (registros antiguos, ficheros temporales y programas que ya no se usan). Con un 87 % ocupado, va justo aunque no se usara para pruebas.
5. Cuándo hacerlo
Antes del primer usuario externo, no ahora. Hoy el paso intermedio añadiría tiempo a cada cambio sin proteger a nadie, porque no hay clientes. El momento natural es la tarea de abrir el registro público de CreaRack: el paso intermedio de pruebas queda apuntado ahí como requisito, y cuando llegue el día el plan se revisará en frío antes de construirlo, porque es un cambio de infraestructura.
6. Glosario
- Producción
- El servidor donde funciona crearack.com, el que usan (y usarán) los clientes.
- Servidor de pruebas
- Una copia de CreaRack con sus propios datos, sin datos de clientes, para comprobar cambios antes de publicarlos. En el Dashboard aparece como «Staging».
- Servidor de operaciones
- La máquina del equipo que ejecuta las pruebas automáticas y las tareas programadas.
- Panel de despliegues
- El programa que publica cada versión de CreaRack en sus servidores.
- Fusionar
- Incorporar una propuesta de cambio a la versión principal del código. Hoy equivale a publicar.
- Agente simulado
- Un programa que se comporta como el Agente de un cliente y envía medidas inventadas; hoy alimenta la empresa de demostración.
¿Algo no cuadra?
Esta guía describe cómo trabajamos, y escribirla ya sirvió para descubrir cosas que no encajaban. Si al leerla algo no coincide con lo que ves en tu trabajo, se ha quedado anticuado, no se entiende o se podría hacer mejor, dilo: así es como mejoran las guías y, con ellas, la forma de trabajar.
- Pídeselo a Claude en cualquier sesión, diciendo qué guía, qué apartado y qué cambiarías. Por ejemplo: En la guía de bienvenida, el apartado 6 ya no es verdad porque…
- O escribe un comentario en la tarea «Mejoras de las guías» del tablero del Workspace, que está abierta siempre para esto.
Claude también propone mejoras cuando detecta algo que no encaja. Cada propuesta se revisa y, si se acepta, la guía se actualiza con su nueva fecha de revisión.