Hay una señal que se repite en muchas plataformas con algunos años en producción: nadie quiere tocar ciertas partes del sistema. Las nuevas funcionalidades se acumulan para lanzarse todas juntas, los despliegues se hacen de noche o los fines de semana, y después de cada lanzamiento aparecen errores en lugares que no se habían modificado.
Cuando publicar depende de recordar una lista de pasos manuales y de que una persona esté disponible para resolver cualquier falla, postergar el cambio parece razonable. El primer objetivo es que el equipo sepa qué se probó, qué se publicó y cómo actuar si algo sale mal.
Ambientes separados y parecidos a producción
La base de cualquier proceso de calidad es tener dónde probar antes de publicar. Un esquema habitual incluye:
- Desarrollo: donde el equipo construye y prueba sus cambios de forma individual.
- Pruebas o staging: un ambiente lo más parecido posible a producción, donde se valida el conjunto de cambios antes de publicarlos.
- Producción: donde operan los usuarios reales.
Lo importante no es la cantidad de ambientes, sino que el de pruebas se parezca realmente a producción: misma configuración, mismas versiones, datos representativos y conexión con los ambientes de prueba de los sistemas externos. Un ambiente de pruebas muy distinto de producción da una falsa sensación de seguridad.
Pruebas automatizadas donde más importan
Probar todo manualmente antes de cada publicación no escala. Las pruebas automatizadas permiten verificar en minutos que lo que funcionaba sigue funcionando. No hace falta cubrir el 100% del código; conviene empezar por:
- Flujos críticos del negocio: registro, compra, pago o reserva; si alguno falla, afecta de inmediato a los usuarios.
- Reglas de negocio complejas: cálculos de precios, impuestos, permisos o estados.
- Integraciones: que los contratos con sistemas externos se sigan respetando.
- Errores que ya ocurrieron: cada error corregido debería tener una prueba que evite que vuelva a aparecer.
QA como parte del proceso, no como etapa final
El control de calidad es más efectivo cuando acompaña todo el ciclo y no solo el final:
- Criterios de aceptación claros antes de empezar a desarrollar, para que todos sepan cuándo una funcionalidad está terminada.
- Revisión de código por otra persona del equipo antes de incorporar cada cambio.
- Pruebas funcionales y exploratorias en el ambiente de pruebas, incluyendo escenarios alternativos y casos límite.
- Pruebas de regresión sobre los flujos principales antes de cada publicación.
Integración y despliegue continuo
Un pipeline de integración y despliegue continuo (CI/CD) automatiza el recorrido de un cambio desde el código hasta producción: compila, ejecuta las pruebas, publica en el ambiente de pruebas y, una vez aprobado, despliega en producción siempre de la misma manera.
Para un equipo que hoy despliega a mano, el primer avance puede ser automatizar la misma secuencia de publicación y registrar cada ejecución. Luego se incorporan pruebas que frenen cambios problemáticos. Ese recorrido permite detectar en qué paso falló un despliegue y repetirlo sin depender de la memoria de una sola persona.
Cambios chicos y frecuentes
Publicar con más frecuencia suena más arriesgado, pero en la práctica pasa lo contrario. Si un despliegue trae un solo cambio, probarlo lleva poco tiempo, cualquier falla apunta a un lugar concreto y volver atrás es sencillo. Cuando se juntan semanas de trabajo en un único lanzamiento, un error puede venir de cualquiera de las decenas de cambios incluidos, y encontrar el origen lleva tiempo.
Desplegar de forma progresiva
Para cambios de mayor impacto, existen estrategias que limitan el alcance de un posible problema:
- Feature flags: la nueva funcionalidad llega a producción apagada y se enciende más tarde, primero para un grupo acotado de usuarios y después para el resto. Así, subir el código y ponerlo a disposición de los usuarios ya no tienen que ocurrir en el mismo momento.
- Despliegues canary: la versión nueva empieza atendiendo a una fracción menor de los usuarios; si los indicadores se mantienen estables, se le deriva cada vez más tráfico hasta reemplazar a la anterior.
- Blue-green: la nueva versión se levanta en paralelo a la actual y el tráfico se cambia de una a otra, lo que permite volver atrás de forma inmediata.
Poder volver atrás
Todo proceso de despliegue debería responder una pregunta antes de empezar: si algo sale mal, ¿cómo se vuelve a la versión anterior y cuánto tarda? El rollback tiene que estar probado, no solo planificado, y los cambios en la base de datos deben diseñarse para ser compatibles con la versión anterior durante la transición.
Después del despliegue
El despliegue no termina cuando el código llega a producción. Conviene verificar los indicadores clave en los minutos siguientes (errores, tiempos de respuesta, operaciones completadas) con monitoreo y alertas que permitan detectar un problema antes de que lo reporte un usuario.
Si hoy publicás de forma manual
Empezá por escribir cómo se publica hoy, qué pasos dependen de una persona y cómo se vuelve atrás. Con ese mapa, automatizá la publicación y elegí uno o dos flujos críticos para probar en cada cambio. Después sumá prácticas más avanzadas, como despliegues progresivos, donde el riesgo del producto lo justifique.
Un proceso sólido de despliegue también es lo que permite preparar una plataforma para picos de demanda: los ajustes de rendimiento se pueden probar y publicar con seguridad antes del evento.
La medida de avance no es cuántas herramientas se incorporaron: es si el equipo puede publicar un cambio pequeño, ver su efecto y recuperarse sin improvisar.