De editar por FTP a un pipeline gestionado con IA en una semana

La situación

Una cadena regional de electrónica y portátiles tiene dos tiendas online en OpenCart y ocStore, con unos 42.000 productos. Los productos, precios y existencias llegan desde 1C, el sistema contable de la empresa.

Con los años, las tiendas se habían ido cambiando como se cambian muchas tiendas: directamente en el servidor.

• No había Git. Varios usuarios de FTP tenían acceso de escritura a producción.
• phpMyAdmin estaba abierto a internet.
• En el webroot había volcados de la base de datos, archivos comprimidos y scripts sueltos. Uno ejecutaba ALTER TABLE al abrirlo en el navegador y otro enviaba un correo.
• PHP podía ejecutarse en cualquier sitio y el endpoint de intercambio con 1C aceptaba peticiones de cualquiera.

Todavía no había pasado nada grave. Pero cualquier cambio era arriesgado y nadie sabía decir con exactitud qué había en el servidor.

Qué hicimos

Primero, la seguridad.

• Copias cifradas fuera del servidor: la base de datos cada 6 horas y los archivos cada noche, con una restauración verificada por checksum.
• Bastionamos el servidor:
  • los puertos 80/443 solo aceptan tráfico de la CDN;
  • PHP solo se ejecuta en los puntos de entrada propios de la tienda;
  • el endpoint de 1C solo acepta la IP del servidor de 1C;
  • SSH solo con clave, y eliminamos el FTP.
• Los archivos retirados fueron a cuarentena, no a la papelera.

El código, a Git.

• Tras buscar secretos filtrados, las dos tiendas pasaron a una organización privada de GitHub que es propiedad del cliente.
• Un servidor de staging separado recibió una copia saneada de la base de datos. En staging, los pagos, la analítica, los píxeles, los afiliados y el login social están desactivados, y los dominios se reescriben.

El pipeline.

• Cada pull request se revisa automáticamente: sintaxis PHP (para la versión del servidor), secretos filtrados y archivos prohibidos.
• Los cambios de riesgo se marcan para que los revise un ingeniero: configuración, CI, dependencias, SQL, el intercambio con 1C, módulos OCMOD y código que borra datos.
• Cada despliegue a producción pasa por un control en el propio servidor. Hace una copia de la base de datos, despliega el código, reconstruye las modificaciones y comprueba que la web responde. Si no, vuelve atrás por sí solo.
• Una comprobación nocturna de desviaciones compara producción con Git y abre un ticket si algo ha cambiado fuera del pipeline. Los despliegues quedan bloqueados hasta que se resuelve.

Entrega al dueño. El dueño instaló las apps de Claude y GitHub, unos diez minutos. Ahora pide cambios en lenguaje normal, los revisa en staging y los aprueba. Los primeros arreglos visibles para los clientes, una redirección de idioma y el marcado de producto, salieron al día siguiente.

Extras

Con la tienda ya fácil de cambiar sin riesgo, añadir automatización fue sencillo:

• un artículo de blog redactado por IA cada mañana, que revisa el encargado;
• publicaciones automáticas en Telegram: precios diarios, avisos de “ha bajado de precio” y una selección semanal para el canal de la tienda.