DevOps sin equipo de DevOps: empezar por lo que duele
Un pipeline simple hace mucho bien en sistemas PHP modestos: build, respaldos probados y avisos de error.
«DevOps» suena a equipo grande, Docker y Kubernetes. La parte que le importa a una PyME con un sistema web y dos o tres personas cuidándolo es más pequeña y más valiosa: poder liberar sin miedo, responder cuando algo falla y recuperar cuando algo se rompe. Eso se consigue con un pipeline aburrido, no con una arquitectura de revista.
El primer pipeline: cuatro pasos
Para un sistema PHP modesto (o cualquier app pequeña con un repositorio), el pipeline mínimo rinde como uno complejo:
- Build reproducible: las dependencias se instalan igual en cualquier máquina (lock de versiones). Si «funciona en mi computadora», el build no lockea dependencias. Así empieza casi toda calabada.
- Pruebas que corren solas: no hace falta cobertura del 90%: unas pruebas del flujo crítico (una venta se registra, un correo sale, un reporte se calcula) atrapan el 80% del daño de una liberación.
- Entorno separado: staging con los mismos ajustes que producción. La prueba que se hace sobre producción no es prueba: es una rueda afortunada.
- Regla del viernes: nada sale a producción después del jueves por la tarde, salvo emergencia con reversión planificada.
Respaldos: el que no se prueba, no existe
La copia que vive en el disco del mismo servidor no es un respaldo, es una promesa. Un respaldo serio se restaura de vez en cuando en un entorno aislado y se registra cuánto tomó. En una PyME el costo de olvidar esto es el negocio entero: datos de clientes, facturas, contratos. Este es el punto de DevOps donde no negociamos.
Error avisado vs. error llamado
La falla va a ocurrir: la pregunta es quién la descubre primero. El monitoreo mínimo (registro de errores con aviso al responsable, chequeo de disponibilidad, tiempo de respuesta) convierte el llamado del cliente enojo en un aviso del sistema. En muchos proyectos es la primera mejora que piden es porque ya la sintieron de otra manera.
La reversión: tu seguro del pánico
El plan de reversión es increíblemente frugal: versionar los despliegues con código y tener el paso escrito de «volver atrás» (deploy el paquete anterior, restaurar el last backup si tocó base de datos). Si liberar X versión no incluye plan de reversión, es un riesgo que no está viniendo del código: viene del proceso.
Nada de esto requiere un equipo dedicado. Requiere alguien con criterio al comienzo y la disciplina de no liberar a mano. En DevOps & CI/CD lo armamos, pero empiece por el diagnóstico y los cuellos que ya da el escaneo de un día.