Cómo probamos el software antes de entregarlo

El servidor de staging corre exactamente las mismas condiciones que producción: misma versión de Node, misma configuración de MySQL, mismo sistema de PM2 para gestión de procesos. La diferencia es que los datos son de prueba y los puertos son distintos (4001 en lugar de 3001).

Esto importa más de lo que parece. Muchos equipos tienen staging en sus laptops, o en un Docker container con SQLite, o en un ambiente que "es parecido" a producción. Lo que esos ambientes no capturan son los problemas específicos del servidor real: permisos de sistema de archivos, configuración de MySQL, tamaños de packet, zona horaria del sistema.

Cuando algo funciona en local pero no en staging, el problema siempre está en la diferencia entre ambientes. Y si no tenés staging real, no sabés que el problema existe hasta que lo encontrás en producción.

Antes de cada deploy corremos un conjunto de smoke tests: scripts que verifican que los endpoints críticos respondan correctamente.

No son tests exhaustivos de cada caso de uso. Son la verificación mínima de que el sistema arranca y funciona en lo fundamental: el endpoint de health responde 200, el login con credenciales válidas devuelve un token, las queries básicas de contenido retornan datos con la shape esperada, el sistema de uploads acepta una imagen y la guarda.

Si algún smoke test falla, el deploy no continúa. La regla es simple: si no pasa la verificación mínima, algo está roto.

La metodología que seguimos es leer el diff antes de mergear. No el código completo — el diff. Cada cambio tiene que tener una razón clara, y esa razón tiene que ser visible en los cambios.

Cuando el diff incluye una nueva query a la base de datos, verificamos que tenga el filtro correcto. Cuando incluye un nuevo endpoint, verificamos que tenga los guards de autenticación y autorización. Cuando modifica una migración, la corremos en staging primero.

Esto no es código review formal con checklist. Es la práctica de mirar lo que cambiaste con ojos frescos antes de mandarlo. En la mayoría de los casos, el bug que hubieras encontrado en producción se hace evidente cuando lo mirás con la pregunta "¿qué puede salir mal aquí?"

Las migraciones de base de datos son el cambio más peligroso que existe en un sistema en producción. Un error en una migración puede corromper datos que no tienen recuperación directa.

Nuestro proceso: cada migración se escribe como SQL puro, se revisa manualmente, se aplica primero en staging, se verifica que el sistema funcione después de aplicarla, y solo entonces se aplica en producción.

Las migraciones son always-forward: no hay rollback de schema en producción. Si una migración produce un problema, el fix es una nueva migración. La razón es que en un sistema multi-tenant, hacer rollback de una migración que ya corrió en diez bases de datos es exponencialmente más complejo que corregir hacia adelante.

No tenemos tests unitarios para la mayoría del código de negocio. Esto puede sonar irresponsable, pero tiene una razón: la mayoría de los bugs que encontramos en el pasado no eran de lógica de negocio — eran de integración. Un campo que llegaba con el nombre equivocado, una query que no filtraba por tenant, un guard de autorización que no se ejecutaba.

Los smoke tests y la revisión de staging capturan esa categoría de bugs mejor que los tests unitarios, porque testean el sistema integrado. Los tests unitarios tienen más valor para lógica de negocio compleja y aislada — y cuando la tenemos, la testeamos.

La distribución del esfuerzo de testing tiene que estar donde están los bugs reales.