Was bedeutet in Sugar "upgrade sicher"?

Leider herrscht bei vielen Leuten die Meinung vor, dass das was gratis ist, auch simpel sein muss. Simpel zu konfigurieren, simpel anzupassen.

Dies ist allerdings bei SugarCRM absolut nicht der Fall. Sugar ist eine sehr komplexe Anwendung die aus knapp 6.000 einzelnen Dateien besteht die eben nicht jeder Wald- und Wiesenprogrammierer so ganz einfach anpassen kann.

Aber was heißt anpassen überhaupt? Oder anders: Wann gilt eine Anpassung als "upgrade sicher"?

Grundsätzlich kann Sugar auf zwei Arten angepasst werden: Einmal mit den, wenn man so will, bordeigenen Mitteln (Studio und Module Builder) und zweitens über Zusatzprogrammierungen wie jede andere Anwendung auch.

Im ersten Fall ist mit 99%iger Wahrscheinlichkeit davon auszugehen, dass eine Anpassung die nächste Version überleben wird da man sich nur in den von Sugar gesteckten Richtlinien bewegen kann.

Bei Anpassungen über externe Zugriffe sieht die Sache schon wieder anders aus (dies gilt übrigens auch für fertige Zusatzmodule die Sie sich z.B. von Sugarforge herunterladen): Wenn durch Eingriffe (Zusatzprogrammierungen) keine so genanntes "core" Datei verändert wurde (das sind die Dateien wie Sie im Auslieferzustand vorhanden sind) dann ist eine Aktualisierung zumeist machbar. Sugar überschreibt nämlich bei einem update u.U. alle diese Dateien ohne Rücksicht auf eventuelle Änderungen durch irgendwen. Dies muss auch so sein da ja eine Upgraderoutine nur den Standard kennt. Wurden also keine Dateien verändert, so können alte Dateiversionen während der Aktualisierung bedenkenlos durch neue ersetzt werden und alles funktioniert wieder.

Wurden core Dateien verändert so gilt: Mit einer Aktualisierung sind diese Änderungen weg aber es wird im System möglicherweise noch an vielen Stellen darauf verwiesen. Wenn ein solcher Verweis dann aufgerufen wird, kommt es meist zu dem gefürchteten "White Screen of Death" - man sieht nur mehr den weißen Bildschirm uns sonst nichts mehr. Denken Sie an ein Stiegengeländer das verstärkt wurde. Wurde das Geländer um einen Meter verschoben ist die Verstärkung an der alten Stelle nutzlos und Sie greifen ins Leere (und fallen u.U. tief).

Viele fertige Module nutzen aber eine Wiederherstellungsfunktion von Sugar: Wird ein solches Modul VOR einer Aktualisierung deinstalliert wird auch der alte Zustand wiederhergestellt. Damit sind Upgrades möglich, laufen richtig durch und man kann anschließend dieses Modul (so es denn eine neue Version gibt) wieder einspielen.

Schlimmer ist es bei den angesprochenen Programmierern die das alles nicht wissen (oder denen es einfach egal ist). Die pfuschen um mehr oder weniger Geld tief im System herum und erzielen oft auch das gewünschte Ergebnis. Allerdings kann man meist nichts deinstallieren und es gibt auch so gut wie nie eine Dokumentation. Fatal dabei: Ihr System muss nicht gleich beim ersten Update hochgehen (weil da genau diese Dateien nicht an der Reihe waren) sondern erst beim zweiten oder dritten. Zu dem Zeitpunkt ist der Programmierer vermutlich schon wieder in einem anderen Beruf tätig bzw. es ist nahezu unmöglich ihm die Schuld zu beweisen.

Was können Sie also tun um "upgrade sicher" zu bleiben?

• Nicht upgraden. Dies ist eine Strategie die oftmals auch bei kommerziellen Paketen Anwendung findet. Ob das gut ist muss jeder für sich selbst beurteilen.
• Änderungen nur als Module/Paket über "Module verwalten" installieren. Auf einer Testversion ausprobieren ob das Paket sich auch wieder deinstallieren lässt.
• Wo immer es geht interne Mechanismen (Studio, Module Builder) verwenden um Anpassungen durchzuführen.
• Externe Programmierer vertraglich an die Upgrade Sicherheit binden. Dokumentation verlangen, nach der Installation eine Deinstallation auf einem Testsystem verlangen.
• Und wenn Sie nicht mehr wissen was gemacht wurde: man kann eine Installation auf Upgrade Sicherheit überprüfen und diese auch wiederherstellen. Allerdings sollte dies VOR einem Upgrade gemacht werden. Rechnen Sie auch damit, dass das nicht ganz billig kommen wird.
• Upgrades NIEMALS in einer Live Umgebung durchführen sondern immer zuerst auf einer kopierten Version. Das sind 10 Minuten mehr Arbeit aber man erspart sich unter Umständen viel Kopfweh.
• Anpassungen außerhalb von Pkt. 3 vermeiden. Sammeln Sie Änderungswünsche während der ersten Woche Arbeit in Sugar. Und dann nach 3 Monaten wieder. Werfen Sie die ersten Wünsche weg und realisieren Sie die anderen zur Hälfte. Und Sie werden sehen - niemandem geht etwas ab.