Wenn jedes Deployment eine andere Geschichte ist: Die Ad-hoc-Falle

Sie haben ein kleines Team. Vielleicht fünf oder sechs Leute. Die App funktioniert. Die Nutzer sind zufrieden. Deployments finden statt, aber niemand spricht wirklich darüber, wie. Ein Entwickler kopiert Dateien per FTP auf den Server. Ein anderer führt ein Skript von seinem persönlichen Laptop aus. Ein Dritter loggt sich einfach in die Produktion ein und ändert Dinge direkt.

Niemand beschwert sich, weil es meistens funktioniert. Bis es das nicht tut.

Die Person, die "weiß, wie man deployed", geht in den Urlaub. Ein kritischer Bug muss raus, und niemand anders kann die Schritte nachvollziehen. Das Deployment dauert drei Stunden statt zwanzig Minuten. Jemand führt den falschen SQL-Befehl gegen die Produktionsdatenbank aus. Es gibt keine Möglichkeit, das rückgängig zu machen.

Das ist Level 1 der Delivery-Reife: Ad-hoc. Alles ist manuell. Alles ist jedes Mal anders. Und der gesamte Prozess hängt davon ab, wer verfügbar ist, nicht davon, was dokumentiert oder automatisiert ist.

Das Problem der Personenabhängigkeit

Das deutlichste Zeichen eines Ad-hoc-Delivery-Prozesses ist, dass Wissen in den Köpfen der Menschen steckt, nicht in einem gemeinsamen System. Wenn eine Person das Deployment-Wissen hält, wird diese Person zum Flaschenhals. Ist sie im Urlaub, stoppen die Deployments. Verlässt sie das Unternehmen, verlässt das Wissen das Unternehmen mit ihr.

Selbst wenn Dokumentation existiert, ist sie meist veraltet. Jemand hat vor sechs Monaten eine README geschrieben. Seitdem haben sich die Deploymentschritte fünfmal geändert. Niemand hat das Dokument aktualisiert. Neue Teammitglieder lernen durch Versuch und Irrtum, indem sie diejenigen fragen, die zu wissen scheinen, was sie tun.

Das folgende Flussdiagramm zeigt, wie ein Ad-hoc-Deployment in unvorhersehbare Pfade abzweigen kann, jeder mit seinen eigenen Risiken:

flowchart TD A[Entwickler startet Deployment] --> B{Welche Methode?} B --> C[FTP Dateien zum Server] B --> D[Persönliches Skript ausführen] B --> E[Direkte Änderung in Produktion] C --> F[Dateien könnten unvollständig sein] D --> G[Skript läuft nur auf einem Rechner] E --> H[Risiko eines falschen SQL-Befehls] F --> I[Deployment schlägt still fehl] G --> J[Anderer Entwickler kann es nicht ausführen] H --> K[Kein Rollback möglich] I --> L[Person im Urlaub - keine Behebung] J --> L K --> L L --> M[Deployment dauert Stunden]

Hier geht es nicht um Inkompetenz. Kleine Teams überleben oft so, weil die Risiken gering sind. Aber wenn das Team wächst, werden die Risse sichtbar. Jedes Deployment wird zu einem neuen Abenteuer. Niemand kann vorhersagen, ob es zehn Minuten oder zwei Stunden dauert.

Manuelles Deployment: Keins ist wie das andere

In einer Ad-hoc-Umgebung gibt es keine standardisierte Deployment-Prozedur. Jeder Entwickler hat seine eigene Methode. Eine Person könnte per SSH auf den Server gehen, den neuesten Code pullen und den Dienst neustarten. Ein anderer könnte eine Zip-Datei über ein Web-Interface hochladen. Ein Dritter könnte ein lokales Skript ausführen, das nur auf seinem Rechner funktioniert.

Weil es keine einzige Quelle der Wahrheit gibt, kann niemand überprüfen, ob das Deployment korrekt durchgeführt wurde. Wenn etwas fehlschlägt, beginnt der Deployende zu raten. Sie probieren verschiedene Befehle aus, starten Dienste neu, prüfen Logs und hoffen, dass etwas funktioniert. Wenn sie nicht weiterkommen, rufen sie jemand anderen an, der vielleicht mehr weiß.

Dieser Ansatz funktioniert, wenn Sie einmal im Monat deployen. Er wird schmerzhaft, wenn Sie wöchentlich oder täglich deployen müssen. Jedes Deployment trägt das gleiche Risiko, weil der Prozess nie verfeinert wird. Fehler wiederholen sich. Zeit wird damit verschwendet, dieselben Lösungen immer wieder neu zu entdecken.

Datenbankänderungen ohne Sicherheitsnetz

Datenbankmanagement auf Level 1 ist besonders gefährlich. Schema-Änderungen werden direkt auf der Produktionsdatenbank angewendet. Ein Entwickler loggt sich in den Datenbankserver ein, führt ein ALTER TABLE-Statement aus und hofft, dass nichts kaputt geht.

Es gibt keine Migrationsskripte. Keine Versionsverfolgung. Keinen Rollback-Plan. Wenn die Änderung Probleme verursacht, muss derselbe Entwickler herausfinden, wie man sie rückgängig macht, oft durch die Ausführung eines weiteren manuellen SQL-Befehls, der funktionieren könnte oder auch nicht.

Das Team hat keine Möglichkeit zu wissen, welche Version des Schemas gerade läuft. Wenn zwei Entwickler gleichzeitig Änderungen vornehmen, bleiben Konflikte unentdeckt, bis etwas kaputt geht. Produktionsdaten können verloren gehen, beschädigt werden oder in einem inkonsistenten Zustand zurückbleiben.

Infrastruktur aus dem Gedächtnis verwaltet

Server werden manuell eingerichtet. Jemand loggt sich ein, installiert Pakete, konfiguriert Dienste und passt Einstellungen von Hand an. Anwendungskonfigurationen leben in Dateien auf dem Server, nicht in der Versionskontrolle. Wenn ein Server ausfällt, muss sich das Team an jeden Schritt erinnern, der nötig ist, um ihn neu zu erstellen.

Es gibt keine Infrastructure as Code. Keine automatisierte Bereitstellung. Keinen wiederholbaren Einrichtungsprozess. Das Team verlässt sich auf Erinnerungen, Haftnotizen und den guten Willen dessen, der den ursprünglichen Server eingerichtet hat.

Das funktioniert, wenn Sie einen oder zwei Server haben. Es wird unhandlich, wenn Sie skalieren, von Ausfällen erholen oder Umgebungen zum Testen replizieren müssen.

Warum Teams auf Level 1 bleiben

Auf Level 1 zu bleiben ist kein Zeichen von Faulheit oder mangelndem Können. Viele Teams bleiben hier aus guten Gründen:

  • Das Team ist sehr klein, und manuelle Prozesse sind schnell genug.
  • Deployments finden selten statt, sodass der Schmerz nicht konstant ist.
  • Die Anwendung ist nicht kritisch, sodass Ausfälle geringe Auswirkungen haben.
  • Das Team hat andere Prioritäten, die sich dringender anfühlen.

Diese Gründe sind kurzfristig sinnvoll. Aber sie schaffen versteckte Kosten. Jedes manuelle Deployment birgt ein Risiko. Jeder undokumentierte Schritt schafft eine Abhängigkeit. Jede direkte Datenbankänderung erhöht die Wahrscheinlichkeit von Datenverlust.

Das Problem ist nicht, dass das Team etwas falsch macht. Das Problem ist, dass der aktuelle Ansatz nicht skaliert. Wenn das Team wächst, wenn Deployments häufiger werden oder wenn die Anwendung kritischer wird, wird der Ad-hoc-Prozess zu einer Belastung.

Der erste Schritt ist nicht der Kauf eines Tools

Über Level 1 hinauszukommen erfordert keine teuren Tools oder komplexen Pipelines. Der erste Schritt ist einfacher und schwieriger: einzuräumen, dass der aktuelle Prozess unzuverlässig ist, und damit zu beginnen, zu dokumentieren, was während eines Deployments tatsächlich passiert.

Bevor Sie etwas automatisieren, müssen Sie wissen, was Sie automatisieren. Bevor Sie eine Pipeline bauen, müssen Sie sich auf die Schritte einigen. Bevor Sie eine CI/CD-Plattform kaufen, müssen Sie Ihren eigenen Workflow verstehen.

Praktische Checkliste für den Ausstieg aus Ad-hoc

Wenn Sie Ihr Team in dieser Beschreibung wiedererkennen, hier ist, wo Sie anfangen sollten:

  • Schreiben Sie die genauen Schritte für ein Deployment auf, einschließlich jedes Befehls und jedes Entscheidungspunkts.
  • Identifizieren Sie, wer das kritische Wissen hält und was passiert, wenn diese Person nicht verfügbar ist.
  • Listen Sie jeden manuellen Schritt auf, der bei falscher Ausführung zu einem Fehler führen könnte.
  • Dokumentieren Sie das aktuelle Datenbankschema und wie Änderungen angewendet werden.
  • Halten Sie den Server-Einrichtungsprozess fest, einschließlich aller Pakete, Konfigurationen und Abhängigkeiten.

Hier geht es nicht darum, eine perfekte Dokumentation zu erstellen. Es geht darum, das Unsichtbare sichtbar zu machen. Sobald der Prozess aufgeschrieben ist, können Sie sehen, wo die Risiken liegen und wo Automatisierung tatsächlich helfen wird.

Die konkrete Erkenntnis

Ad-hoc-Delivery funktioniert, bis es das nicht tut. In dem Moment, in dem ein Deployment fehlschlägt und niemand weiß, wie man es behebt, oder die Person, die es weiß, nicht erreichbar ist, werden die Kosten manueller Prozesse deutlich. Der Weg nach vorne geht noch nicht über Tools oder Automatisierung. Es geht darum, zuzugeben, dass der aktuelle Weg fragil ist, und damit zu beginnen, aufzuschreiben, was Sie tun, damit Sie es irgendwann besser machen können.