Über mypresta.rocks Hinweis

Unsere Infrastruktur: 100% Open-Source-Entwicklungsstack

So entwickelt und liefert mypresta.rocks PrestaShop-Module: EU-eigene Infrastruktur, realistische Testumgebungen und menschlich geprüfte Releases.

Der Technik-Stack, mit dem wir tatsächlich arbeiten, und warum wir uns für jeden Baustein entschieden haben

Dies ist die Infrastruktur, die jedes Modul in unserem Katalog baut, testet und ausliefert. Wir schreiben sie nieder, weil die Frage, die uns von Agenturen am häufigsten gestellt wird, in irgendeiner Form lautet: „Sind Sie ein echtes Team mit echter Infrastruktur, oder sind Sie drei Freelancer in einem Discord?" Eine berechtigte Frage. Hier ist die Antwort aus der Vogelperspektive.

Alles in unserer Pipeline ist Open Source oder rechtlich kostenlos. Keine Markenpositionierung. Eine Beschaffungsentscheidung, die wir vor Jahren getroffen haben und für deren Überprüfung wir bislang keinen Anlass hatten. Keine raubkopierte Software, keine geknackten Lizenzplätze, kein proprietärer Anbieter, den wir nicht innerhalb eines Wochenendes ersetzen könnten. Der praktische Nutzen: Nichts in unserer Pipeline hängt von einer Lizenz ab, die wir verlieren könnten, oder von einem SaaS, das uns aussperren könnte.

Der Server

Wir arbeiten auf Hardware in der EU, die uns gehört. Sie nutzt prüfsummengeschützten Speicher mit fehlerkorrigierendem Arbeitsspeicher und regelmäßigen Integritätsprüfungen. Der Host gehört uns; alles andere ist ein Container darauf.

Wir haben uns aus einem ganz bestimmten Grund für diesen Speicheransatz entschieden: Jeder Block ist prüfsummengeschützt, und jeder Datensatz lässt sich in Millisekunden per Snapshot sichern. Die Snapshots sind günstig genug, dass wir sie vor jedem PrestaShop-Upgrade-Test erstellen. Wenn eine 9.0-Migration eine Datenbank zerlegt (das ist vorgekommen), spielen wir den Datensatz zurück, und der Container bootet in Sekunden in den Zustand vor dem Fehler. Die Snapshot-Gewohnheit sorgt dafür, dass uns eine fehlerhafte Migration Minuten kostet, nicht einen Tag.

Warum keine große Public Cloud

Ein vergleichbares Setup auf einer großen Public Cloud, der Arbeitsspeicher, der Speicherplatz, die Bandbreite, die unsere Entwicklungs- und Staging-Container verbrauchen, der Egress-Traffic, um ZIP-Dateien und Demo-Daten hin- und herzuschieben, würde im Betrieb pro Monat spürbar mehr kosten. Die eigene Hardware hält die Infrastruktur bei festen Kosten mit vorhersehbaren Rechnungen, statt einer Variablen, die uns überrascht, wenn für eine Kundendemo Dutzende paralleler Browser hochgefahren werden.

Der andere Grund ist die Datenhoheit. Unsere Infrastruktur steht physisch in der EU und unter unserer Kontrolle. Keine Exposition gegenüber dem US Cloud Act, keine stille Log-Export-Konfiguration, die wir zu deaktivieren vergessen haben, kein Aufschlag pro Anfrage auf die Support-E-Mails, die wir versenden. Für einen kleinen EU-Shop, der mit EU-Händlern arbeitet, ist das das einfachere Modell, und es bedeutet, dass das Support-Gespräch über Ihren Shop, einschließlich aller Logs, die Sie uns senden, auf Hardware bleibt, die uns gehört.

Dedizierte Container, versionierte Images, jede Version, die wir noch unterstützen

Zu jedem Zeitpunkt betreiben wir eine ausgelastete Reihe container-basierter Umgebungen. Jede ist eine vollständige PrestaShop-Installation mit eigener Datenbank, eigenem Admin-Benutzer und eigenem Modulverzeichnis. Wir halten parallele Umgebungen vor für:

  • PrestaShop 1.6.x. Alt, ja, aber es gibt noch Shops, die es betreiben, und die kaufen weiterhin unsere Module.
  • PrestaShop 1.7.6 bis 1.7.8, weiterhin verbreitet in Shops, die ihr Update auf nächstes Jahr verschieben.
  • PrestaShop 8.1 und 8.2, aktueller Produktivbetrieb für die Mehrheit der neuen Shops.
  • PrestaShop 9.0 und 9.1, die Symfony-lastige Zukunft, in die wir dieses Jahr den Großteil unserer Portierungsarbeit stecken.
  • Multistore-Varianten für alle genannten. Multistore bringt Module auf ganz eigene Weise zum Absturz, und wir liefern nicht aus, ohne es getestet zu haben.

Jede PrestaShop-Instanz erhält die MySQL-/MariaDB-Version, die diese Release erwartet, statt einer einheitlichen Datenbankversion für alle Installationen. Eine gemeinsame Cache-Schicht übernimmt das Session- und Objekt-Caching über alle hinweg und bildet so ab, wie ein produktiver Hoster es tatsächlich einrichtet.

Das ist das Setup, das die Fehler abfängt, die Sie sonst erst im Produktivbetrieb entdecken würden. Wenn ein Kunde einen Fatal Error auf einer älteren Kombination aus PrestaShop und Datenbank mit erzwungenem Smarty-Caching meldet, läuft genau diese Kombination bei uns noch vor dem Mittagessen, statt nur einer einzigen „neuesten" Installation, die versionsspezifische Fehler stillschweigend verbirgt.

Selbst gehostet, kein SaaS

Alles, was wir vernünftigerweise selbst hosten können, hosten wir selbst. Auf eigener Hardware in der EU bedeutet das unter anderem:

  • Einen selbst gehosteten Git-Server. Jedes Modul-Repository liegt auf Hardware, die uns gehört, sodass die kanonische Quelle jeder Release, die Sie erhalten, bei den Menschen liegt, die sie schreiben.
  • Einen selbst gehosteten Mail-Stack mit DKIM, SPF und DMARC. Ihre Support-Antworten laufen nicht durch ein SMTP-Relay eines Drittanbieters, das sie scannt.
  • Ein internes Dokumentationssystem für unsere Wissensdatenbank und Runbooks, in dem aus einer einmaligen Lösung eine wiederholbare Vorgehensweise wird, sodass die nächste Person dieselbe Antwort findet, statt sie neu zu erarbeiten.
  • Einen verschlüsselten Secrets-Tresor für die Zugangsdaten, die unsere internen Werkzeuge benötigen.
  • Service-Health-Monitoring, damit wir vom Ausfall eines Containers erfahren, bevor der Kunde es tut.
  • Einen Reverse Proxy mit automatischem SSL auf jedem internen Hostnamen.
  • Internes DNS, sodass neue Entwicklungsumgebungen mit einem einzigen Eintrag in unserem privaten Netzwerk verfügbar werden.

Selbst-Hosting ist mehr Aufwand, als bei einem SaaS die Kreditkarte zu zücken, und dieser Abwägung sind wir uns bewusst. Wir tun es, weil die Alternative bedeutet, ein halbes Dutzend Anbieterausfälle zu haben, die wir nicht beheben können, verstreut über einen Stack, den wir nicht kontrollieren. Wenn etwas um 23 Uhr Probleme macht, starten wir es selbst neu; wir eröffnen kein Support-Ticket und warten.

Wie Releases gebaut und geprüft werden

Das Leben eines Moduls endet nicht beim Kauf, also auch nicht die Infrastruktur dahinter. Die Release, die in Ihrem Back Office landet, wird aus derselben selbst gehosteten Git-Quelle gebaut, gegen die wir entwickeln. Die Auslieferung ist bewusst ein von Menschen geprüfter Vorgang: Unsere automatisierten Jobs und KI-Coding-Assistenten veröffentlichen keine Releases von sich aus. Ein Mensch prüft die Änderung, bevor sie zu einer Release wird. Dieser Prüfschritt ist die Schranke, die eine experimentelle Änderung oder einen halluzinierten Methodenaufruf aus der Version heraushält, die Sie installieren. Der Zugang zu unseren internen Systemen liegt hinter privatem, authentifiziertem Netzwerkzugang statt hinter einem offenen Port.

Die Entwicklungs-Workstation

Unsere primäre Entwicklungsmaschine läuft auf einer modernen, regelmäßig aktualisierten Linux-Umgebung, wir bekommen das neueste PHP, das neueste Node, das neueste von allem, ohne darauf zu warten, dass eine Distribution es absegnet. Das ist wichtig, wenn PrestaShop 9 auf PHP 8.2+ erscheint und wir es in der Woche testen müssen, in der die Release-Notes herauskommen.

Warum Linux auf der Entwicklungsseite

Weil der Produktivbetrieb Linux ist. Case-sensitive Dateisysteme, POSIX-Berechtigungen, echte Symlinks, alles. Wir haben zu viele Module von Windows- oder macOS-Entwicklern übernommen, die auf der Maschine des Autors einwandfrei funktionierten und auf einem echten Shared-Host-Linux-Server sofort brachen, weil Module.php und module.php auf dem einen zwei verschiedene Dateien und auf dem anderen ein und dieselbe sind. Auf derselben OS-Familie wie das Deployment zu entwickeln, schneidet eine ganze Fehlerkategorie aus dem Workflow heraus, bevor sie überhaupt ausgeliefert werden kann.

Wir arbeiten in einem Open-Source-Editor ohne Anbieter-Telemetrie. Die tägliche Laufzeitumgebung besteht aus container-basierten Umgebungen auf dem Server, rootless Containern lokal und vollständigen lokalen VMs, wenn wir sie brauchen, meist, um die cPanel- oder Plesk-Umgebung eines Kunden gut genug nachzubilden, um einen hosting-spezifischen Fehler zu reproduzieren.

KI-Coding-Assistenten

Die neuere Ergänzung: KI-Coding-Assistenten als Teil des täglichen Workflows, nützlich dort, wo eine zweite Perspektive die Arbeit beschleunigt. Sie arbeiten gegen dieselben Repos und dieselben container-basierten Umgebungen wie die Menschen. Keiner von ihnen hat Zugangsdaten, um in den Produktivbetrieb auszuliefern. Das bleibt eine menschliche Handlung. Sie übernehmen zahlreiche kleinere Aufgaben wie „Portiere diesen Controller auf PS 9", „Prüfe auf fehlende CSRF-Tokens", „Übersetze die Modul-Formulierungen ins Niederländische". Sorgfältig eingesetzt steigern sie die Produktivität. Unvorsichtig eingesetzt schleusen sie halluzinierte Methodenaufrufe in eine Codebasis ein, weshalb wir einen menschlichen Prüfschritt beibehalten, bevor irgendetwas eine Release-ZIP erreicht.

Design und Kreatives

Modularbeit ist nicht nur PHP. Jede Release wird mit Icons, Bannern, Store-Screenshots und gelegentlich einem eigenen Icon-Font ausgeliefert. Alles mit Open-Source-Werkzeugen erstellt, mit null Adobe-Ausgaben pro Jahr.

Warum das wichtig ist, wenn Sie ein Modul bei uns kaufen

Wir testen auf dem, was Sie betreiben

Ihr Shop läuft auf Linux, einem Webserver, einer MySQL-/MariaDB-Datenbank, PHP und einer Cache-Schicht. Unsere Entwicklungsumgebung läuft auf demselben Stack, nicht auf einer Windows-mit-WAMP-Annäherung, die sich auf subtile und schmerzhafte Weise anders verhält. Wenn wir ein Modul als „getestet auf einer bestimmten PrestaShop- und Datenbankversion mit aktiviertem Cache" kennzeichnen, dann deshalb, weil wir genau diesen Container buchstäblich laufen haben, nicht weil wir die PrestaShop-Anforderungsseite gelesen haben.

Wir können Probleme auf der Version reproduzieren, die Sie betreiben

Weil jede unterstützte PrestaShop-Version hier weiterläuft, debuggen wir nicht gegen eine einzige „neueste" Installation, die versionsspezifische Fehler stillschweigend verbirgt. Die Snapshot-Gewohnheit bedeutet, dass wir eine Regression auf genau der Version reproduzieren können, die sie ausgelöst hat, statt zu raten.

Geringerer Overhead, kein Lizenzaufschlag

Null Ausgaben für die wiederkehrenden Rechnungen proprietärer Software, die ein typisches Entwicklungsunternehmen trägt. Das sind wiederkehrende Kosten, die wir nicht über die Modulpreise hereinholen müssen.

Dasselbe Modell wie PrestaShop selbst

PrestaShop ist Open Source. Sie haben es aus genau diesem Grund gewählt. Wir haben unsere Infrastruktur aus demselben Grund gewählt. Wenn Sie ein Modul bei uns kaufen, kaufen Sie es von einem Team, das durchgängig innerhalb des Open-Source-Modells lebt, nicht von einem, das Module für eine offene Plattform verkauft, während es sein eigenes Geschäft mit proprietären Werkzeugen betreibt, ohne die es nicht überleben könnte.

Wie wir hierhergekommen sind

Dieses Setup ist nicht auf einem Whiteboard entstanden. Jeder einzelne Baustein hat einen früheren ersetzt, der auf denkwürdige Weise versagt hat.

Die getrennten Container existieren, weil wir es leid waren, „Funktioniert auf meiner Maschine"-Meldungen zu bekommen, die wir nicht reproduzieren konnten. Die Speicher-Snapshots existieren, weil wir einmal den Großteil eines Tages an eine verpfuschte 1.7-auf-8-Migration verloren und beschlossen, dass einmal genug war. Der selbst gehostete Mail-Stack existiert, weil ein großer Webmail-Anbieter unsere Support-Antworten so oft als Spam markierte, dass Kunden dachten, wir würden sie ignorieren. Der interne DNS-Resolver ersetzte eine handgepflegte /etc/hosts-Datei, die jedes Mal brach, wenn jemand eine neue Entwicklungs-Subdomain hinzufügte. Das interne Wiki ersetzte einen Stapel Markdown-Dateien in einem Repo, das niemand las.

Nichts davon ist theoretisch. Jede Änderung hat ein Problem gelöst, das uns echte Zeit gekostet hatte. Das ist der einzige Grund, warum sie Bestand hatte, und es ist derselbe Grund, warum sie unter den Modulen standhält, die Sie betreiben.

Weiterführende Lektüre

Nach oben