desplegar sobre un sistema financiero heredado, sin romper nada

el encargo

Agregar siete funcionalidades a un sistema de billeteras digitales en operación: perfiles con permisos diferenciados, panel de control, búsqueda sobre el padrón de cuentas, edición auditada de titulares, reportes ampliados, comprobantes con datos del titular y devolución total de fondos. El sistema estaba en producción, movía dinero real y estaba sujeto a auditoría de un organismo público.

lo que lo hacía difícil

El sistema venía de otro proveedor.

• No existía ambiente de pruebas: lo que todos llamaban "staging" era producción.
• El código llegó sin historial: siete componentes entregados como carpetas de archivos.
• La aplicación web se construía desde un repositorio al que el cliente no tenía acceso.
• La documentación no coincidía con la realidad: el manual declaraba una versión del framework y en producción corría otra, dos versiones mayores más nueva, porque las dependencias no estaban fijadas.
• La plataforma de contenedores está discontinuada: un servicio borrado no se puede recrear.

Cero margen para el error.

cómo lo resolví

Reconstruí el sistema completo en mi máquina con el volumen real: las imágenes exactas de producción contra una base con 1.500 cuentas, el mismo monto total y 131.000 transacciones. No una maqueta: una réplica.

Ensayé el despliegue entero cuatro veces, verificando en cada ensayo tres cosas: que la versión anterior funcionara igual que en producción, que las actualizaciones de base de datos se aplicaran sin mover dinero, y que la versión anterior siguiera funcionando contra la base ya actualizada. Ese tercer punto vuelve segura toda la operación: si algo falla, se vuelve atrás en segundos sin tocar la base.

El ensayo encontró un problema real antes de producción: la versión anterior no habría podido crear usuarios contra la base ya migrada. Escribí una migración específica y volví a ensayar hasta cerrarlo.

Definí una medida de verdad antes de empezar: el total de dinero en las cuentas, la cantidad de cuentas, el saldo retenido, el número de transacciones y la marca de tiempo de la última. Cinco medidas, tomadas minutos antes y repetidas al terminar.

Dejé tres caminos de vuelta atrás verificados antes de tocar nada: copias de las bases, las versiones anteriores de cada servicio marcadas del lado del servidor, y el artefacto web descargado. Ninguno dependía de que mi computadora siguiera encendida.

el resultado

Además verifiqué que lo publicado fuera exactamente lo probado: los archivos que sirve el sitio tienen la misma huella criptográfica que los que generé localmente. No una versión equivalente, el mismo artefacto.

lo que se llevó el cliente

• Sus repositorios de código, con historial y análisis automático de credenciales filtradas, y un camino claro para que queden bajo una cuenta propia.
• Un informe de 31 hallazgos ordenados por gravedad, con impacto y recomendación en cada uno.
• Un procedimiento de despliegue documentado y probado, para que la próxima vez no dependa de mí.
• Seis correcciones de seguridad que estaban en producción, entre ellas una página sin verificación de permisos y una exportación que permitía descargar los datos personales de todo el padrón en una sola operación.

cómo trabajo

Ensayo antes de tocar producción: reproduzco el sistema con datos del volumen real y ejecuto el procedimiento completo, incluida la vuelta atrás, hasta que sale igual varias veces seguidas.

Verifico el artefacto, no el proceso: que un comando haya salido bien no prueba que el resultado sea correcto; reviso lo que quedó adentro de la imagen, la base y el servidor.

Defino la medida de verdad antes de empezar: en un sistema con dinero, esa medida es el dinero. Si no puedo demostrar que no se movió, no puedo decir que el despliegue salió bien.