Bei einem Bugtracker besteht der eigentliche Wert nicht nur aus dem Plugin-Code. Mit jeder Meldung wächst ein fachlicher Datenbestand: Produkte, Versionsbezüge, Anhänge, interne Entscheidungen, Statuswechsel, Belohnungen und Projektverknüpfungen. Ein Update, das diese Informationen überschreibt oder löscht, würde den Zweck des Systems grundlegend gefährden. Update-Sicherheit ist deshalb ein eigener Entwicklungsschwerpunkt.
Welche Daten unbedingt erhalten bleiben müssen
Zum schützenswerten Bestand gehören zunächst Produkte und Bugreports. Darüber hinaus dürfen Anhänge, Logs, Einstellungen, Projektchat-Adressen und verwendetes Schlüsselmaterial nicht verloren gehen. Auch manuell geänderte Produktnamen und Slugs müssen bestehen bleiben, weil sie mit vorhandenen Vorgängen verknüpft sind.
Belohnungen und ihre Vergabehistorie gehören ebenfalls dazu. Ein später deaktivierter Code darf in einem älteren Bugreport weiterhin dokumentiert sein. Nur so lässt sich nachvollziehen, was tatsächlich versendet wurde.
Standarddaten dürfen nur ergänzen, nicht zurücksetzen
Die interne Edition kann eine Ausgangsliste vorhandener Projekte besitzen. Bei einem Update darf diese Liste jedoch nicht wie eine vollständige Wahrheit über die bestehende Installation gelegt werden. Hat der Betreiber einen Produktnamen geändert oder eine Projektchat-Adresse ergänzt, bleibt dieser Wert maßgeblich.
Eine neue Version darf fehlende interne Projekte ergänzen, sofern sie wirklich vorgesehen sind. Sie darf aber keine bestehenden Einträge löschen, umbenennen oder mit leeren Werten überschreiben. Für die neutrale Verkaufsversion gilt zusätzlich, dass überhaupt keine internen Seed-Daten eingespielt werden.
Versionierte Datenbankänderungen statt pauschaler Neuinstallation
Technisch bedeutet Update-Sicherheit, dass Strukturänderungen gezielt und versioniert erfolgen müssen. Neue Felder oder Tabellen werden ergänzt, vorhandene Daten bleiben bestehen. Eine Aktivierungsroutine darf nicht so behandelt werden, als würde das Plugin jedes Mal frisch installiert.
Auch Standardwerte benötigen eine vorsichtige Logik. Sie werden nur gesetzt, wenn die entsprechende Option noch nicht existiert. Ein bewusst leer gelassenes Feld kann eine gültige Entscheidung sein und darf nicht automatisch mit einer vermuteten Adresse gefüllt werden.
Verknüpfungen sind genauso wichtig wie einzelne Datensätze
Ein Ticket ohne Produktbezug, ein Anhang ohne Bugreport oder ein Verlauf ohne verantwortlichen Vorgang ist fachlich beschädigt, auch wenn die jeweilige Datenbankzeile noch vorhanden ist. Die Prüfung eines Updates muss deshalb Beziehungen berücksichtigen.
Besonders bei Zusammenführungen und Dublettenverbindungen ist Sorgfalt nötig. Zwei verbundene Meldungen dürfen nach einer Migration nicht plötzlich als unabhängige Vorgänge erscheinen. Umgekehrt muss eine aufgehobene Zusammenführung korrekt bestehen bleiben.
Schlüsselmaterial nicht unbeabsichtigt erneuern
Werden sensible Werte oder interne Verknüpfungen verschlüsselt gespeichert, gehört das verwendete Schlüsselmaterial zum dauerhaften Systemzustand. Ein Update darf nicht einfach einen neuen Schlüssel erzeugen, wenn dadurch ältere Daten unlesbar würden. Bestehende Schlüssel müssen erhalten und nur über einen kontrollierten Migrationsweg verändert werden.
Dieser Punkt ist im Alltag unsichtbar, für die Zuverlässigkeit aber entscheidend. Eine Oberfläche kann nach dem Update korrekt aussehen, während wichtige gespeicherte Werte im Hintergrund nicht mehr entschlüsselt werden können.
Tests müssen echte Updatepfade abbilden
Eine reine Neuinstallation zeigt nicht, ob bestehende Daten geschützt sind. Für Release-Tests benötigt der Bugtracker daher Installationen mit vorhandenen Produkten, geänderten Namen, Tickets, Anhängen, Belohnungen und Projektchat-Adressen. Erst danach wird die neue Version eingespielt und geprüft.
Die Kontrolle umfasst sichtbare Inhalte und Abläufe: Sind Tickets weiterhin filterbar? Öffnen Produktverknüpfungen das richtige Ziel? Bleiben Anhänge zugänglich? Ist die Historie vollständig? Werden aktive und inaktive Belohnungen korrekt angezeigt?
Auch die Benutzeroberfläche muss Datenverlust vermeiden
Update-Sicherheit endet nicht bei der Datenbank. Ein fehlerhafter Editor kann Werte versehentlich leeren, wenn ein Formular nicht vollständig geladen wird oder bei schmalen Ansichten wichtige Felder verschwinden. Deshalb gehören robuste Modals, klare Speichervorgänge und sichtbare Rückmeldungen zum Schutz des Datenbestands.
AJAX-Speicherung ohne unerwartete Navigation reduziert dabei das Risiko, dass Anwender Eingaben verlieren oder denselben Vorgang mehrfach ausführen.
Kontinuität als Qualitätsmerkmal
Ein Bugtracker dokumentiert die Geschichte eines Produkts. Diese Geschichte muss über Releases hinweg bestehen bleiben. Neue Funktionen sind nur dann ein Fortschritt, wenn sie nicht auf Kosten vorhandener Daten eingeführt werden.
Der CROPS Bugtracker behandelt Update-Sicherheit deshalb nicht als spätere technische Nacharbeit. Sie ist Teil des Produktkonzepts: vorhandene Daten respektieren, Editionen trennen, Beziehungen erhalten und Migrationen nachvollziehbar testen. So wächst das System, ohne seine bisherige Entwicklungsdokumentation zu verlieren.
Eine Migrationsprüfung braucht nachvollziehbare Ergebnisse
Nach einem Testupdate sollte nicht nur „funktioniert“ vermerkt werden. Sinnvoll ist eine feste Kontrolle ausgewählter Referenzdaten: ein umbenanntes Produkt, ein Ticket mit Anhang, eine verbundene Dublette, eine vergebene Belohnung und eine gespeicherte Projektadresse. Werden diese Fälle vor und nach dem Update verglichen, lassen sich Veränderungen schnell erkennen. Auch ein Rückweg aus fehlgeschlagenen Migrationen muss vorbereitet sein, bevor eine neue Version verteilt wird. Das Ziel ist nicht, jede denkbare Serverkonfiguration im Voraus zu garantieren. Es geht darum, die zentralen fachlichen Beziehungen systematisch zu prüfen und bekannte Risiken vor der Veröffentlichung sichtbar zu machen.
Werden Abweichungen gefunden, müssen sie vor dem Release reproduzierbar beschrieben und gezielt korrigiert werden. Nur so lässt sich vermeiden, dass ein stiller Datenfehler erst im produktiven Einsatz auffällt.
