Warum manuelle Updates nach den ersten echten Nutzern nicht mehr funktionieren
Du behebst einen Bug auf deinem Laptop. Du lädst die geänderte Datei per SCP auf deinen Server hoch. Du startest die Anwendung neu. Der Bug ist weg. Einfach, oder?
Stell dir jetzt vor, das zu tun, während hundert Leute deine Anwendung nutzen. Du kannst nicht mehr einfach so neu starten – Benutzer werden mitten in der Sitzung rausgeworfen. Stell dir vor, deine Anwendung läuft auf drei Servern, um den Traffic zu bewältigen. Du musst dieselbe korrigierte Datei auf alle drei hochladen, einen nach dem anderen. Wenn du einen Server vergisst, sehen manche Nutzer immer noch die fehlerhafte Version. Schlimmer noch: Sie könnten Fehler sehen, weil alter und neuer Code in derselben Anfrage durcheinandergeraten.
Hier beginnt die eigentliche Herausforderung der Softwareauslieferung. Nicht mit Pipelines oder Tools, sondern mit der einfachen Tatsache, dass sich Anwendungen ständig ändern und manuelle Prozesse nicht mithalten können.
Die eigentliche Quelle von Änderungen
Deine Anwendung wird nach der ersten Veröffentlichung nicht fertig sein. Sie wird sich weiterentwickeln. Änderungen kommen aus allen Richtungen:
- Bugs, die erst auftauchen, nachdem echte Nutzer bestimmte Funktionen verwenden
- Neue Funktionen, die für das nächste Release geplant sind
- Konfigurationsänderungen, weil der Server mit wachsendem Traffic kämpft
- Sicherheitspatches, die sofort ausgerollt werden müssen
Jede einzelne dieser Änderungen muss dorthin gelangen, wo deine Anwendung läuft. Und das immer wieder, solange Menschen deine Anwendung nutzen.
Die Falle der Build-Konsistenz
Hier ist ein Szenario, das sich täglich in Teams abspielt. Du behebst einen Bug auf deinem Laptop. Der Fix funktioniert in deiner lokalen Umgebung einwandfrei. Du lädst die Datei auf den Server hoch, startest neu – und die Anwendung stürzt ab.
Was ist passiert? Vielleicht hat dein Laptop eine andere Version einer Bibliothek. Vielleicht hast du vergessen, eine Konfigurationsdatei zu aktualisieren, die nur auf dem Server existiert. Vielleicht hast du den Code mit anderen Einstellungen kompiliert. Der Fix hat auf deinem Rechner funktioniert, aber die Server-Umgebung ist etwas anders.
Jetzt steckst du fest und versuchst herauszufinden, warum die Produktionsumgebung sich anders verhält als dein lokales Setup. Du behebst das Problem, lädst erneut hoch und hoffst, dass es diesmal klappt. Aber dieselbe Unsicherheit schleicht sich bei jeder manuellen Änderung wieder ein.
Das liegt nicht an Nachlässigkeit. Es geht um die grundlegende Unzuverlässigkeit manueller Prozesse, wenn sie wiederholt werden. Jedes Mal, wenn du manuell baust, besteht eine kleine Chance, dass etwas anders läuft. Ein einziger Unterschied reicht aus, um eine laufende Anwendung zu zerstören.
Der blinde Fleck beim Testen
Manuelles Testen hat dasselbe Problem. Wenn du Änderungen von Hand testest, musst du dich an jeden Schritt erinnern, den du beim letzten Mal gemacht hast. Hast du den Login-Ablauf geprüft? Hast du die Funktion verifiziert, die von dieser kleinen Änderung betroffen sein könnte? Hast du den Grenzfall getestet, der letzten Monat kaputtging?
Je häufiger du aktualisierst, desto wahrscheinlicher ist es, dass du einen Testschritt auslässt. Und wenn du einen auslässt, gelangen Bugs in die Produktion. Nicht, weil du faul bist, sondern weil das menschliche Gedächtnis nicht dafür gemacht ist, dieselbe Abfolge von Dutzenden Schritten jedes Mal perfekt zu wiederholen.
Der Multi-Server-Albtraum
Gehen wir zurück zum Drei-Server-Szenario. Selbst wenn du es schaffst, dieselbe Datei auf alle Server hochzuladen, hast du jetzt ein Timing-Problem. Während du auf Server zwei hochlädst, läuft auf Server eins bereits der neue Code und Server drei hat noch den alten Code. Benutzer werden je nach Last auf verschiedene Server verteilt, was bedeutet, dass sie innerhalb derselben Sitzung unterschiedliche Versionen deiner Anwendung sehen könnten.
So sieht ein manuelles Update in der Praxis aus:
# Manuelles Hochladen auf jeden Server, einzeln
scp app.jar user@server1.example.com:/opt/app/
ssh user@server1.example.com 'systemctl restart app'
scp app.jar user@server2.example.com:/opt/app/
ssh user@server2.example.com 'systemctl restart app'
scp app.jar user@server3.example.com:/opt/app/
ssh user@server3.example.com 'systemctl restart app'
Stell dir jetzt vor, du hast zehn Server oder du vergisst, welchen du schon aktualisiert hast. Eine einfache Skript-Schleife reduziert das Risiko:
# Skript-Schleife – weniger Raum für Fehler
for server in server1 server2 server3; do
scp app.jar "user@$server.example.com:/opt/app/"
ssh "user@$server.example.com" 'systemctl restart app'
done
Selbst dieses kleine Skript eliminiert die Möglichkeit, einen Server zu überspringen oder in der falschen Reihenfolge neu zu starten. Aber es hängt immer noch davon ab, dass du dich erinnerst, es auszuführen, und die richtige Datei lokal hast.
Diese Inkonsistenz erzeugt Bugs, die nahezu unmöglich zu reproduzieren sind. Ein Benutzer meldet ein Problem, aber wenn du dir die Logs ansiehst, laufen alle Server auf derselben Version. Das Problem verschwindet, aber du hast keine Ahnung, warum. Und es wird beim nächsten manuellen Update wiederkommen.
Warum Konsistenz nicht verhandelbar wird
An diesem Punkt wird das Muster klar. Manuelle Prozesse sind nicht konsistent. Jedes Mal, wenn du von Hand baust, testest oder bereitstellst, gibt es eine kleine Chance auf Abweichung. Eine Abweichung im Build-Prozess, ein übersprungener Test, ein vergessener Server – jeder davon kann Probleme verursachen. Und wenn du häufig aktualisierst, wird die Wahrscheinlichkeit, dass mindestens eine Abweichung auftritt, zur Gewissheit.
Es geht nicht um Faulheit oder den Wunsch, um der Automatisierung willen zu automatisieren. Es geht darum, zu erkennen, dass manuelle Prozesse nicht die Konsistenz liefern können, die eine Live-Anwendung braucht. Deine Nutzer interessiert es nicht, dass du einen langen Tag hattest und vergessen hast, ein Szenario zu testen. Sie wollen nur, dass die Anwendung funktioniert.
Konsistenz bedeutet:
- Jeder Build liefert dasselbe Ergebnis, abgesehen von dem Code, der sich tatsächlich geändert hat
- Jeder Testlauf deckt dieselben Szenarien auf dieselbe Weise ab
- Jede Bereitstellung folgt denselben Schritten auf jedem Server
Der praktische Wandel
Das ist der Moment, in dem Teams beginnen, nach Wegen zu suchen, ihre Build-, Test- und Bereitstellungsprozesse zu standardisieren. Nicht, weil sie in einem Blogbeitrag über CI/CD gelesen haben, sondern weil sie den Schmerz inkonsistenter manueller Updates gespürt haben. Sie haben die nächtliche Debugging-Sitzung erlebt, die durch eine vergessene Konfigurationsdatei verursacht wurde. Sie haben sich mit der Benutzerbeschwerde befasst, die von einem übersehenen Server kam.
Der Wandel findet statt, wenn du erkennst, dass manuelle Prozesse nicht nur langsam sind – sie sind unzuverlässig für sich wiederholende Arbeiten. Und deine Anwendung wird immer wieder Updates benötigen, solange es Bugs zu beheben, Funktionen hinzuzufügen oder Konfigurationen zu ändern gibt.
Ein schneller Konsistenz-Check
Bevor du irgendetwas automatisierst, prüfe, ob diese Grundlagen vorhanden sind:
- Kannst du dieselbe Version deiner Anwendung von Grund auf auf jedem beliebigen Rechner neu erstellen?
- Weißt du genau, welche Dateien sich zwischen deiner aktuellen Version und der vorherigen geändert haben?
- Kannst du überprüfen, ob alle deine Server gerade dieselbe Version ausführen?
- Hast du einen schriftlichen, schrittweisen Prozess für die Bereitstellung, dem auch jemand anderes folgen könnte?
Wenn die Antwort auf eine dieser Fragen nein ist, fang dort an. Tools und Pipelines kommen später. Konsistenz kommt zuerst.
Was das für dein Team bedeutet
Achte beim nächsten manuellen Deployment auf jeden Schritt, den du machst. Beachte die kleinen Entscheidungen, die du triffst, ohne nachzudenken – welche Datei zuerst hochladen, welchen Server zuletzt aktualisieren, welchen Test ausführen. In diesen kleinen Entscheidungen versteckt sich die Inkonsistenz.
Dein Ziel ist es nicht, alle manuelle Arbeit über Nacht zu eliminieren. Es geht darum zu erkennen, dass manuelle Prozesse eine Obergrenze haben. Sie funktionieren gut für einen Server und einen Entwickler. Sie brechen zusammen, wenn du mehrere Server, mehrere Umgebungen und mehrere Updates pro Woche hast. Dieser Zusammenbruch ist kein Versagen – es ist ein Signal, dass dein Auslieferungsprozess sich zusammen mit deiner Anwendung weiterentwickeln muss.