Upgrade/update policy e-commerce platforms

7 januari 2024

Waarom updaten en upgraden?

Het regelmatig updaten en upgraden is van belang voor het “gezond” houden van software. De leverancier komt doorlopend met verbeteringen; denk hierbij aan:

  • Bugs/issues
  • Verhogen van de performance
  • Het beter beveiligen.

In software wordt gebruik gemaakt van diverse codebibliotheken die ook weer hun eigen updates en upgrades kennen. Een e-commerce omgeving is live verbonden aan het internet, publiekelijk toegankelijk; het is dus zaak de omgeving stabiel, betrouwbaar en veilig te houden. Een andere belangrijke reden om regelmatig te updaten is de onderhoudbaarheid van het systeem. Op nieuwere versies kan makkelijker onderhoud worden gepleegd en geldt support vanuit de leverancier (Bijvoorbeeld Shopware, Magento, Bigcommerce). Ook nieuwe (maatwerk- / klantspecifieke) features laten zich makkelijker ontwikkelen tegen een recente versie van de software.

Versie-aanduidingen

Om aan te geven wat de scope en impact van een update is wordt doorgaans gebruik gemaakt van (semantische) versienummers. Deze kennen de volgende standaard opbouw:

[Marketingversie] [Majorversie] [Minorversie] [Patchversie]
Bijvoorbeeld Shopware 6.5.2.1 of Adobe Commerce 2.4.6-p3

  • Een Marketingversie is een commerciële aanduiding voor de software generatie en staat buiten de updates/upgrades. Wanneer een software generatie een versie opschuift betekent dit veelal her-implementatie.
  • Een Majorversie betekent een grote stap, welke bijna altijd gepaard gaat systematische wijzigingen, waardoor delen van de implementatie moeten worden herzien en uitgebreid testwerk nodig is. We spreken hier van een ‘upgrade’.
  • Een Minorversie betekent een kleinere stap, welke in principe geen systematische wijzigingen mag bevatten. Een implementatie wordt verondersteld te blijven werken zonder al te veel changes. We spreken hier van een ‘update’.
  • Een Patchversie is een nog kleinere stap en brengt geen nieuwe functionaliteit. Meestal worden er alleen security en performance issues mee opgelost.

Hoe vaak updaten en/of upgraden?

Per organisatie kan het update en upgrade beleid verschillen. XSARUS staat voor kwaliteit,  betrouwbaarheid en veiligheid, het is om die reden belangrijk om tenminste een ondersteunde minorversie te hanteren. Wanneer er regelmatig wordt doorontwikkeld aan het platform is het wenselijk mee te gaan met tenminste alle major versies. Dit leidt dan meestal tot eens per 2 jaar een grotere upgrade. Wanneer er hoogfrequent wijzigingen worden doorgevoerd op het platform is het onze aanbeveling om ook minors te installeren. In een laag ritme hebben updates doorgaans veel meer impact dan in een hoog ritme, doordat de stapjes kleiner zijn en er ervaring wordt opgedaan met het proces. We hanteren de volgende strategieën:

  • Baseline: platform draait minimaal op een ondersteunde minor versie, zodat evt. securityissues kunnen worden opgelost met een patch. Advies: review en impact analyse uitvoeren met als mogelijke uitkomst een update.
  • Always-major: platform draait op de meest recente major versie of er een concreet plan om binnen maximaal 6 maanden tot deze versie te komen. Wanneer wordt geupdate is de meest recente minor binnen deze major het doel. Aanpak: jaarlijks en bij elke uitkomende major een analyse starten in doorontwikkelflow met als doel upgraden
  • Latest-and-greatest: platform draait op de meest recente major en daarbinnen de recentste minor. Het is niet per se noodzakelijk altijd patches te installeren; dit kan worden bepaald op basis van een impactanalyse bij uitkomende patches. Aanpak: eens per kwartaal en bij uitkomende minor een analyse starten in doorontwikkelflow met als doel updaten

Het kan incidenteel noodzakelijk zijn af te wijken van het gekozen updatebeleid, bijvoorbeeld door een geplande ontwikkeling of een gebleken afhankelijkheid naar software van derden.

Het update-proces

Het doorvoeren van een updates en upgrades kent het volgende proces:

  1. (XSARUS) Initiatie conform het gekozen updatebeleid en 1e impact analyse
  2. (Klant) Verstrekking akkoord op planning en te verwachte urenbesteding
  3. (XSARUS) Detail impact analyse en aanduiding van wat moet worden getest
  4. XSARUS) Uitvoeren van updates op ontwikkel- en testomgeving:
    - Platform
    - Indien vereist: Afhankelijke modules en plugins
    - Indien vereist: Onderliggende systemen (serversoftware)
  5. (XSARUS) Controleren op eventuele fouten (basistesten) en deze oplossen
  6. (Klant) Uitvoeren van functionele testen op testomgeving
  7. (XSARUS) Oplossen van gemelde fouten en issues
  8. (Klant en XSARUS) Plannen uitrol naar productieomgeving
  9. (Klant) Finale controle productieomgeving bij oplevering

Hulpbronnen

Leveranciers houden overzichten bij van hun versies en de geplande ondersteuning hiervan en geven aan wat de wijzigingen zijn in de software bij elke versie.