Warum dein Drupal- oder Django-Projekt in der Staging-Umgebung immer wieder abstürzt (und wie du das strukturell beheben kannst)

Mehr als nur Hosting: Vom Framework-Management zur Anwendungsbereitstellung

Es gibt eine ganz bestimmte Art von Nachmittag, die die meisten Backend-Entwickler nur zu gut kennen. Du bist mitten in der Entwicklung eines Features, etwas wirklich Interessantes, genau die Art von Arbeit, wegen der du den Job angenommen hast, und dann kommt eine Slack-Nachricht. Die Staging-Umgebung ist kaputt. Die PHP-Version stimmt nicht mit der in der Produktivumgebung überein. Jemandes „composer install“ hat eine Abhängigkeit heruntergeladen, die mit der gemeinsamen Umgebung in Konflikt steht. Kannst du dir das mal ansehen?

Vier Stunden später hast du noch nichts von dem angefasst, was du dir für diesen Tag vorgenommen hattest, und deine gesamte Zeit damit verbracht, deine CI/CD-Pipeline zu reparieren.

Das ist die vorhersehbare Folge davon, eine Plattform wie einen Hosting-Account zu behandeln – kein Pech.

Was dich „nur Hosting“ tatsächlich kostet

Das Wichtigste zum Mitnehmen: Die Kosten der Umgebungsabweichung zeigen sich weniger in Stunden pro Vorfall als vielmehr in verlorenem Fokus: Die konzentrierte Arbeit, deren Neustart jedes Mal teuer ist, wenn eine Slack-Nachricht jemanden daraus reißt.

Die meisten Entwickler sehen sich nicht als Infrastrukturmanager, aber ein typischer open source Projekt-Setup verlangt es ohnehin von ihnen. Du wartest eine gemeinsam genutzte Staging-Umgebung, gibst Laufzeitversionen manuell in Deployment-Konfigurationen an, richtest Datenbankdienste ein und kümmerst dich regelmäßig um die Folgen, wenn sich etwas zwischen den Umgebungen verschiebt.

Nichts davon gehört zur eigentlichen Arbeit. Es ist das Gerüst rund um die eigentliche Arbeit.

Das Problem mit dem Gerüst verschärft sich, je komplexer die Stacks werden. Eine Drupal-Seite mit Redis für das Caching und MariaDB im Backend ist nach der Konfiguration nicht kompliziert zu betreiben, aber eine saubere, reproduzierbare Konfiguration zu erreichen, erfordert echten Aufwand, und sie über lokale, Staging- und Produktivumgebungen hinweg synchron zu halten, erfordert ständige Wachsamkeit. Kommt ein zweiter Entwickler hinzu, wird es noch komplizierter. Ein dritter, und du hast wahrscheinlich Umgebungskonflikte als wiederkehrenden Tagesordnungspunkt.

Die versteckten Kosten liegen in den Unterbrechungen, nicht in der Zeit, die ein einzelner Vorfall in Anspruch nimmt. Der Kontextwechsel aus der konzentrierten Arbeit heraus ist unverhältnismäßig kostspielig, weil er etwas verdrängt: jene Art von „Deep Work“, für die man etwa 20 Minuten braucht, um wieder hineinzukommen. Multipliziere das mit einem Team über ein Quartal hinweg, und die Kosten sehen nicht mehr wie ein Stapel Support-Tickets aus, sondern wie Features, die langsamer veröffentlicht werden, weil die Leute, die sie entwickeln, ständig von anderen Aufgaben abgelenkt werden.

Die „Infrastructure-as-Code“-Lösung, bei der die meisten Teams nicht bis zum Ende gehen

Kernaussage: Die meisten IaC-Implementierungen hören bei der Bereitstellung auf. Man erhält zwar eine reproduzierbare Umgebung, aber OS-Patches, Zertifikatsrotation und Service-Updates bleiben weiterhin Aufgabe des Teams. Die vollständige Umsetzung dieses Konzepts ist eine Plattform, die alles unterhalb der Anwendungsschicht übernimmt – nicht nur bei der Einrichtung, sondern fortlaufend.

Der Standardratschlag hier lautet „Infrastructure as Code“: Definiere deine Umgebung deklarativ, übergebe sie in die Versionskontrolle und lass keine Konfigurationsabweichungen mehr zu. Das ist richtig – soweit es geht. Das Problem ist, dass die meisten Implementierungen bei der Bereitstellung Halt machen. Du erhältst zwar eine reproduzierbare Umgebung, bist aber weiterhin für die zugrunde liegenden Dienste verantwortlich: Betriebssystem-Patches, Zertifikatsrotation, Verwaltung von Datenbankversionen.

Du hast die Abweichungen reduziert. Den Wartungsaufwand hast du nicht reduziert.

Die umfassendere Version dieses Ansatzes ist eine Konfigurationsdatei, die beschreibt, was deine Anwendung benötigt, und eine Plattform, die die Verantwortung für alles unterhalb dieser Grenze übernimmt – nicht nur zum Zeitpunkt der Bereitstellung, sondern fortlaufend.

Upsuns Ansatz hierfür ist eine einzige Konfigurationsdatei unter .upsun/config.yaml. Für ein Drupal-Projekt mit Redis und MariaDB sieht das in etwa so aus:

applications:
  drupal:
    type: php:8.3                  # exact runtime version, consistent across every environment
    relationships:
      database: "db:mysql"         # wires the app to the database service below
      cache: "redis:redis"         # wires the app to the Redis service below
    mounts:
      "/web/sites/default/files":
        source: local
        source_path: files

services:
  db:
    type: mariadb:10.11            # platform manages patching within this version
  redis:
    type: redis:7.2                # same: version pinned, maintenance handled

Das ist der gesamte Stack. Die Laufzeitversion, die Dienste, die Beziehungen zwischen ihnen. Die Plattform kümmert sich um Betriebssystem-Patches, SSL-Rotation, Dienst-Updates innerhalb der definierten Versionen und die Vernetzung zwischen den Containern. Du musst dich um nichts davon kümmern, weder bei der Einrichtung noch später.

Die PHP-Version in der Konfiguration ist die PHP-Version in der Produktivumgebung. Nicht ungefähr. Nicht „wir glauben schon“. Genau.

Die gleiche Dateistruktur gilt auch für ein Django-Projekt mit Python. Andere Laufzeitumgebung, andere Datenbank, identische Struktur:

applications:
  django:
    type: python:3.12              # exact runtime version, consistent across every environment
    relationships:
      database: "db:postgresql"    # wires the app to the PostgreSQL service below
      cache: "redis:redis"         # wires the app to the Redis service below
    mounts:
      "/app/media":
        source: local
        source_path: media

services:
  db:
    type: postgresql:16            # platform manages patching within this version
  redis:
    type: redis:7.2                # same: version pinned, maintenance handled

Dieselbe einzelne Datei, dieselbe Arbeitsteilung. Die Laufzeitumgebung und die Dienste ändern sich mit dem Stack; was dir die Plattform abnimmt, bleibt gleich.

Warum das für open source-Frameworks noch wichtiger ist

Das Wichtigste auf einen Blick: Open-source-Frameworks sind von Grund auf flexibel, was bedeutet, dass Entscheidungen zur Bereitstellung standardmäßig beim Team liegen. Eine versionsverwaltete Konfigurationsdatei macht diese Entscheidungen explizit und nachvollziehbar, sodass die Frage „Was läuft in der Produktivumgebung?“ eine Antwort erhält, für die man sich nicht per SSH in irgendetwas einloggen muss.

Proprietäre SaaS-Produkte neigen dazu, bestimmte Vorstellungen hinsichtlich ihrer eigenen Bereitstellung zu haben. Open-source-Frameworks sind von Grund auf flexibel, was bedeutet, dass die Bereitstellungsentscheidungen bei dir liegen.

Diese Flexibilität ist größtenteils ein Feature. Deshalb läuft Drupal sowohl auf Shared-Hosting-Servern als auch in hochgesicherten Regierungsinfrastrukturen. Deshalb wird Django gleichzeitig von Start-ups und großen Finanzinstituten genutzt. Es bedeutet aber auch, dass es keine Standardantwort auf die Frage „Wie sollte das bereitgestellt werden?“ gibt – jedes Team trifft diese Entscheidungen also von Grund auf selbst und muss dann mit den Konsequenzen leben.

Der häufigste Fehler liegt hier im sich ansammelnden Pragmatismus, nicht in Inkompetenz. Man trifft frühzeitig eine vernünftige Entscheidung: einen Shared-Staging-Server, ein manuelles Deployment-Skript, einen Cron-Job, der funktioniert – und dann bleibt man für immer daran gebunden. Die Entscheidung machte Sinn, als es noch einen Entwickler und eine Website gab. Sobald es fünf Entwickler und sechs Websites gibt, ist es technische Schuld, für deren Tilgung es keinen offensichtlichen Zeitpunkt gibt.

Eine versionsverwaltete Konfigurationsdatei beseitigt diese Entscheidungen nicht, sondern macht sie sichtbar. Welche Laufzeitumgebung brauchst du eigentlich? Welche Dienste? Wenn diese explizit festgelegt und in die Versionsverwaltung eingecheckt sind, lässt sich die Frage „Was läuft in der Produktivumgebung?“ beantworten, ohne dass man sich per SSH irgendwo einloggen muss.

Die Infrastruktur-Ebene langweilig machen

Das Wichtigste zum Mitnehmen: Das Ziel ist hier eine Infrastruktur, die keine Aufmerksamkeit mehr erfordert, nicht leistungsfähigere Tools. Wenn die Plattform die Routineaufgaben übernimmt, bleibt nur noch die Anwendung übrig.

Das Ziel ist hier eine Infrastruktur, die keine Aufmerksamkeit mehr erfordert.

Viele Entwickler-Tools versuchen, die Infrastruktur leistungsfähiger oder konfigurierbarer zu machen. Manchmal ist das genau das, was man braucht. Häufiger braucht man jedoch etwas, das die Routineaufgaben übernimmt, ohne dass man darüber nachdenken muss, und das sich zurückzieht, wenn man etwas in der Anwendungsschicht debuggt – nicht in der Plattformschicht.

Wenn die Umgebung programmiert wird, über alle Zweige hinweg reproduzierbar ist und von der Plattform statt vom Team gewartet wird, verschwinden Probleme wie „Staging funktioniert nicht“ größtenteils. Was übrig bleibt, ist die Anwendung. Und die ist schließlich das, was du eigentlich entwickeln willst.

Hast du bereits eine bestehende Konfiguration?

Die Konfigurationsdatei beschreibt einen Zielzustand, keinen Migrationspfad. Wenn du Drupal auf einem verwalteten Server mit einem Deployment-Skript betreibst, das du seit drei Jahren pflegst, ist der Umstieg auf eine Plattformkonfiguration lediglich eine Frage des Aufschreibens dessen, was du bereits betreibst: die PHP-Version, die Dienste, die Beziehungen zwischen ihnen. Die Konfiguration wird zur verlässlichen Quelle für eine Konfiguration, die derzeit nur in deinem Kopf und in einer seit sechs Monaten veralteten README-Datei existiert.

Häufig gestellte Fragen (FAQs)

Habe ich weiterhin die Kontrolle über meine PHP- oder Python-Version?

Ja. Du gibst die genaue Version in `.upsun/config.yaml` an. Die Plattform stellt sicher, dass diese Version in jedem Branch und jeder Umgebung einheitlich ist, und kümmert sich um die Sicherheitspatches innerhalb dieser Version. Du gibst die Kontrolle nicht ab; du triffst die Entscheidung einmal und sie wird überall durchgesetzt.

Was passiert mit dem zugrunde liegenden Betriebssystem und den Zertifikaten?

Die Plattform verwaltet die Absicherung des Betriebssystems, Kernel-Patches und die Rotation von SSL-Zertifikaten automatisch. Das sind keine Dinge, die du konfigurierst; sie werden unterhalb der Zeile abgewickelt, die deine Konfigurationsdatei definiert.

Funktioniert das auch mit entkoppelten oder Headless-Stacks?

Ja. Du kannst mehrere Anwendungen in einer einzigen Konfigurationsdatei definieren (zum Beispiel ein Next.js-Frontend und ein Drupal-Backend) und die Plattform kümmert sich um die Vernetzung und Isolierung zwischen ihnen. Es sind keine separaten cloud-Konten oder manuelle Netzwerkkonfigurationen erforderlich.

Warum deckt mein bestehendes Deployment-Skript das nicht ab?

Skripte kümmern sich um das, was du bereits vorausgesehen hast. Die Wartungslücke, die sie hinterlassen, umfasst alles andere: Versionsabweichungen zur Laufzeit, Ablauf von Zertifikaten, Kompatibilität der Dienste über verschiedene Umgebungen hinweg. Eine von der Plattform verwaltete Konfigurationsdatei deckt die laufenden Aufgaben ab, nicht nur die Ersteinrichtung.

Was bedeutet „die Plattform kümmert sich darum“ konkret im Alltag?

In der Praxis: Du aktualisierst die Konfigurationsdatei, wenn du etwas ändern möchtest. Die Plattform wendet diese Änderung konsistent an. Zwischen den Änderungen kümmert sie sich um Patches und Updates, ohne dass das Team eingreifen muss. Der operative Aufwand beschränkt sich auf die Anwendung selbst.