Wer nebenbei mehrere Websites betreibt, kennt den Moment, in dem die Zahl der Baustellen die verfügbare Zeit überholt. Bei mir kam er ungefähr beim fünften Projekt. Die Antwort darauf war keine weitere Abkürzung, sondern eine andere Bauweise.
Überblick
Das Wichtigste in Kürze
- Alle Projekte teilen sich eine Codebasis, aber jedes hat ein eigenes Design und eine eigene Datenbank.
- Jede Änderung an der Datenbank ist eine nummerierte Datei mit dem Kürzel des Mandanten im Namen.
- Ein Push ins Repository löst die Veröffentlichung aus, der Rest läuft ohne weiteres Zutun.
- Der größte Gewinn ist nicht Geschwindigkeit, sondern dass jede Verbesserung sofort allen Projekten zugutekommt.
Ausgangslage
Neunundzwanzig Projekte, ein Feierabend
In meinem Portfolio stehen 29 Projekte, 25 davon mit einer eigenen Projektseite hier auf der Website. Dahinter stecken Reisemagazine, Rechnerportale, Rasseverzeichnisse, ein Portal für Modetransparenz und mehrere Apps. Wäre jedes davon eine eigene Installation, hätte ich 29 Update-Zyklen, 29 Konfigurationen und 29 Stellen, an denen derselbe Fehler steckt.
Der Punkt, an dem das kippt, liegt früher als man denkt. Nicht die Entwicklung kostet die Zeit, sondern die Pflege. Ein Sicherheitsupdate, eine Änderung an der Einwilligungsverwaltung, eine Korrektur an der Sitemap — jede dieser Aufgaben multipliziert sich mit der Zahl der Installationen. Bei drei Projekten merkt man das kaum, bei zehn ist es der ganze Abend.
Bauweise
Ein Kern, viele Oberflächen
Technisch ist das ein mandantenfähiges System. Der Anwendungscode existiert genau einmal. Beim Aufruf entscheidet die Domain, welcher Mandant gemeint ist, welche Datenbank gilt und welches Design geladen wird. Zwei Websites können dadurch völlig unterschiedlich aussehen und trotzdem dieselbe Artikelverwaltung, dieselbe Bildauslieferung und dieselbe Sitemap-Logik benutzen.
Sichtbar wird das an Projekten, die inhaltlich nichts miteinander zu tun haben. Ein Portal für Sternzeichen, eines für Modetransparenz und ein Verzeichnis für Hunderassen teilen sich im Hintergrund fast alles. Was sie unterscheidet, sind Daten, Farben und Schriften.
Datenbank
Jede Änderung ist eine Migration
Die wichtigste Regel in diesem Aufbau betrifft nicht den Code, sondern die Datenbank. Nichts wird von Hand geändert. Jede Änderung ist eine nummerierte Datei, und der Dateiname trägt das Kürzel des Mandanten, für den sie gilt. Eine Datei für das Hunderasse-Portal wird auf keiner anderen Datenbank ausgeführt, auch nicht versehentlich.
Inzwischen liegen 2.078 solcher Dateien im Repository. Das klingt nach viel und ist es auch, aber es ergibt eine lückenlose Geschichte. Ich kann nachvollziehen, wann eine Spalte dazukam, wann eine Weiterleitung gesetzt wurde und mit welchem Text ein Artikel veröffentlicht wurde. Ohne diese Kette wäre der Zustand einer Datenbank nach zwei Jahren schlicht nicht mehr erklärbar.
Der Ablauf ist immer derselbe. Ich schreibe die Migration, spiele sie lokal ein, prüfe das Ergebnis im Browser und schiebe sie ins Repository. Kurz darauf läuft sie auf dem Server, gefiltert nach Mandant, und der Zwischenspeicher der betroffenen Domain wird geleert.
Eine Datenbank, die nur der Code verändert, ist eine Datenbank, die man reparieren kann.
Grenzen
Wo die Bauweise wehtut
Der Aufbau hat eine Kehrseite, die man kennen sollte. Wenn mehrere Websites sich ein Layout teilen, betrifft jeder Fehler darin sofort alle. Das ist gut, solange man zentral repariert, und gefährlich, sobald jemand anfängt, denselben Fehler an drei Stellen zu übermalen. Nach kurzer Zeit weiß niemand mehr, welche Regel nun gilt.
Die zweite Falle sind Klone. Eine neue Website entsteht oft als Kopie einer bestehenden, weil das schnell geht. Dabei wandern Daten mit, die dort nichts zu suchen haben. Beim Aufräumen für diese Website habe ich genau das gefunden, einen Autorendatensatz aus dem Quellprojekt, den nie jemand sehen sollte. Sichtbar war er nicht, richtig war er trotzdem nicht.
Und drittens kostet Mandantenfähigkeit Disziplin. Jede neue Funktion braucht die Frage, ob sie allgemein ist oder speziell. Diese Frage kostet am Anfang Zeit und spart sie später vielfach.
Fazit
Wann sich das lohnt
Für eine einzelne Website lohnt der Aufwand nicht. Ab dem dritten oder vierten Projekt dreht sich das Verhältnis, und ab dem zehnten gibt es aus meiner Sicht keine ernsthafte Alternative mehr, wenn die Projekte von einer Person gepflegt werden sollen.
Der eigentliche Gewinn zeigt sich an unscheinbaren Stellen. Als ich die Bildauslieferung auf moderne Formate umgestellt habe, betraf das nicht ein Projekt, sondern alle. Dieselbe Rechnung gilt für Barrierefreiheit, für Ladezeit und für jede Verbesserung an der Sitemap. Einmal gebaut, überall wirksam.
Fragen
Häufige Fragen
Ist eine gemeinsame Codebasis nicht ein Risiko?
Sie ist ein Risiko und gleichzeitig der beste Schutz. Ein Fehler wirkt sofort überall, eine Korrektur aber auch. Entscheidend ist, dass Änderungen nachvollziehbar sind und dass es einen Weg gibt, sie zurückzunehmen.
Wie kommt eine neue Website dazu?
Sie bekommt ein Kürzel, eine eigene Datenbank und eine Konfiguration mit ihrer Domain. Danach läuft sie auf demselben Code wie alle anderen. Das Design entsteht als eigene Stilebene, damit es keine anderen Projekte beeinflusst.
Warum getrennte Datenbanken statt einer gemeinsamen?
Getrennte Datenbanken machen Fehler teuer, aber lokal. Eine falsch gefilterte Abfrage kann keine fremden Inhalte anzeigen, weil die fremden Inhalte gar nicht erreichbar sind. Außerdem lässt sich ein einzelnes Projekt so ohne Rücksicht auf die anderen sichern oder umziehen.
Über ein Projekt sprechen?
Ob KI-Anwendung, Automation oder Mediaeinkauf — schreib mir gern.
