Is een upgrade altijd beter?

maybe not...

Geschreven door: op
We proberen onze software altijd up to date te houden met de nieuwere versies. Moet je echter altijd zomaar meegaan naar de nieuwste release of zijn er ook valkuilen?

Voor de klant betekent een upgrade: nieuwer, beter, meer mogelijkheden. Voor ons betekent het vaak: nieuwe frameworks, andere technieken, aanpassingen in de structuur. De kansen en de risico's zijn dus duidelijk aanwezig en het is daarom belangrijk om samen te bespreken wat de impact van een upgrade is.

Ook kunnen de oorzaken voor een release verschillen. Het kan zo zijn dat er eenĀ securtiy-leak is ontstaan waardoor de veiligheid van de applicatie of informatie in het geding komt. Dan moet je of het lek dichten of upgraden, maar er is weinig keus. Zit er een groot verschil tussen de huidige versie en de nieuwere versie, dan kan het verstandig zijn een minor upgrade uit te voeren. Voor een major upgrade moet je altijd een impact analyse maken, aangezien de consequenties niet altijd direct te overzien zijn.

Een minor upgrade heeft weinig impact en kan regelmatig worden uitgevoerd. Een major upgrade zal altijd eerst een impact analyse moeten krijgen.

Zelfs vanuit de impact analyse is het voor een major upgrade lastig om de uren van een release in te schatten. Moet de klant dan zomaar akkoord gaan met nacalculatie of moet je dan toch maar een schatting afgeven? Hierbij is het belangrijk dat de upgrade in overleg wordt uitgevoerd. Loopt deze uit, bespreek het met elkaar en neem een besluit over de vervolgstappen. Doe je dit niet, dan heb je straks een prachtig resultaat maar mogelijk ook een berg onvoorziene kosten. Dan is het plezier van de upgrade snel verdwenen.

Op de lange termijn is er geen twijfel mogelijk over de voordelen. Hoe langer je upgrades uitstelt hoe meer tijd ze in beslag nemen en hoe gevoeliger de release wordt voor fouten. Ook zullen er wijzigingen gaan plaatsvinden in de structuur; de afbeeldingen worden anders opgeslagen of de gebruikers van het systeem worden op een andere manier beveiligd. Het heeft allemaal impact op het systeem en gecombineerd is het aantal problemen vaak niet een kwestie van vermenigvuldigen, maar van kwadraat.

Je hoeft niet altijd haantje de voorste te zijn met het doorvoeren van een upgrade, integendeel. Volg de kudde op een gepaste afstand.

Voorbeeld 1

Versie 7.2.0 zal bijvoorbeeld altijd nog bugs bevatten, omdat het de eerste versie van een nieuwe serie is. Omdat het een minor upgrade betreft van je huidige versie 7.1.6 is zal de nieuwe versie niet direct heel veel voordeel opleveren. Kijk daarom goed in de release notes of er nieuwe functionaliteiten zijn die echt nodig zijn. Zo niet, lekker laten gaan tot versie 7.2.2. Zo ja, de upgrade gecontroleerd uitvoeren.

Voorbeeld 2

De huidige versie 6.5.2 werkt goed, maar is de hoogste versie binnen zijn serie. Ondertussen is versie 7.0.6 beschikbaar en wordt door meerdere leveranciers al met een live applicatie of website gedraaid. Voor dan een impact analyse uit om te kijken welke risico's en aanpassingen aanwezig zijn en weeg daarna de voor- en nadelen af. Bespreek dit zowel voor als tijdens de upgrade met elkaar om verrassingen te voorkomen. Voer na de major upgrade een volledige test uit over het gehele systeem.

Conclusie

Een upgrade is (bijna) altijd een verbetering voor het systeem, maar niet per definitie een verbetering voor de applicatie of website. Zeker de nieuwste versies van een nieuwe serie bevatten mogelijk meer bugs dan een stabiele doorontwikkelde versie die wat ouder is. Het kiezen van het upgrademoment moet daarom zorgvuldig en in overleg plaatsvinden.

Nieuwer is niet per definitie altijd beter. Oud is echter wel per definitie slechter.

Is een upgrade altijd beter? Aantal keer bekeken: 1.909