Sichere Softwareauslieferung: Deploy, Migration, Pakete

Drei Stellen, an denen es teuer wird

Ein Großteil der ernsthaften Probleme in der Softwareauslieferung entsteht an drei wiederkehrenden Stellen: beim Deploy selbst, bei Datenbankmigrationen und beim Einbinden neuer Abhängigkeiten. Alle drei haben gemeinsam, dass ein Fehler dort nicht lokal bleibt, sondern unmittelbar die produktive Umgebung betrifft – anders als ein Fehler, der beim Schreiben des Codes noch folgenlos korrigiert werden kann.

Deploy: der Moment ohne Rückweg

Ein Deploy bringt eine neue Version in Betrieb, oft während das System weiterläuft und genutzt wird. Fehlt ein klar definierter Rollback-Weg, wird aus einem fehlerhaften Deploy schnell ein Ausfall, der sich nicht in Minuten, sondern in Stunden beheben lässt. Entscheidend ist deshalb weniger, ob ein Deploy fehlerfrei verläuft – das lässt sich nie vollständig garantieren – sondern, ob ein Fehler nach dem Deploy schnell erkannt und der vorherige Zustand zuverlässig wiederhergestellt werden kann.

Migrationen: irreversibel, wenn niemand daran gedacht hat

Eine Datenbankmigration verändert nicht nur Code, sondern bestehende Daten. Eine Spalte, die gelöscht wird, ein Datentyp, der sich ändert, oder eine Umbenennung ohne Übergangsphase kann Daten unwiderruflich verlieren, selbst wenn der zugehörige Code fehlerfrei ist. Zwei Dinge senken dieses Risiko deutlich: eine Sicherung vor der Migration, die tatsächlich getestet zurückspielbar ist, und eine Migration, die so weit möglich rückgängig gemacht werden kann, statt nur in eine Richtung zu funktionieren.

Neue Abhängigkeiten: fremder Code im eigenen System

Jedes eingebundene Paket bringt fremden Code mit in die eigene Software – inklusive aller Abhängigkeiten, die dieses Paket seinerseits mitbringt. Ein Paket, das kaum noch gepflegt wird, eine Version, die ungeprüft auf die neueste Ausgabe aktualisiert wird, oder eine Bibliothek, die weit mehr Rechte einfordert, als ihre eigentliche Aufgabe erfordert, sind typische Einfallstore. Anders als eigener Code lässt sich fremder Code selten vollständig lesen, bevor er zum Einsatz kommt – umso wichtiger ist eine bewusste Prüfung, bevor eine neue Abhängigkeit überhaupt Teil des Systems wird.

Was eine sichere Auslieferung an allen drei Stellen ausmacht

• Ein Deploy-Prozess mit klar definiertem, getestetem Rollback statt einer Hoffnung, dass nichts schiefgeht
• Migrationen, die vor der Ausführung auf einer Kopie der echten Daten geprüft werden
• Eine Sicherung, die tatsächlich zurückgespielt und nicht nur erstellt wird
• Eine bewusste Prüfung neuer Abhängigkeiten auf Pflegezustand und tatsächlichen Umfang, bevor sie eingebunden werden
• Automatisierte Gates in der Pipeline, die diese Prüfungen bei jeder Auslieferung gleich durchsetzen, statt sie dem Zufall zu überlassen

Wie sich solche Prüfungen als feste Bestandteile in eine bestehende Pipeline einfügen, beschreibt der Beitrag zu Quality Gates in der CI/CD-Pipeline. Wie eng dieses Risiko mit ungetestetem, unter Zeitdruck übernommenem Code zusammenhängt, zeigt der Artikel zur Testabdeckung bei KI-generiertem Code, und wer am Ende für einen Schaden aus einer fehlerhaften Auslieferung einsteht, behandelt der Beitrag Wer haftet für KI-generierten Code?.

Warum diese drei Stellen zusammengehören

Deploy, Migration und neue Abhängigkeiten wirken auf den ersten Blick wie getrennte Themen, teilen sich aber dieselbe Eigenschaft: Ein Fehler dort trifft nicht nur den Code, sondern unmittelbar den laufenden Betrieb und mitunter echte Daten. Wer diese drei Stellen mit derselben Sorgfalt behandelt wie die eigentliche Programmierung, senkt genau dort das Risiko, wo ein Fehler am teuersten wird.