Encargo de ejemplo, Magento 2: Un parche de seguridad y un campo obligatorio en el checkout para una tienda B2B

Este artículo describe un encargo ficticio pero típico. La empresa no existe; el proceso corresponde al modo de trabajo de la Eywora AI Crew.

La situación de partida

Un mayorista de material de instalaciones eléctricas vende a través de una tienda en Magento Open Source 2.4 exclusivamente a clientes profesionales. Dos cosas molestan desde hace tiempo: los clientes piden una y otra vez sin indicar la empresa, lo que contabilidad tiene que arreglar al facturar, y el NIF-IVA no se valida en ningún sitio. A eso se suma un parche de seguridad que Adobe publicó hace dos semanas y que aún no se ha aplicado. El propietario describe los tres puntos en un solo encargo.

Paso 1: Prioridad y orden

El jefe de equipo de IA pone el parche de seguridad en primer lugar. Afecta al sistema en producción con independencia de los demás deseos y por eso no debe esperar a los cambios del checkout. Propuesta: el parche como primer cambio independiente con su propia aprobación, los ajustes del checkout como segundo. Así el parche puede publicarse el siguiente día de lanzamiento aunque el checkout siga en la ronda de comentarios. El agente de estimación de costes indica un rango aproximado para ambas partes.

Paso 2: El parche en la copia

La tienda se gestiona con Composer. En la copia, el agente de integraciones y sistemas aplica el parche, ejecuta las actualizaciones de setup, recompila las dependencias y genera los archivos estáticos. Después comprueba lo que en Magento suele fallar tras cada actualización: si todos los indexadores se ejecutan, si el cron funciona, si las cachés están limpias. Las pruebas automáticas abren páginas de categoría, producto y carrito y completan un pedido con cada método de pago activo. El agente de seguridad y protección de datos confirma, a partir de la versión y el changelog, que el parche está en vigor.

Paso 3: Checkout con funciones propias y un módulo pequeño

Para el NIF-IVA no hace falta código propio: Magento incluye la validación a través del servicio europeo de verificación y puede asignar automáticamente a los clientes a un grupo según el resultado. Los agentes lo configuran y crean los grupos «profesional verificado» y «profesional sin verificar», que el propietario podrá usar después para precios y métodos de pago. El campo obligatorio Empresa, en cambio, no se puede activar sin más. Para ello se crea un pequeño módulo propio que añade la regla de obligatoriedad a los campos de dirección del checkout y ofrece un mensaje de error comprensible. No modifica archivos del núcleo ni de otros módulos, para que las futuras actualizaciones de Magento no lo sobrescriban. Un segundo agente revisa el código; la diseñadora, la presentación del checkout en el móvil.

Paso 4: Vista previa, aprobación, publicación

El propietario aprueba el parche tras una breve revisión de la vista previa; se publica el martes con copia de seguridad. Para el checkout pide un cambio: el mensaje de error debe remitir a la facturación y no decir solo «campo obligatorio». Tras la segunda vista previa aprueba, y el checkout se publica el jueves, de nuevo con copia de seguridad previa. Ambos cambios quedan documentados por separado en el sistema de versiones y pueden revertirse con independencia uno del otro. Dos reversiones al mes están incluidas.

Qué muestra este ejemplo

En muchas tiendas los parches de seguridad esperan porque van ligados a otras tareas o simplemente se olvidan. Un equipo de desarrollo que los desacopla y los aplica con su propia copia de seguridad y su propia aprobación quita al propietario justo esa preocupación. Y también en Magento rige: primero las funciones propias, luego el mínimo código propio posible. Las versiones de Magento admitidas las indica la lista de sistemas; qué distingue a una agencia de un equipo de desarrollo de IA en estas tareas, el artículo ¿Equipo de desarrollo de IA o agencia?.

← Al blog