Nuestra infraestructura: Stack de desarrollo 100% Open Source

La infraestructura sobre la que realmente trabajamos, y por qué elegimos cada pieza

Esta es la infraestructura que construye, prueba y publica cada módulo de nuestro catálogo. La dejamos por escrito porque la pregunta que más nos hacen las agencias adopta, de una forma u otra, este tono: «¿Es usted un equipo de verdad que gestiona una infraestructura de verdad, o tres autónomos reunidos en un Discord?». Pregunta legítima. Esta es la respuesta a vista de pájaro.

Todo en nuestro flujo de trabajo es de código abierto o legalmente gratuito. No es un posicionamiento de marca, sino una decisión de compra que tomamos hace años y que no hemos tenido motivos para revisar. Ningún software pirateado, ninguna licencia crackeada, ningún proveedor propietario que no pudiéramos reemplazar en un fin de semana. La ventaja práctica es que nada en nuestro flujo depende de una licencia que pudiéramos perder ni de un SaaS que pudiera dejarnos fuera.

El servidor

Operamos sobre hardware ubicado en la UE y de nuestra propiedad. Utiliza almacenamiento con sumas de comprobación, memoria con corrección de errores y comprobaciones de integridad periódicas. El anfitrión es nuestro; todo lo demás es un contenedor que se ejecuta encima.

Elegimos ese enfoque de almacenamiento por un motivo muy concreto: cada bloque tiene su suma de comprobación y cada conjunto de datos puede congelarse en una instantánea en cuestión de milisegundos. Las instantáneas son lo bastante baratas como para que las tomemos antes de cada prueba de actualización de PrestaShop. Cuando una migración a la 9.0 destroza una base de datos (ha pasado), restauramos el conjunto de datos y el contenedor arranca en el estado previo a la avería en segundos. El hábito de las instantáneas hace que una migración fallida nos cueste minutos, no un día.

Por qué no una gran nube pública

Una configuración comparable en una gran nube pública, la RAM, el almacenamiento, el ancho de banda que consumen nuestros contenedores de desarrollo y de preproducción, el tráfico de salida para mover archivos ZIP y datos de demostración, costaría notablemente más cada mes en su funcionamiento. Ser dueños del hardware mantiene una infraestructura de coste fijo, con facturas predecibles, en lugar de una variable que nos sorprende cuando una demostración para un cliente arranca decenas de navegadores en paralelo.

El otro motivo es la jurisdicción de los datos. Nuestra infraestructura está físicamente en la UE y bajo nuestro control. Ninguna exposición a la Cloud Act estadounidense, ninguna configuración silenciosa de exportación de registros que olvidamos desactivar, ningún recargo por solicitud sobre los correos de soporte que enviamos. Para una pequeña tienda de la UE que trata con comerciantes europeos, ese es el modelo más sencillo, y significa que la conversación de soporte sobre su tienda, incluidos los registros que nos envíe, permanece en hardware de nuestra propiedad.

Contenedores dedicados, imágenes versionadas, cada versión que aún damos por soportada

En cualquier momento mantenemos en marcha un conjunto bien ocupado de entornos basados en contenedores. Cada uno es una instalación completa de PrestaShop con su propia base de datos, su propio usuario administrador y su propio directorio de módulos. Mantenemos entornos paralelos para:

• PrestaShop 1.6.x: antiguo, sí, pero todavía hay tiendas que lo usan y siguen comprando nuestros módulos.
• PrestaShop de la 1.7.6 a la 1.7.8: la larga cola del «ya actualizaremos el año que viene».
• PrestaShop 8.1 y 8.2: la producción actual para la mayoría de las tiendas nuevas.
• PrestaShop 9.0 y 9.1: el futuro cargado de Symfony, donde dedicamos la mayor parte de nuestro trabajo de migración este año.
• Las variantes multitienda de cada una de las anteriores. El multitienda rompe los módulos a su manera particular y no publicamos nada sin haberlo probado.

Cada instancia de PrestaShop recibe la versión de MySQL/MariaDB que espera esa entrega, en lugar de una única base de datos de talla única. Una capa de caché compartida gestiona el almacenamiento en caché de sesiones y objetos en todo el conjunto, reproduciendo la manera en que un alojamiento de producción configura realmente las cosas.

Esta es la configuración que atrapa los fallos que, de otro modo, descubriría en producción. Cuando un cliente informa de un error fatal en una combinación más antigua de PrestaShop y base de datos con el almacenamiento en caché de Smarty forzado, tenemos exactamente esa combinación funcionando antes del almuerzo, en lugar de una única instalación «más reciente» que oculta de forma silenciosa las roturas propias de una versión.

Autoalojado, no SaaS

Todo lo que razonablemente podemos alojar, lo alojamos nosotros. Sobre hardware ubicado en la UE y de nuestra propiedad, eso significa, entre otras cosas:

• Un servidor Git autoalojado: cada repositorio de módulo reside en hardware de nuestra propiedad, de modo que la fuente canónica de cada entrega que usted recibe queda en manos de quienes la escriben.
• Una pila de correo autoalojada con DKIM, SPF y DMARC. Sus respuestas de soporte no pasan por un relé SMTP de terceros que las escanea.
• Un sistema de documentación interno para nuestra base de conocimiento y nuestros manuales de procedimiento, donde una solución puntual se convierte en un procedimiento repetible, de modo que la siguiente persona dé con la misma respuesta en lugar de redescubrirla.
• Una bóveda cifrada de secretos para las credenciales que necesita nuestro instrumental interno.
• Supervisión del estado de los servicios, para enterarnos de que un contenedor está caído antes de que lo haga el cliente.
• Un proxy inverso con SSL automático en cada nombre de host interno.
• Un DNS interno, de modo que los nuevos entornos de desarrollo aparezcan en nuestra red privada con una sola entrada.

El autoalojamiento da más trabajo que pasar una tarjeta de crédito en un SaaS, y somos conscientes de esa contrapartida. Lo hacemos porque la alternativa es sufrir media docena de caídas de proveedores que no podemos arreglar, repartidas por una pila que no controlamos. Cuando algo se tuerce a las 23:00, lo reiniciamos nosotros mismos; no abrimos un tique de soporte y esperamos.

Cómo se construyen y revisan las entregas

La vida de un módulo no termina con la compra, así que tampoco lo hace la infraestructura que lo respalda. La entrega que llega a su back office se construye a partir de la misma fuente Git autoalojada contra la que desarrollamos. El despliegue es deliberadamente una acción revisada por una persona: nuestros trabajos automatizados y nuestros asistentes de programación con IA no publican entregas por su cuenta. Una persona revisa el cambio antes de que se convierta en una entrega. Ese paso de revisión es la barrera que mantiene un cambio experimental o una llamada a un método alucinada fuera de la versión que usted instala. El acceso a nuestros sistemas internos se encuentra tras un acceso de red privado y autenticado en lugar de un puerto abierto.

La estación de trabajo de desarrollo

Nuestra máquina de desarrollo principal funciona sobre un entorno Linux moderno y actualizado con regularidad, disponemos del último PHP, del último Node, de lo último de todo, sin esperar a que una distribución lo bendiga. Eso importa cuando PrestaShop 9 aparece sobre PHP 8.2+ y necesitamos estar probándolo la misma semana en que salen las notas de la versión.

Por qué Linux en el lado del desarrollo

Porque la producción es Linux. Sistemas de archivos sensibles a mayúsculas y minúsculas, permisos POSIX, enlaces simbólicos de verdad, todo el conjunto. Hemos heredado demasiados módulos de desarrolladores de Windows o macOS que funcionaban a la perfección en la máquina del autor y se rompían al instante en un servidor Linux de alojamiento compartido real, porque Module.php y module.php son dos archivos distintos en uno y un solo y mismo archivo en el otro. Desarrollar sobre la misma familia de sistema operativo que el despliegue elimina toda una categoría de fallos del flujo de trabajo antes de que puedan publicarse.

Trabajamos en un editor de código abierto sin telemetría del proveedor. El tiempo de ejecución del día a día son entornos basados en contenedores en el servidor, contenedores sin privilegios de root en local y máquinas virtuales locales completas cuando las necesitamos, por lo general, para replicar el entorno cPanel o Plesk de un cliente con la fidelidad suficiente para reproducir un fallo propio del alojamiento.

Los asistentes de programación con IA

La incorporación más reciente: asistentes de programación con IA como parte del flujo de trabajo diario, útiles allí donde una segunda perspectiva agiliza el trabajo. Se ejecutan contra los mismos repositorios y los mismos entornos basados en contenedores que las personas. Ninguno de ellos tiene credenciales para desplegar en producción, eso sigue siendo una acción humana. Se encargan de la larga cola de «migra este controlador a PS 9», «audita los tokens CSRF que falten», «traduce el texto del módulo al neerlandés». Usados con cuidado, son un multiplicador de fuerza. Usados sin cuidado, introducen llamadas a métodos alucinadas en una base de código, razón por la cual mantenemos un paso de revisión humana antes de que nada llegue a un ZIP de entrega.

Diseño y creatividad

El trabajo de módulos no es solo PHP. Cada entrega se publica con iconos, banners, capturas de pantalla de la tienda y, en ocasiones, una fuente de iconos personalizada. Todo producido con herramientas de código abierto, con cero gasto en Adobe al año.

Por qué esto importa si nos compra un módulo

Probamos sobre lo que usted utiliza

Su tienda funciona sobre Linux, un servidor web, una base de datos MySQL/MariaDB, PHP y una capa de caché. Nuestro entorno de desarrollo funciona sobre la misma pila, no sobre una aproximación de Windows-con-WAMP que se comporta de forma distinta de maneras sutiles y dolorosas. Cuando marcamos un módulo como «probado en una versión determinada de PrestaShop y de base de datos con la caché activada», es porque tenemos literalmente ese contenedor en marcha, no porque hayamos leído la página de requisitos de PrestaShop.

Podemos reproducir los problemas en la versión que usted utiliza

Como cada versión soportada de PrestaShop sigue en marcha aquí, no estamos depurando contra una única instalación «más reciente» que oculta de forma silenciosa las roturas propias de una versión. El hábito de las instantáneas hace que podamos reproducir una regresión en la versión exacta que la provocó, en lugar de adivinar.

Menos gastos generales, sin recargo de licencias

Cero gasto en las facturas recurrentes de software propietario que arrastra un taller de desarrollo típico. Es un coste recurrente que no necesitamos recuperar en los precios de los módulos.

El mismo modelo que el propio PrestaShop

PrestaShop es de código abierto. Usted lo eligió por ese motivo. Nosotros elegimos nuestra infraestructura por el mismo motivo. Cuando nos compra un módulo, lo compra a un equipo que vive dentro del modelo de código abierto de principio a fin, no a uno que vende módulos para una plataforma abierta mientras dirige su propio negocio sobre herramientas propietarias sin las que no podría sobrevivir.

Cómo llegamos hasta aquí

Esta configuración no surgió en una pizarra. Cada una de sus piezas reemplazó a una pieza anterior que falló de una forma memorable.

Los contenedores separados existen porque nos cansamos de los informes de «funciona en mi máquina» que no podíamos reproducir. Las instantáneas de almacenamiento existen porque una vez perdimos casi un día entero con una migración chapucera de la 1.7 a la 8 y decidimos que una vez era suficiente. La pila de correo autoalojada existe porque un gran proveedor de correo web empezó a marcar nuestras respuestas de soporte como spam con la frecuencia suficiente para que los clientes creyeran que los estábamos ignorando. El resolutor de DNS interno reemplazó a un archivo /etc/hosts editado a mano que se rompía cada vez que alguien añadía un nuevo subdominio de desarrollo. La wiki interna reemplazó a un montón de archivos Markdown en un repositorio que nadie leía.

Nada de esto es teórico. Cada cambio resolvió un problema que nos había costado tiempo real. Es el único motivo por el que cuajó, y es el mismo motivo por el que aguanta bajo los módulos que usted está utilizando.

Lecturas relacionadas

• Nuestra tecnología: la visión más amplia a nivel de empresa
• Performance Revolution: el módulo en el que la experiencia de caché volvió en forma de producto
• Refuerzo de la seguridad de PrestaShop: la misma higiene de autoalojamiento aplicada a su tienda
• Índice de la base de conocimiento: rendimiento, multitienda, seguridad y más