Eine frage an die programmierer hier:
Ich habe eine web-app, die (aus datenschutsgruenden) an verschiedene kunden lizensiert, und vor ort auf deren server installiert wird, wo sie nur lokal zu erreichen ist. Dort passen die kunden die software individuel an, was bedeutet dass sie ihre eigenen (web-)formulare erzeugen die daten sammeln und spaeter ausgewertet werden. Die software stammt noch aus den 90ern, und das frontend sieht auch dementsprechend aus.
Das problem ist nun, dass bestimmte bestandteile modernisiert werden sollen, ohne das bei bestehenden kunden die existierenden forms kaputtgehen. Also einfach jquery rauswerfen und bootstrap rein funktioniert nicht. Selbst wenn wir die 0815-ui fuer login, suche usw. umschreiben wuerden, waere die angepasste kundensoftware kaputt die dann eben versucht auf die alte css/js dateien zuzugreifen um irgendwelche styles oder js-code anzuwenden die vor 10 jahren mal der heisse scheiss war. Die existierenden dateien muessen bleiben wo sie sind, bis der kunde sich entscheidet seine forms selbst zu erneuern.
Teil der software sind also die statischen web assets (js, css, … die in irgendwelchen ordnern auf der platte liegen), und die forms selbst sind irgendwo in der DB oder im code gespeichert.
Wie wuerdet ihr vorgehen, die app schrittweise zu erneuern, ohne die bestehenden kundenanpassungen kaputtzumachen? Mein erster instinkt waere, fuer neu hinzukommende assets versionen-verzeichnisse (z.b. js/datatables/3_0/datatables.js sowie js/datatables/latest/datatables.js ) anzulegen die dann von den forms aus verlinkt werden damit jedes form prinzipiell unabhaengig von anderen teilen ist, aber vielleicht gibt es jemanden der sowas schonmal gemacht hat und andere/bessere loesungen hat?
Wenn nur kleinere Teile modernisiert werden sollen, diese so wegkapseln, dass sie nicht mit dem alten Scheiß kollidieren. Zum Beispiel über Web Components.
Oder falls die Webapp drumherum komplett neu soll und der alte Scheiß den die Kunden noch brauchen, laufen beide separat, der alte Kram wird in den neuen inkludiert in iframes. Der iframe und die Parentseite schicken sich Nachrichten über Broadcast Channels falls sie die Form Daten voneinander brauchen.
Neu bauen, Kunden informieren dass für die neue Version Anpassungen seiner Umgebung notwendig sind und anbieten diese Anpassungen als bezahlte Beauftragung zu machen.
Kunde kann dann entscheiden ob er auf der alten Version bleiben will, oder ob er migrieren will.
Wenn man das zu oft macht, haut dir der Kunde relativ schnell ab. Man selbst ist ja auch genervt wenn windows zum Beispiel nach Updates irgendwelche Settings vergisst
Schon wahr, aber wenn das Ding aus den 90ern stammt, sollte das schon mal drin sein.
Meiner Erfahrung nach entstehen die größten Sorgen meist dadurch, dass irgendjemand sowas irgendwann nicht gesagt hat. Alte Software zu warten über mehrere Dekaden dann auch noch kann in größeren Projekten schnell zum Millionengrab werden.
Ich würde sagen dein Vorschlag klingt erstmal vernünftig. Wir entwickeln momentan eine Webanwendung die aus verschiedenen Services/Uis besteht. Dort werden die einzelnen Services auch über ihre URL versioniert, also z.B. “example.org/api/v2/meinService”. Gibt’s da ne große Änderung, wird v3 released: Bestehende Uis können aber trotzdem noch auf v2 zugreifen - diese wird dann aber irgendwann deprecated/entfernt. Ist zwar ne andere Technologie, verhält sich aber ähnlich wie deine versionierte Ordnerstruktur.
Technisch klingt eine API-Versionierung nach einer guten Lösung.
Ganz wichtig ist dass die alte API (bzw. Assetfolder oder was auch immer) wie @Augapfel@feddit.de gesagt hat deprecated und entfernt wird. Das muss langfristig und klar kommuniziert werden.
Andernfalls wird kein Kunde den Mehraufwand investieren das neue Framework zu lernen und dann die alten funktionierenden Formulare zu migrieren.
Das ist wichtig für euch, sonst müsst ihr nun nicht nur eine Library supporten sondern effektiv zwei. Denn ohne Deprecation bleiben Altkunden beim alten und Neukunden beim neuen Framework.
Damit der Kunde sich nicht über den Tisch gezogen fühlt sollte sich die neue Version auch für ihn lohnen, z.B. mit einer schicken neuen UI und neuen Features, am besten etwas wonach Kunden schon länger gefragt haben.
Oh, und seht zu dass ihr die Doku anpasst auf die neue API, vielleicht sogar mit Migrationshilfen von der alten Version.
Ich würde dem Kunden erstmal schildern, dass seine Software alter Dreck ist und ihm dann vorrechnen, wie viel teurer jede Wartung daran im Vergleich zu einer Neuimplementierung wäre und wann da ein Break Even zu erwarten wäre. Da Kunde nun sicher geschockt in Abwehrhaltung geht, würde ich vorschlagen, nur das nötigste an der bestehenden Software zu machen, damit er arbeitsfähig bleibt, aber zeitgleich eine neue Version in unterschiedlichen Modulen (Kunden lieben das Wort “Modul”) zu konzipieren, natürlich in der Grundversion erstmal nur mit dem nötigsten.
