E-commerce · Marketplace mayorista B2B
Un pipeline de entrega seguro para un marketplace de 9 años, listo en un día
Un marketplace en Laravel con unos 3.900 commits desde 2017, un único servidor dedicado sin memoria libre y cambios que iban directos a producción. El pipeline con controles quedó funcionando en un solo día.
La situación
Un marketplace B2B de venta mayorista de calzado y ropa funciona sobre el mismo código Laravel desde 2017. Tiene unos 3.900 commits, colas en Redis y un único servidor dedicado.
El sistema había crecido como suele pasar:
- El código estaba en el GitLab de una agencia externa.
- Los cambios iban directos a producción. No había copia de staging ni ningún control entre un commit y los clientes reales.
- El servidor iba justo de memoria. Los procesos en segundo plano se habían multiplicado con los años; algunos estaban duplicados y otros corrían como root.
Una migración de base de datos que fallara a medias, o un proceso que se comiera la poca memoria que quedaba, dejaría el marketplace caído para compradores y proveedores.
Qué hicimos
Primero, ajustar el servidor. Antes de añadir nada nuevo, hicimos sitio en la máquina que ya había.
- Los procesos en segundo plano pasaron de 49 a 9. Quitamos los duplicados y ya ninguno corre como root.
- La RAM libre pasó de 2,5 GB a 10,3 GB.
- Con ese margen, los workers de PHP-FPM pasaron de 10 a 50, así que la web atiende más peticiones a la vez.
- El uso del disco raíz bajó del 80% al 48%.
Copias que permiten volver atrás.
- La base de datos se copia fuera del servidor 4 veces al día.
- El binlog da 7 días de recuperación a un punto en el tiempo: podemos restaurar al minuto anterior a un cambio malo, no solo al último volcado.
- Los archivos se copian a diario y se guardan 6 meses.
- Un espejo de Git cada hora conserva el historial del código aunque alguien haga un force-push encima.
El pipeline.
- La CI corre en runners propios del cliente.
- Cada migración nueva de base de datos se prueba sobre una copia del esquema de producción: aplicar, deshacer y volver a aplicar. Una migración que no se puede deshacer se detecta antes de llegar a producción.
- Staging funciona sobre una copia de la base de datos. Las fotos de producción se montan en solo lectura, y el correo y las notificaciones están desactivados, para que nadie reciba un mensaje de prueba.
- Los despliegues a producción se lanzan con un botón y pasan por un control en el propio servidor que ningún pull request puede debilitar.
- Antes de cualquier migración se vuelca la base de datos y se anota la posición del binlog.
Resultado
El pipeline quedó en marcha en un solo día, con 39 pull requests. Algunos eran arreglos reales, no solo la puesta a punto del pipeline.
Ahora el marketplace tiene una copia de staging donde revisar los cambios, migraciones que se prueban antes de ejecutarse y un punto de recuperación para cada minuto de la última semana. El servidor va holgado, y el equipo puede tocar un código de 9 años sin contener la respiración.