Webapplicatie en updates

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • w00d
  • Registratie: Juni 2004
  • Laatst online: 15:50
Kort gezegd: wat is de beste / meest efficiënte strategie m.b.t. het updaten van een webapplicatie?

De situatie is als volgt; wij hebben een webapplicatie ontwikkeld welke gebruikt wordt voor meerdere projecten (+/- 5 per jaar). Binnen deze webapplicatie kunnen onze klanten bepaalde producten kiezen, hiervoor krijgen ze 2 maanden de tijd waarna hun login gesloten wordt. Binnen een project krijgen niet alle klanten te gelijk een login, dus een project kan best een jaar duren.

De projecten maken allemaal gebruik van dezelfde database, dit omdat de producten die de klanten kunnen kiezen project overschrijdend zijn. Hiervoor is dan ook 1 beheer gedeelte waarin je de producten, klanten, project etc allemaal kan beheren.

Nu is het een web applicatie die groeit, we voeren soms kleine wijzigingen door welke zonder problemen in de lopende projecten gewijzigd kunnen worden. Maar in de planning staan ook grotere wijzigingen, deze brengen nieuwe functionaliteit met zicht mee voor de klant of hierdoor worden bestaande weergaven (schermen) aangepast. Deze grotere update kunnen of willen we soms niet doorvoeren in de lopende projecten.


Wat is nou de beste manier om dit in te richten? Nu draait de applicatie op 1 domein, er draait nu 1 project in (pilot welke 3 maanden geleden gestart is) en de eerste grote update wordt tussen project 1 en 2 doorgevoerd. Nu is die ruimte er, maar vanaf maart volgend jaar gaan we naar de 5 projecten per jaar toe welke de applicatie gaan gebruiken en is die ruimte er niet meer.

Voor het onderhoud aan de code wil je eigenlijk de frontend maar op 1 plek neerzetten en niet voor ieder project een apart "site / subdomein" oprichten. Echter is het doorvoeren van wijzigingen dan niet haalbaar. De backend en de database zijn flexibel genoeg om over de verschillende versie heen te werken verwacht ik.

Ik heb een aantal opties bedacht en benieuwd naar jullie mening / ervaring:

- per project een subdomein voor de frontend
- per (grote) versie de classes, stylesheets en views in een aparte map. Dan via het beheer aangeven in welke versie het project valt en via die manier in de code schakelen naar de juiste map.
- ieder project mee updaten, dus data migreren en bestaande gekozen producten indien nodig converteren naar de nieuwe situatie
- iets anders???

Acties:
  • 0 Henk 'm!

  • Kalentum
  • Registratie: Juni 2004
  • Laatst online: 21:16
Kun je het niet oplossen met autorisaties?

Dus klant X mag functionaliteit Y gebruiken? Dan wordt in de user interface en in de code die functionaliteit aangeboden. En als klant X dat recht niet heeft, dan wordt het niet getoond in de user interface en zal je server side de toegang tot die code moeten blokkeren.

Acties:
  • 0 Henk 'm!

  • w00d
  • Registratie: Juni 2004
  • Laatst online: 15:50
Daar heb ik ook nog aan zitten denken, het zou dan gaan op basis van projecten, echter wordt dat niet echt beheersbaar verwacht ik. Je krijg dan in je code allemaal if / else statements waar bepaalde query of views moeten draaien.

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Zoals jij het beschrijft zou ik googlen op templates en template management.

Want op meer komt het bij mij niet echt over als ik lees dat je verwacht dat je backend het wel gaat trekken.

Het enige tricky stukje wat ik lees is : Classes...
Waarom zijn die verschillend per versie? Dat gaat killing worden.
Zet daar een API oid tussen zodat je views enkel view-dingen doen en je business logica voor je api zit.

Dan kan een view wellicht vanwege een andere template meer / andere data krijgen, maar zolang er geen view-logica voor bestaat wordt er simpelweg niets nieuws getoond.

Je backend moet imho maar 1 manier van praten met je views hebben, en ik vermoed dat je dat nu niet helemaal hebt als je verschillende classes gebruikt.

Acties:
  • 0 Henk 'm!

  • w00d
  • Registratie: Juni 2004
  • Laatst online: 15:50
Voorop gesteld, ik gebruik nog geen verschillende classes ;) Maar het is wellicht een goed punt om de views en business logica verder / helemaal uit elkaar te trekken. Ik zal me hierin is verdiepen.