Mantenimiento y soporte Laravel

La mayoría de las aplicaciones Laravel las mantiene quien las construyó, hasta que esa persona se va. Lo que sigue es conocido: nadie actualiza nada porque nadie está seguro de qué se romperá, la lista de dependencias envejece en silencio, y el primer problema de verdad llega a la peor hora posible sin nadie que sepa dónde están enterrados los cadáveres.

Este es el acuerdo que lo evita, para empresas cuya aplicación es importante pero no justifica un equipo Laravel permanente.

Qué cubre

Parches de seguridad, aplicados con prontitud. Laravel, PHP y su árbol de dependencias publican avisos. La mayoría son irrelevantes para usted y unos pocos no lo son, y saber cuáles son cuáles es el trabajo. Los parches dentro del rango soportado salen según calendario; lo urgente sale cuando se publica y no en la siguiente entrega conveniente.

Dependencias que siguen siendo instalables. El fallo caro no es un paquete desactualizado, sino descubrir, el día en que necesita añadir algo, que no se instala nada nuevo porque las restricciones ya no se resuelven. Mantener sano ese grafo es una tarea mensual pequeña y un proyecto puntual enorme.

El framework dentro de soporte. Una actualización menor cada vez que aparece, y una mayor planificada en lugar de aplazada. La diferencia entre una aplicación que va una versión por detrás y otra que va tres no es tres veces el trabajo: es la razón por la que actualizaciones y rescate existe como encargo aparte.

Alguien al otro lado. Una vía hacia un ingeniero que ya conoce su esquema, sus colas y su despliegue, para que un incidente empiece con un diagnóstico y no con una orientación.

Monitorización que significa algo. Trabajos fallidos, profundidad de cola, tasas de error y los endpoints que mueven dinero, vigilados, con umbrales acordados con usted, para que el primer aviso de un problema no sea un cliente.

Qué no cubre

Funcionalidades nuevas. Es deliberado y no tacañería: un contrato de soporte que absorbe trabajo de producto se convierte en un presupuesto de desarrollo lento y no planificado, y el mantenimiento deja de ocurrir porque las funcionalidades siempre son más urgentes. El trabajo de producto se presupuesta como trabajo de producto, y los dos no compiten por las mismas horas.

Cómo funciona

Empezamos leyendo la aplicación, la hayamos escrito nosotros o no: el grafo de dependencias, la ruta de despliegue, los trabajos, las integraciones y lo que sea que tenga a alguien sin dormir. De ahí sale un documento corto: qué es frágil, qué está fuera de soporte, y qué pasaría a las tres de la madrugada.

Después es un ritmo mensual. Los parches y las actualizaciones salen según un calendario que usted conoce de antemano. Lo urgente lo interrumpe. Cada mes cierra con una nota de qué ha cambiado y qué viene, que es el documento que le pedirá su auditor y el que agradecerá su próximo desarrollador.

Todo ocurre en su repositorio, como pull requests revisables. No se hace nada a su sistema que usted no pueda leer después.

Cuándo esto es lo incorrecto

Si la aplicación ya va varias versiones por detrás y cuesta cambiarla, el mantenimiento no es el punto de partida: lo es la actualización, y fingir lo contrario significa pagar cada mes por sostener una posición que empeora.

Si nadie puede decir si la aplicación está sana, la auditoría responde eso en dos semanas a precio cerrado, y la respuesta decide cuál de estos encargos necesita de verdad.

Qué recibe

Una nota escrita cada mes: qué se parcheó, qué se actualizó, qué decidimos no tocar y por qué, y las horas usadas frente a las contratadas. El trabajo llega como pull requests, y lo que sale mal recibe un informe más largo que una línea en un chat.

El primer mes produce además un inventario corto de la aplicación. Versiones, dependencias con problemas conocidos y las tres cosas con más probabilidad de despertar a alguien. Ese documento le sirve continúe o no el acuerdo.