- Der Deploy ist kein Abschluss, sondern der Beginn des Betriebs. Beim Selbstbau fehlt dieser Teil fast immer.
- Vier Dinge entscheiden: eine funktionierende Datensicherung, getrennte Zugangsdaten, ein Blick auf Fehler und ein Weg zurück.
- Zugangsdaten gehören nie in das Verzeichnis, das ausgeliefert wird. Was nicht dort liegt, kann keine Ausschlussliste vergessen.
- Nach jedem Deploy prüfen statt annehmen: ein einzelner Abruf zeigt, ob etwas öffentlich steht, das es nicht sollte.
Es gibt einen Moment, in dem die selbst gebaute Anwendung zum ersten Mal unter ihrer eigenen Adresse erreichbar ist. Das fühlt sich wie das Ende des Projekts an. Tatsächlich ist es der Anfang von etwas, das niemand eingeplant hat, weil es in keiner Anforderung steht und weil eine Coding-KI nicht von selbst danach fragt.
Fertige Produkte bringen diesen Teil mit. Sicherung, Überwachung, Zugriffsschutz und Wiederherstellung sind im Preis enthalten, auch wenn sie nie erwähnt werden. Wer selbst baut, übernimmt diesen Teil vollständig, meistens ohne es zu bemerken.
Der falsche Abschluss
Der Grund für diese Lücke ist nachvollziehbar. Während der Entwicklung gibt es ein klares Ziel: Es soll funktionieren. Sobald es funktioniert, ist das Ziel erreicht, und das Projekt fühlt sich abgeschlossen an. Der Betrieb hat kein vergleichbares Erfolgserlebnis. Er besteht daraus, dass nichts passiert, und das ist schwer zu feiern.
Dazu kommt, dass die Werkzeuge, mit denen heute gebaut wird, beim Bauen hervorragend unterstützen und beim Betreiben schweigen. Eine Coding-KI schreibt Ihnen auf Zuruf eine funktionierende Anwendung. Sie fragt nicht, ob es eine Sicherung gibt, weil danach niemand gefragt hat.
Erstens: eine Sicherung, die Sie einmal zurückgespielt haben
Eine eingerichtete Sicherung und eine funktionierende Sicherung sind zwei verschiedene Dinge. Der Unterschied zeigt sich erst im Ernstfall, und dort ist es zu spät, ihn herauszufinden. Typische Überraschungen: Die Sicherung läuft seit Wochen ins Leere, sie enthält die Datenbank aber nicht die hochgeladenen Dateien, oder niemand kennt das Passwort zum Entpacken.
Der einzige Test, der zählt: Spielen Sie die Sicherung einmal in eine leere Umgebung zurück und prüfen Sie, ob alles da ist. Einmalig, eine halbe Stunde. Danach wissen Sie, ob Sie eine Sicherung haben oder nur eine Vermutung.
Zweitens: Zugangsdaten, die nicht mitfahren
Jede Anwendung braucht Geheimnisse: Datenbankpasswörter, Schlüssel für fremde Dienste, Zugänge zum Mailversand. Der bequeme Ort dafür ist eine Datei im Projektordner. Der sichere Ort ist außerhalb davon, und der Unterschied ist größer, als er aussieht.
Auslieferungswerkzeuge arbeiten meist nach dem Prinzip "alles ausser". Was nicht ausdrücklich ausgeschlossen ist, wandert auf den Server. Eine solche Liste kennt nur die Namen, die jemand eingetragen hat, und sie wird selten erweitert, wenn eine neue Datei dazukommt. Dass eine Datei in der Versionsverwaltung ausgenommen ist, hilft dabei nicht: Das sind zwei getrennte Mechanismen, die nichts voneinander wissen.
Die Lösung ist einfacher als jede Absicherung: Legen Sie die Datei eine Ebene höher oder in ein eigenes Verzeichnis außerhalb des Projekts. Was dort nicht liegt, kann keine Liste vergessen. Wie so ein Fall konkret aussieht und warum kein automatisches Werkzeug angeschlagen hat, ist in Was KI in einer Codebase findet beschrieben. Welche Sorgfalt bei fremden Schlüsseln gilt, steht in API-Key-Sicherheit.
Drittens: mitbekommen, wenn etwas kaputt ist
Ohne eine bewusste Entscheidung erfahren Sie von einem Ausfall durch einen Anruf. Das ist nicht nur unangenehm, es kostet auch Zeit: Zwischen dem Ausfall und dem Anruf liegen oft Stunden, in denen niemand etwas tun konnte.
Für den Anfang reicht sehr wenig. Ein Dienst, der alle paar Minuten Ihre Startseite abruft und Ihnen eine Nachricht schickt, wenn keine Antwort kommt, deckt die häufigsten Fälle ab und ist in zehn Minuten eingerichtet. Alles Weitere, etwa das Sammeln von Fehlermeldungen aus der Anwendung, können Sie ergänzen, wenn der einfache Fall steht.
Viertens: ein Weg zurück
Irgendwann liefern Sie eine Änderung aus, die etwas kaputt macht. Das ist kein Zeichen von Unfähigkeit, sondern der Normalfall. Entscheidend ist, wie lange es dauert, den vorherigen Stand wiederherzustellen. Wenn die Antwort "das muss ich mir erst ansehen" lautet, reparieren Sie unter Druck, und das geht selten gut.
Praktisch heißt ein Weg zurück: Der letzte funktionierende Stand ist irgendwo abgelegt, Sie wissen wo, und das Zurückholen dauert Minuten statt Stunden. Bei einer statischen Seite ist das eine Kopie des Verzeichnisses, bei einer Anwendung mit Datenbank gehört der Stand der Daten dazu. Beides einmal durchgespielt, bevor Sie es brauchen.
Nach jedem Deploy prüfen statt annehmen: Rufen Sie die Adressen ab, unter
denen nichts stehen darf, etwa /.env oder /.git/config. Erwartet
wird eine Fehlermeldung. Kommt stattdessen der Inhalt, ist das kein Hinweis, sondern ein
Vorfall. Dieser Test dauert Sekunden und lässt sich an den Auslieferungsvorgang anhängen.
Der halbe Tag, der sich auszahlt
Die vier Punkte zusammen sind für ein kleines Werkzeug etwa ein halber Tag Arbeit, einmalig. Danach bleibt ein fester Termin pro Quartal, an dem Sie die Sicherung prüfen und Abhängigkeiten aktualisieren. Das ist deutlich weniger, als die Wiederherstellung nach einem Verlust kostet, und im Gegensatz dazu planbar.
Wenn Sie nur einen davon umsetzen: Nehmen Sie die Sicherung, und spielen Sie sie einmal zurück. Alles andere lässt sich nachholen, ein verlorener Datenbestand nicht. Was danach dauerhaft an Pflege anfällt, steht in Wer wartet das in sechs Monaten?.
