Den Ausgangszustand festhalten
Bewahren Sie bei Erhalt des Quellcodes eine unveränderte Kopie auf und bestimmen Sie die gelieferte Version vor der Anpassung. Erfassen Sie Anwendungsversion, Abhängigkeitsdateien, Stand der Datenbankmigrationen und verwendete Installationsanleitung. Klären Sie, welche Zusatzdienste mitgeliefert und welche separat bereitgestellt werden. Zugangsdaten gehören nicht ins Quellarchiv; dokumentieren Sie stattdessen die Namen ihrer Konfigurationseinträge. Diese Grundlage hilft, ursprüngliche Fehler von späteren Änderungen zu unterscheiden und die Umgebung für den Support nachzustellen. Ein Ordner namens „aktuell“ ist kein verlässlicher Versionsnachweis. Jeder bereitgestellte Build braucht eine Kennung, die zu seinem tatsächlichen Quellstand führt.
Eigene Anpassungen nachvollziehbar halten
Beschreiben Sie jede Anpassung über den Kundenbedarf, den sie erfüllt, nicht nur über geänderte Dateien. Trennen Sie Branding und Konfiguration nach Möglichkeit von Eingriffen in das Kernverhalten. Dokumentieren Sie Erweiterungen, die gemeinsame Bereiche wie Berechtigungen, Zahlungszustände oder Hintergrundverarbeitung berühren. Bei einem Anbieter-Update brauchen diese Bereiche besondere Aufmerksamkeit, weil zwei einzeln sinnvolle Änderungen zusammen kollidieren können. Vergleichen Sie vor der Zusammenführung die Anbieteränderungen mit eigenen Annahmen und legen Sie das gewünschte Verhalten fest. Bewahren Sie diese Entscheidung beim Code auf, damit spätere Verantwortliche sie nicht aus einem unerklärten Merge rekonstruieren müssen.
Updates mit repräsentativen Daten proben
Ein Updateplan muss Anwendungscode und Datenänderungen umfassen. Prüfen Sie die Zielversion in einer getrennten Umgebung mit angemessen geschützten, repräsentativen Daten, statt unbeschränkte Produktionsdaten auf Entwicklungsgeräte zu kopieren. Kontrollieren Sie Migrationen, Hintergrundaufgaben, Kundensitzungen und betroffene Betriebsabläufe. Bestimmen Sie, wie Arbeiten vor dem Versionswechsel angehalten oder abgeschlossen werden. Beschreiben Sie die Wiederherstellung bei fehlgeschlagener Bereitstellung und prüfen Sie die tatsächliche Umkehrbarkeit einer Datenbankänderung. Älterer Code stellt alte Daten nicht automatisch wieder her. Sicherungen und ein geprobter Wiederherstellungsablauf müssen zum vorgesehenen Bereitstellungsplan passen.
Releases mit Supportverantwortung verbinden
Erstellen Sie Versionshinweise zu verändertem Verhalten, Konfigurationsbedarf, bekannten Grenzen und betrieblichen Prüfungen. Benennen Sie Freigabeverantwortliche, Beobachter der ersten Betriebsphase und den Ablageort für Probleme. Trennen Sie Fragen zum Originalpaket von solchen zu Eigenentwicklungen und halten Sie für beide ausreichend Nachweise bereit. Vereinbaren Sie den tatsächlich enthaltenen Support und Updatezugang; aus Quellcodebesitz allein folgen diese Leistungen nicht. Ein wartbares Produkt braucht Versionshistorie und wiederholbare Entscheidungen. Ziel ist eine einfachere Bewertung des nächsten Updates, damit nicht jede Aktualisierung eine völlig neue Untersuchung erfordert.