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?

  • zipfelwurster@feddit.de
    link
    fedilink
    Deutsch
    arrow-up
    3
    ·
    1 year ago

    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.