Terugblik 2020

typewriter image

Als afsluiting van afgelopen jaar zijn wij als bedrijf eens in onze statistieken gedoken wat betreft de ontwikkeling van onze software. Aangezien wij in 2020 onze ontwikkel en release omgeving verder hebben geautomatiseerd waren we vooral benieuwd naar deze statistieken en wat ons dat qua tijd heeft opgeleverd.

In totaal hebben wij in 2020 ruim 3800 code-updates aan onze software doorgezet naar ons versiebeheer en continuous integration platform. Wanneer dit gebeurd worden er automatisch een aantal taken uitgevoerd voor de geupdate software, deze beschrijf ik kort hieronder.

Stap 1:  PHPStan en SonarQube. deze controleren de PHP-code in een project op veelvoorkomende fouten en het correct gebruik van standaarden en bijvoorbeeld of de types van variabelen wel kloppen door de code heen. Dit controleert de "gezondheid" van de code in het algemeen, zijn er bijvoorbeeld mogelijke beveiligingsproblemen geïntroduceerd in de code? Is er opeens duplicate code toegevoegd?

Stap 2: Unit Tests en Codeception. Hier wordt gevalideerd dat de business logica nog klopt van de applicatie en worden er functionele automatische tests uitgevoerd die ook als acceptatie en integratietests gebruikt kunnen worden. Zo weet je zeker dat je hoofdproces, zoals het aanschaffen van producten via een winkelmandje, nog werkt bij elke release.

SonarQube statistics

Mocht de nieuwe code in 1 van de bovenstaande stappen een probleem tegenkomen dan krijgen de ontwikkelaars een melding om deze problemen op te lossen en de code opnieuw te updaten, dit is afgelopen jaar ongeveer 800 keer voorgekomen. Dat lijkt misschien veel op 3800 updates, maar waarom dit goed is en heel erg meevalt zal ik zo uitleggen.

Is de code wel goed bevonden dan worden de volgende taken ook uitgevoerd.

Stap 3: Er wordt automatisch een "schoon" geïnstalleerd image gemaakt van de software met alle daarbij behorende vereisten welke gereleased kan worden.

Stap 4: De testomgeving wordt qua server-structuur automatisch bijgewerkt naar hoe deze versie van de software deze vereist. Dit is mogelijk doordat deze ook in de code van het project beschreven staat en meegenomen wordt in het versiebeheersysteem.

Stap 5: De servers of pods in de testomgeving wordt automatisch geupdate met de nieuwe software-image(s) en er kan handmatig getest en geëvalueerd gaan worden! Hier kan natuurlijk nog feedback op terugkomen van product-owners, klanten en bijvoorbeeld andere programmeurs in het team.

Mochten de wijzigingen op de testomgeving klaar zijn voor acceptatie, dan wordt de code gemerged van de develop branch naar de main branch en wordt automatisch volgens stap 3, 4 en 5 de acceptatie omgeving geüpdatet. Nadat de product-owner of klant de wijzigingen heeft geaccepteerd, dan kan er een release-versienummer aan de huidige code toegekend worden. Als dit gebeurd worden er automatisch releases klaar gezet voor de productie-omgeving. Deze updates voeren wij echter niet direct automatisch uit, maar kan met 1 druk op de knop getriggerd worden.

Terugkomend op die 800 gefaalde pipelines zoals dat in ontwikkelaarsland heet. De reden waarom 800 fouten heel erg meevalt, is ten eerste omdat wij hele strenge tests uitvoeren om een maximaal kwaliteitsniveau en consistentie te waarborgen. Een hoofdletter op een verkeerde plek of een niet gebruikte variabele kan bijvoorbeeld al een fout geven. Waarom? Dit hoeft namelijk niet persé problemen te geven in het gebruik van de software.

Er kan simpel weg nog een oud stukje code zijn dat niet meer gebruikt wordt of een typefout, echter willen wij geen rommel in onze code, dus weg daarmee! Het kan echter ook wijzen op een spelfout in de naam van de variabele waardoor ergens anders een bepaalde waarde niet correct meegenomen wordt in een calculatie. Zo'n fout zal in de meeste gevallen ook met een automatische test naar boven komen (Hé, ik testte deze functionaliteit en het antwoord klopt niet met wat ik verwachtte!).

PHPStan notice

In het uiterste geval werden vroeger zulke issues helemaal niet gedetecteerd (zeker in de tijd voor geautomatiseerde tests en versiebeheer). Dan werd zo'n probleem hopelijk gevonden na uitgebreide handmatige tests op de testomgeving en in het ergste geval belandde zo'n issue in de productie-omgeving en werd jarenlang niet opgemerkt, mogelijk met catastrofale gevolgen voor een bedrijf of persoon.

Kortom, de voordelen:

  • Vroeger, toen zulke taken niet zover geautomatiseerd konden worden, moesten de ontwikkelaars zulke tests en updates e.d. handmatig uitvoeren en met elkaar afstemmen, dit kostte veel tijd.
  • Ontwikkelaars konden niet doorwerken aan de code tijdens het uitvoeren van zulke tests en konden misschien, aangezien het handwerk was een test vergeten te draaien of bijvoorbeeld een fout maken bij het updaten van een omgeving waardoor de boel niet meer werkte.
  • Je was als ontwikkelaar vaak afhankelijk van 1 iemand in het team die alle updates moest regelen voor alle teamleden, naast dat dat dus handwerk was zoals hierboven aangegeven, wat dus ook wachten betekende tot hij tijd had voor jou. Met moderne platformen kan dus iedereen updaten.
  • Je hebt als team inzicht in de code, de voortgang en de resultaten en deze worden ook gearchiveerd. Dit is handig om werk makkelijker op elkaar af te stemmen, je hebt een archief en kan samen terugkijken waarom iets toen misging of niet werkte en het management heeft interessante en belangrijke statistieken om te kijken waar er dingen in het proces of de software verbeterd kunnen worden.

Ervan uitgaande dat wanneer je handmatig tests moest uitvoeren en updates handmatig moest regelen kan je uitgaan van een tijdswinst van al snel twee uur per update.

De conclusie in cijfers:

  • Ruim 3800 updates aan onze softwareproducten in 2020
  • Ongeveer 800 (mogelijke) issues gedetecteerd in de code en afgevangen voordat deze op een testomgeving (en een uiteindelijke release) terecht kwamen en meteen opgelost werden (ongeveer 15 minuten tijdsbesparing per keer)
  • 3000 updates die in 1 keer goed gingen (al snel een twee uur tijdsbesparing per keer, alle tests nog een keer draaien, je infrastructuur updaten, test updaten, acceptatie updaten, productie updaten, allemaal handmatig)
  • Zo'n 6200 uur aan handmatig werk bespaard
  • Dat is zo'n 3.25 FTE aan werk dat we ons bespaard hebben.

Of je dat nou ziet als kostenbesparing of als extra tijd die je hebt om meer ontwikkelwerk te kunnen doen, dat is een hele hoop!

Bij een bedrijf dat veel aan ontwikkelwerk doet zoals wij is het aannemen van 1 DevOpser, die zulke geautomatiseerde omgevingen kan inrichten, opzetten en beheren dus al snel terugverdiend. Bij een klein bedrijf, al is er maar 1 programmeur aan het werk, kan het deze investering echter ook zeker waard zijn, huur tijdelijk iemand in (Dit kan afhankelijk van de software al binnen een paar weken geregeld zijn) en je verdient over het algemeen deze investering binnen een jaar weer terug! Heb je hier vragen over of wilt u advies en hulp hierbij in uw organisatie, neem dan gerust contact op.

Wat ik dus graag wil meegeven aan bedrijven die aan software ontwikkeling doen, ook al is het maar 1 programmeur, kijk eens hoeveel tijd je kwijt bent aan testen / updaten / onnodige bugfixes. Zulke verloren tijd kan je met de huidige tools en technieken zo makkelijk terugverdienen! En daarnaast ook zeer belangrijk: Het maakt je werk ook nog minder frustrerend, leuker en makkelijker!