Chi siamo, mypresta.rocks Informazioni

La nostra infrastruttura: Stack di sviluppo 100% Open Source

Come mypresta.rocks sviluppa e distribuisce moduli PrestaShop: infrastruttura UE, ambienti realistici e release riviste da persone.

Lo stack su cui lavoriamo davvero, e perché abbiamo scelto ogni componente

Questa è l'infrastruttura che costruisce, collauda e rilascia ogni modulo del nostro catalogo. La mettiamo per iscritto perché la domanda che ci pongono più spesso le agenzie assume, in una forma o nell'altra, questo tono: «È un vero team che gestisce una vera infrastruttura, oppure tre liberi professionisti riuniti su un Discord?». Domanda legittima. Ecco una panoramica.

Tutto nella nostra pipeline è open source oppure legalmente gratuito. Non è un posizionamento di marca, ma una decisione d'acquisto presa anni fa che non abbiamo avuto motivo di rivedere. Nessun software piratato, nessuna licenza craccata, nessun fornitore proprietario che non potremmo sostituire nell'arco di un fine settimana. Il vantaggio concreto è che nulla nella nostra pipeline dipende da una licenza che potremmo perdere o da un SaaS che potrebbe estrometterci.

Il server

Lavoriamo su hardware situato nell'UE e di nostra proprietà. Utilizza uno storage con somme di controllo, memoria a correzione d'errore e verifiche d'integrità regolari. L'host è nostro; tutto il resto è un container che vi gira sopra.

Abbiamo scelto questo approccio allo storage per un motivo ben preciso: ogni blocco ha la sua somma di controllo e ogni set di dati può essere congelato in uno snapshot nell'ordine dei millisecondi. Gli snapshot sono abbastanza economici da consentirci di crearli prima di ogni test di aggiornamento di PrestaShop. Quando una migrazione alla 9.0 manda in malora un database (è successo), ripristiniamo il set di dati e il container si avvia nello stato precedente al guasto in pochi secondi. L'abitudine agli snapshot fa sì che una migrazione andata male ci costi minuti, non una giornata.

Perché non un grande cloud pubblico

Una configurazione paragonabile su un grande cloud pubblico, la RAM, lo storage, la banda che consumano i nostri container di sviluppo e di staging, il traffico in uscita per spostare ZIP e dati dimostrativi, costerebbe sensibilmente di più da gestire ogni mese. Possedere l'hardware mantiene un'infrastruttura a costo fisso, con bollette prevedibili, anziché una variabile che ci sorprende quando una demo per un cliente avvia decine di browser in parallelo.

L'altro motivo è la giurisdizione dei dati. La nostra infrastruttura si trova fisicamente nell'UE e sotto il nostro controllo. Nessuna esposizione al Cloud Act statunitense, nessuna silenziosa configurazione di esportazione dei log che abbiamo dimenticato di disattivare, nessun sovrapprezzo per richiesta sulle e-mail di assistenza che inviamo. Per un piccolo negozio dell'UE che tratta con commercianti europei, è il modello più semplice, e significa che la conversazione di assistenza riguardante il tuo negozio, compresi i log che ci invii, resta su hardware di nostra proprietà.

Container dedicati, immagini versionate, ogni versione che supportiamo ancora

In qualsiasi momento teniamo in funzione un insieme ben affollato di ambienti basati su container. Ciascuno è un'installazione completa di PrestaShop con il proprio database, il proprio utente amministratore, la propria cartella dei moduli. Manteniamo ambienti paralleli per:

  • PrestaShop 1.6.x: vecchio, sì, ma ci sono ancora negozi che lo usano e continuano ad acquistare i nostri moduli.
  • PrestaShop dalla 1.7.6 alla 1.7.8: la lunga coda del «aggiorneremo l'anno prossimo».
  • PrestaShop 8.1 e 8.2: la produzione attuale per la maggior parte dei nuovi negozi.
  • PrestaShop 9.0 e 9.1: il futuro a forte componente Symfony, dove quest'anno dedichiamo gran parte del nostro lavoro di porting.
  • Le varianti multistore per ciascuna delle precedenti. Il multistore manda in tilt i moduli a modo suo, e non rilasciamo nulla senza averlo collaudato.

Ogni istanza di PrestaShop riceve la versione di MySQL/MariaDB che quella release si aspetta, anziché un unico database valido per tutti. Un livello di cache condiviso gestisce il caching delle sessioni e degli oggetti sull'intero parco, rispecchiando il modo in cui un hoster di produzione configura davvero le cose.

È questa la configurazione che intercetta i bug che altrimenti scopriresti in produzione. Quando un cliente segnala un errore fatale su una combinazione più datata di PrestaShop e database con il caching Smarty forzato, abbiamo esattamente quella combinazione in funzione prima di pranzo, anziché una sola installazione «più recente» che nasconde silenziosamente le rotture specifiche di una versione.

Self-hosted, non SaaS

Tutto ciò che possiamo ragionevolmente ospitare, lo ospitiamo da noi. Su hardware situato nell'UE e di nostra proprietà, ciò significa, tra le altre cose:

  • Un server Git self-hosted: ogni repository di modulo risiede su hardware di nostra proprietà, così che la sorgente canonica di ogni release che ricevi si trovi presso le persone che la scrivono.
  • Uno stack di posta self-hosted con DKIM, SPF e DMARC. Le tue risposte di assistenza non passano attraverso un relay SMTP di terze parti che le analizza.
  • Un sistema di documentazione interno per la nostra base di conoscenza e i runbook, dove una correzione una tantum diventa una procedura ripetibile, così che la persona successiva trovi la stessa risposta invece di riscoprirla.
  • Un archivio cifrato per le credenziali utilizzate dai nostri strumenti interni.
  • Il monitoraggio dello stato dei servizi, così da venire a sapere che un container è giù prima che lo scopra il cliente.
  • Un reverse proxy con SSL automatico su ogni nome host interno.
  • Un DNS interno, così che i nuovi ambienti di sviluppo compaiano sulla nostra rete privata con un'unica voce.

Il self-hosting comporta più lavoro che strisciare una carta di credito presso un SaaS, e siamo consapevoli di questo compromesso. Lo facciamo perché l'alternativa è subire una mezza dozzina di disservizi di fornitori che non possiamo correggere, sparpagliati su uno stack che non controlliamo. Quando qualcosa fa i capricci alle 23, lo riavviamo noi stessi; non apriamo un ticket di assistenza e aspettiamo.

Come vengono costruite e revisionate le release

La vita di un modulo non finisce con l'acquisto, e così neppure l'infrastruttura che vi sta dietro. La release che arriva nel tuo back office è costruita dalla stessa sorgente Git self-hosted su cui sviluppiamo. Il deployment è deliberatamente un'azione revisionata da una persona: i nostri processi automatizzati e gli assistenti di programmazione basati su IA non pubblicano release di propria iniziativa. Una persona esamina la modifica prima che diventi una release. Questo passaggio di revisione è la barriera che tiene una modifica sperimentale o una chiamata di metodo allucinata fuori dalla versione che installi. L'accesso ai nostri sistemi interni si trova dietro un accesso di rete privato e autenticato anziché dietro una porta aperta.

La workstation di sviluppo

La nostra macchina di sviluppo principale gira su un ambiente Linux moderno e aggiornato di frequente, disponiamo dell'ultimo PHP, dell'ultimo Node, dell'ultimo di tutto, senza aspettare che una distribuzione lo benedica. Conta quando PrestaShop 9 arriva su PHP 8.2+ e dobbiamo collaudarlo nella stessa settimana in cui escono le note di rilascio.

Perché Linux sul versante dello sviluppo

Perché la produzione è Linux. File system sensibili alle maiuscole, permessi POSIX, veri symlink, il tutto. Abbiamo ereditato troppi moduli da sviluppatori su Windows o macOS che funzionavano perfettamente sulla macchina dell'autore e si rompevano all'istante su un vero server Linux in hosting condiviso, perché Module.php e module.php sono due file diversi su uno e un solo e medesimo file sull'altro. Sviluppare sulla stessa famiglia di sistema operativo del deployment elimina un'intera categoria di bug dal flusso di lavoro prima che possano essere rilasciati.

Lavoriamo in un editor open source privo di telemetria del fornitore. Il runtime quotidiano è fatto di ambienti basati su container sul server, container rootless in locale e VM locali complete quando ci servono, di solito per replicare l'ambiente cPanel o Plesk di un cliente con sufficiente fedeltà da riprodurre un bug specifico dell'hosting.

Gli assistenti di programmazione basati su IA

L'aggiunta più recente: assistenti di programmazione basati su IA come parte del flusso di lavoro quotidiano, utili dove un secondo punto di vista velocizza il lavoro. Operano sugli stessi repository e sugli stessi ambienti basati su container delle persone. Nessuno di essi possiede le credenziali per il deployment in produzione. Quello resta un'azione umana. Si occupano della lunga coda di «porta questo controller a PS 9», «verifica l'assenza di token CSRF», «traduci i testi del modulo in olandese». Usati con attenzione, aumentano la produttività del team. Usati con leggerezza, immettono chiamate di metodo allucinate in una base di codice, ed è per questo che manteniamo un passaggio di revisione umana prima che qualcosa raggiunga uno ZIP di release.

Design e creatività

Il lavoro sui moduli non è solo PHP. Ogni release viene fornita con icone, banner, screenshot del negozio e occasionalmente un font di icone personalizzato. Tutto prodotto con strumenti open source, con zero spesa Adobe all'anno.

Perché conta se acquista un modulo da noi

Collaudiamo su ciò che usa Lei

Il tuo negozio gira su Linux, un server web, un database MySQL/MariaDB, PHP e un livello di cache. Il nostro ambiente di sviluppo gira sullo stesso stack, non su un'approssimazione Windows-con-WAMP che si comporta diversamente in modi sottili e dolorosi. Quando contrassegniamo un modulo come «collaudato su una determinata versione di PrestaShop e di database con la cache attiva», è perché abbiamo letteralmente quel container in funzione, non perché abbiamo letto la pagina dei requisiti di PrestaShop.

Possiamo riprodurre i problemi sulla versione che usa Lei

Poiché ogni versione supportata di PrestaShop resta in funzione qui, non stiamo facendo debug su una sola installazione «più recente» che nasconde silenziosamente le rotture specifiche di una versione. L'abitudine agli snapshot fa sì che possiamo riprodurre una regressione esattamente sulla versione che l'ha provocata, invece di tirare a indovinare.

Meno costi generali, nessun sovrapprezzo di licenza

Zero spesa per le ricorrenti fatture di software proprietario che una tipica software house si accolla. È un costo ricorrente che non abbiamo bisogno di recuperare nei prezzi dei moduli.

Lo stesso modello di PrestaShop stesso

PrestaShop è open source. Lo hai scelto per quel motivo. Noi abbiamo scelto la nostra infrastruttura per lo stesso motivo. Quando acquisti un modulo da noi, lo acquisti da un team che vive dentro il modello open source dall'inizio alla fine, non da uno che vende moduli per una piattaforma aperta mentre gestisce la propria attività su strumenti proprietari senza i quali non potrebbe sopravvivere.

Come ci siamo arrivati

Questa configurazione non è comparsa su una lavagna. Ciascuno dei suoi elementi ha sostituito un elemento precedente che era venuto meno in modo memorabile.

I container separati esistono perché eravamo stanchi delle segnalazioni «sulla mia macchina funziona» che non riuscivamo a riprodurre. Gli snapshot dello storage esistono perché una volta abbiamo perso quasi un'intera giornata per una migrazione mal riuscita dalla 1.7 alla 8 e abbiamo deciso che una volta bastava. Lo stack di posta self-hosted esiste perché un grande fornitore di webmail ha iniziato a contrassegnare le nostre risposte di assistenza come spam abbastanza spesso da far credere ai clienti che li stessimo ignorando. Il resolver DNS interno ha sostituito un file /etc/hosts modificato a mano che si rompeva ogni volta che qualcuno aggiungeva un nuovo sottodominio di sviluppo. Il wiki interno ha sostituito un mucchio di file Markdown in un repository che nessuno leggeva.

Nulla di tutto ciò è teorico. Ogni cambiamento ha risolto un problema che ci era costato tempo reale. È l'unico motivo per cui è rimasto, ed è lo stesso motivo per cui regge sotto i moduli che stai usando.

Letture correlate

Torna su