Una estrategia de despliegue con rollback en PHP no consiste en conservar un botón para volver a la versión anterior. Es un diseño operativo que permite retirar código sin dejar datos incompatibles, trabajos asíncronos duplicados o procesos en curso ejecutando reglas ya descartadas. El rollback debe ser una opción preparada antes de publicar, no una reacción improvisada durante una incidencia.
Los despliegues pequeños reducen el radio de impacto: introducen menos variables, facilitan identificar el cambio causante y acortan la recuperación. Sin embargo, un cambio reducido puede afectar a pagos, autenticación, permisos, inventario o comunicaciones. Por eso el tamaño del cambio no sustituye a controles técnicos ni a criterios explícitos para detener una publicación.
El rollback se diseña antes de que exista una incidencia
Revertir código es sencillo sólo cuando el cambio no ha alterado el estado compartido. En producción, una versión puede haber escrito datos, enviado mensajes a una cola, activado una tarea programada o llamado a un servicio externo. Volver a un commit anterior sin revisar esos efectos puede ocultar el error inicial y crear uno más difícil de diagnosticar.
Antes de aprobar un despliegue, el equipo debe poder responder a cuatro preguntas:
- Qué artefacto se publicará: versión identificable, construida una vez y disponible para restauración.
- Qué estado cambia: esquema de base de datos, caché, archivos, índices de búsqueda, colas, proveedores externos y configuración.
- Qué versión puede leer y escribir ese estado: código nuevo, código anterior o ambos durante una ventana temporal.
- Qué señal obliga a actuar: umbral de errores, fallo de una ruta crítica, retraso en cola, degradación de latencia o impacto funcional confirmado.
La unidad de reversión debe estar definida. Puede ser toda la aplicación, un servicio, un consumidor de cola o una funcionalidad activada mediante configuración. No conviene confundir despliegue, que instala software, con release, que hace disponible un comportamiento. Separarlos permite desplegar código inactivo y exponerlo después de validar condiciones técnicas.
Clasificar los cambios según su capacidad de reversión
No todos los cambios admiten el mismo tratamiento. Un ajuste de presentación o una corrección interna sin cambios de estado suele ser reversible mediante la restauración del artefacto previo. En cambio, una migración destructiva, una modificación de contrato de API o una nueva regla de negocio que ya ha producido efectos externos exige una estrategia adicional.
Cambios normalmente reversibles
- Correcciones de lógica que conservan los contratos de entrada y salida.
- Cambios de plantillas, siempre que no dependan de campos eliminados.
- Nuevas rutas o endpoints que no modifican recursos existentes.
- Optimizaciones internas sin cambios de esquema ni de semántica.
Cambios que requieren compatibilidad temporal
- Renombrado o sustitución de columnas, campos JSON y eventos.
- Cambios de formato en mensajes de cola o webhooks.
- Nuevas restricciones de validación sobre datos ya existentes.
- Modificaciones de autenticación, permisos o reglas de cálculo.
- Integraciones que crean cargos, pedidos, notificaciones o modificaciones en sistemas externos.
Para datos compartidos, el patrón más seguro suele ser expandir, migrar, contraer. Primero se añade una estructura compatible, después el código soporta temporalmente el formato antiguo y el nuevo, se migran o rellenan los datos necesarios y, sólo tras retirar definitivamente la versión antigua, se elimina lo obsoleto. Por ejemplo, añadir una columna nullable y escribir ambos campos durante una transición es recuperable; renombrar o eliminar directamente una columna usada por la versión anterior no lo es.
Las migraciones deben tratarse como entregables independientes del código. Una migración sólo hacia delante puede ser correcta, pero entonces el plan debe declarar que el rollback de aplicación no implica revertir el esquema. Evite una migración de bajada automática si puede borrar datos generados tras el cambio o si su resultado depende del estado real de producción.
Preparar artefactos, configuración y condiciones previas
El mismo artefacto debe avanzar entre entornos. Compilar dependencias o modificar código directamente en cada servidor impide saber qué versión se está ejecutando y dificulta restaurar una conocida. En una aplicación PHP, el artefacto puede incluir el código versionado y las dependencias resueltas; la configuración sensible y específica del entorno debe inyectarse por mecanismos externos, no quedar embebida en el paquete.
Registre como mínimo el identificador de versión, la fecha de publicación, la configuración funcional relevante y el responsable de la decisión. Esto acelera tanto la investigación como la vuelta a una versión concreta.
Antes del despliegue, verifique de forma automatizada y visible:
- Pruebas unitarias, de integración y de contrato proporcionales al cambio.
- Resolución de dependencias y compatibilidad con la versión de PHP, extensiones y servicios requeridos.
- Estado de migraciones, plan de expansión de datos y tiempo estimado de ejecución.
- Salud de dependencias: base de datos, caché, almacenamiento, API internas y proveedores críticos.
- Capacidad y comportamiento de workers, colas y tareas programadas.
- Disponibilidad del artefacto anterior y procedimiento probado para restaurarlo.
Las comprobaciones no deben limitarse a que el proceso PHP responda. Una ruta de salud puede confirmar que PHP-FPM está activo y, aun así, no detectar un error de autorización, una consulta lenta o un consumidor bloqueado. Defina rutas sintéticas pequeñas que representen operaciones críticas sin ejecutar acciones irreversibles.
Publicar gradualmente con responsables y límites claros
La exposición gradual reduce el alcance de un fallo, pero sólo funciona si el tráfico o las instancias pueden separarse de forma real. Puede actualizarse una fracción de instancias, activar una capacidad para un segmento controlado o dirigir una parte de solicitudes a la nueva versión. La elección depende de la arquitectura y del tipo de estado compartido.
Asigne funciones explícitas durante la ventana de publicación:
- Una persona ejecuta y registra los pasos.
- Otra observa métricas, logs y trazas relevantes.
- Un responsable tiene autoridad para detener o revertir sin esperar aprobaciones ambiguas.
- El equipo de negocio o soporte conoce los efectos esperados si el cambio toca una operación sensible.
También establezca una ventana de observación. No basta con publicar, ver una respuesta HTTP correcta y pasar al siguiente cambio. Algunos defectos aparecen cuando se procesa una cola, expira una caché, se ejecuta una tarea programada o un usuario completa un flujo más largo.
Verificar después: servicio, datos y efectos de negocio
La verificación posterior debe combinar señales técnicas y funcionales. Las métricas generales son útiles, pero un promedio de latencia estable puede ocultar el fallo de una operación minoritaria y crítica.
- Rutas críticas: autenticación, lectura y escritura principal, pagos, creación de pedidos o acciones con permisos.
- Errores: excepciones PHP, respuestas 5xx, aumentos de 4xx inesperados, errores de validación y fallos de dependencias.
- Rendimiento: latencia por endpoint, saturación de workers, conexiones de base de datos y consumo de recursos.
- Procesamiento asíncrono: tamaño y antigüedad de cola, reintentos, mensajes fallidos e idempotencia.
- Efectos de negocio: transacciones incompletas, duplicados, cambios de estado inválidos o caídas en conversiones que el equipo pueda contrastar.
Los criterios de decisión deben ser verificables. Continúe si las rutas definidas funcionan, no hay incremento sostenido de errores y las colas permanecen dentro de su retraso aceptable. Detenga la expansión si aparece una anomalía que aún requiere diagnóstico. Revierta si el artefacto previo es compatible con el estado actual y la restauración reduce claramente el impacto. Corrija hacia delante si revertir rompería la compatibilidad, no desharía efectos externos o tardaría más que aplicar una corrección aislada y validada.
Gestionar colas y procesos iniciados por una versión retirada
Los workers son una fuente habitual de rollbacks incompletos. Puede retirarse el código web mientras quedan mensajes creados por la nueva versión o procesos de larga duración que siguen ejecutando lógica antigua. El plan debe indicar cómo drenar, pausar, reiniciar o aislar consumidores sin perder trazabilidad.
Considere un flujo hipotético: una aplicación PHP publica un mensaje para confirmar un pedido. La nueva versión añade un campo al mensaje y modifica el estado del pedido antes de enviarlo. Si hay que retirarla, el consumidor anterior debe ignorar de forma segura el campo adicional o el mensaje debe llevar una versión que permita enrutarlo a un consumidor compatible. Además, la confirmación debe usar una clave idempotente para que un reintento no produzca dos acciones externas.
{
"event": "order.confirmation_requested",
"schema_version": 2,
"idempotency_key": "operacion-unica",
"order_id": "identificador"
}Antes de revertir, pause la entrada de nuevos trabajos si es necesario, identifique los mensajes en tránsito y confirme qué consumidores pueden procesarlos. Después, revise fallidos y reintentos de forma controlada. No borre una cola para recuperar rapidez: puede eliminar evidencia necesaria o dejar operaciones de negocio a medio completar.
Convertir el plan en una práctica repetible
Una estrategia madura no depende de memoria individual. Mantenga un runbook breve por servicio con los comandos aprobados, ubicación de logs, paneles de observación, responsables, condiciones de parada y límites conocidos de reversión. Ensaye el procedimiento en un entorno representativo, especialmente tras cambios de infraestructura, colas, migraciones o integraciones.
Tras cada incidencia o rollback, revise si falló la detección, la compatibilidad, la automatización o la decisión. El objetivo no es evitar toda reversión; es poder elegir entre revertir y corregir hacia delante con información suficiente, sin transformar una incidencia localizada en una pérdida de datos o una interrupción mayor.
