Een jodiBooks release voorbereiden

Bij jodiBooks doen we iedere twee weken een release. Dat houdt in dat we iedere twee weken tijdelijk de website afsluiten, nieuwe features toevoegen of bug repareren, en de deur weer opendoen. Waarom we dat iedere twee weken doen hebben we al eens uitgelegd in een andere blogpost, release day @jodibooks: we willen jullie zo snel mogelijk een betere jodiBooks ervaring geven.

Maar, voordat er daadwerkelijk een release gebeurt, is er al een hoop werk verzet. Er wordt gepland, getest, gebouwd en klaargezet. Kortom we moeten een hoop voorbereiden. Ook na de werkelijke release zijn we nog niet klaar. We moeten namelijk ook nog vertellen wat er precies veranderd is; de zogenaamde release notes. Al met al duurt die voorbereiding ongeveer een hele dag. In dit blog nemen we jullie mee op een typische release dag.

Diana's bureau na het voorbereiden van een release

Plannen

Alles begint met een plan. Gelukkig hebben we al een jaar vooruit gepland, dus de datum en tijd staat al vast. Maar om iets te releasen, moet je wel weten wat “iets” is. Iedere donderdag hebben we een planningsmeeting. In de week dat we geen release hebben, beslissen we wat we in de volgende release mee willen nemen. We kijken dan waar we mee bezig zijn en of er dingen op onze backlog staan die echt moeten gebeuren.

Een week later, kijken we wat er gelukt is. Wat is af en kan gereleased worden? En wat niet? Dit doen we met een technish concept: git-flow. Git-flow is een manier om je “zichtbare”, gereleaste software (de masterbranch) te scheiden van je ontwikkelsoftware (de developbranch). Laat ik dat uitleggen aan de hand van een beauty-fotoshoot.

model gets made up
“Beauty git-flow” Foto door Candice Picard op Unsplash

Jij als beautyspecialist hebt samen met je collega’s een prachtig model voor je op de stoel zitten. Dit prachtig mens, gaan jullie nog mooier maken. Het haar moet gedaan, make-up op, nagels in de lak, mooie kleren aan (nieuwe features toevoegen). Dit alles doen jullie niet op de set, maar in een kleedkamer. Ondertussen is er ook geen fotograaf alvast foto’s aan het maken.

Een softwareprogrammeur zou nu zeggen dat jullie bezig zijn in de developbranch. Nog specifieker, jullie zijn allemaal bezig met jullie eigen feature. Een iemand doet het haar, de ander de makeup, weer iemand anders de nagels. Jullie zijn allemaal het model nog aan het (op)maken, verbeteren en testen (is dit wat de fotograaf wil zien?). Zodra jullie klaar zijn, “releasen” jullie het model naar de set, de masterbranch. Daar kan iedereen het model zien en foto’s maken. Daar kan het model ook echt model zijn.

Uiteraard zullen jullie nog wel eens de set opgeroepen worden om wat vlekjes weg te werken of een lok haar in het gareel te krijgen. Dat zouden wij een hotfix, patch of een snelle bugfix noemen.

Testen

Unittests

Voordat we de software van develop naar master brengen, wordt alles grondig getest. Allereerst heeft Diana overal unittests bij geschreven. Een unittest test een klein stukje van de software. Dat stukje is het liefst zo klein mogelijk. Wat je met een unittest namelijk wilt doen is controleren of dat ene kleine stukje altijd precies doet wat het zou moeten doen.

Bijvoorbeeld: als je op onze website op ons logo klikt, zou je altijd naar de homepage moeten gaan. Nou moet ik wel eerst even uitleggen hoe zo een link werkt. Als jij klikt, wordt er een functie aangeroepen. Die functie is de daadwerkelijke software die zegt: “als jij hier klikt, dan zorg ik ervoor dat je daar uitkomt”. Die hier en daar, is de input en output van de functie.

Een unittest doet niet meer dan input een functie instoppen en controleren of de output klopt. Dus als “hier” het plaatje van ons logo is, dan verwacht ik dat ik “daar” (op de homepage) uitkom. Als dat niet zo is, word ik rood. Als het wel zo is groen. Het voordeel van dit soort kleine unittests, is dat je heel snel kunt zien waar iets foutgaat. Je zoekt namelijk de rode lampjes tussen de groene.

rode nagels
“Hopelijk zijn onze tests allemaal groen”. Foto door BENCE BOROS op Unsplash

We kunnen hier weer de analogie van het model gebruiken. Iedere nagel zou een eigen unittest kunnen hebben. Is een nagel niet goed gelakt, dan zal die nagel opnieuw moeten. Je hoeft dan niet te gissen naar wat er fout is als de fotograaf of regisseur zegt: “er is iets niet goed met dit model”.

Integratie-, regressie en performance tests

Als “alles groen is”, kan het model de set op. We gaan dan nog niet meteen foto’s maken, eerst moet het licht nog worden afgesteld en gecontroleerd of alles scherp op de foto kan. Komen de kleuren van de makeup en het haar goed naar voren in dit licht, of moet er toch nog wat bijgewerkt worden? Ook gaan we kijken of het klikt tussen het model en de fotograaf. Snappen ze elkaar snel, of duurt het allemaal wat langer?

In ons geval gaat Diana kijken of iedere knop en functie in jodiBooks nog werkt. Ze klikt dus letterlijk op iedere knop en past alles een keer aan. Ze maakt onder andere een bon en een factuur en voert uitgaven in. Ze registreert zichzelf als nieuwe gebruiken en koppelt Facebook. Ik zal hier ophouden, want het stappenplan is in totaal 16 A4-tjes met tests.

Als alles gecontroleerd is, wordt er nog gekeken hoe snel jodiBooks is. We maken van alles 1000 neppers aan: 1000 klanten, 1000 leveranciers, 1000 inkomsten, etc. We kijken vervolgens hoe lang het duurt om iedere pagina 20x te openen.

Grafiek van de laadsnelheid per 20 jodiBooks pagina's. De snelheid fluctueert iedere release. Max 28+ seconden bij 1.14.0.3. Min 22 seconden bij 1.16.12.
De laadsnelheid van jodiBooks per 20 pagina’s

Vinden we daar ook geen probleem, dan “maken” we de release. Dit is een .zip-bestand met alle data die we moeten gaan uploaden naar de server. Ook maken we een rollback. Dit is zo’n zelfde zip-bestand, maar dan met de huidige versie van jodiBooks. Mocht er dus onverwacht toch iets niet werken of fout gaan met uploaden, kunnen we altijd terug naar de status van voor de release.

Releasen

Alles wat we tot nu toe beschreven hebben, doen we dus ergens tussen donderdag en zaterdagavond. Meestal reserveert Diana hier een halve dag voor op vrijdag. Mocht we dan iets tegenkomen, hebben we nog tijd om het te fixen. De release zelf staat echter hard vast. Iedere keer op zaterdagavond vanaf 22:00. We willen absoluut niet dat jij een keer moet inloggen en dat het dan niet kan. De kans dat dat op zaterdagavond is leek ons vrij klein.

Dus, om 22:00 starten we het releaseplan. Dit is net als het testplan een stappenplan, gelukkig niet zo lang (29 stappen). We sluiten de toegang tot jodiBooks af, zetten de software stil en beginnen met het maken van een backup.

We uploaden de nieuwe versie en starten de software weer op. We checken of alles is opgestart en controleren weer of alle pagina’s te benaderen zijn. Dat betekent inloggen en op iedere knop drukken. Gaat alles goed, dan doen we de jodiBooksdeur weer open.

Release notes

Joep houdt ondertussen bij hoe lang de release duurt. Hier doen we nog niks mee, behalve opschrijven als leuk feitje. Later kunnen we gaan meten of we de release efficiënter kunnen doen. Hij duurt nu namelijk een dik half uur.

Soms schrijven we de release notes meteen, maar meestal doen we dat op zondag. Voor ons is half 11 namelijk best laat en we willen na de release snel naar bed. In die release notes schrijven we wat er aan de software is veranderd. Dit kunnen nieuwe dingen zijn, verbeteringen van bestaande, maar soms halen we ook dingen weg.

Voorheen zette Joep dan op maandag een bericht op Facebook en Instagram met een link naar die notes. Dat doen we nu niet meer, want ze staan nu standaard in onze nieuwsbrief. Die we uiteraard wel weer delen via social media.

Logo met release versie nummer. Link naar release notes

Zouden we dingen veranderen?

Met het delen van de release notes zijn we klaar met de release. Vanaf dat moment leven we weer toe naar de volgende en begint het cirkeltje weer van voor af aan. Uiteraard hebben we dit cirkeltje niet in een keer bedacht. We zijn al anderhalf jaar aan het uitproberen en verbeteren en het is nog lang niet perfect. Dus ja, we zouden graag dingen veranderen.

Er staan al een hoop dingen op ons verlanglijstje, zoals de software opsplitsen, zodat we niet altijd de hele website hoeven af te sluiten. Of een development server, zodat we het hele release-stappenplan alvast kunnen doen, ook weer zonder de website te hoeven afsluiten. Ook zouden we graag niet meer handmatig overal op willen klikken. Dat moet ook automatisch kunnen.

Allemaal dingen die een hoop tijd en/of geld kosten. Twee dingen die we nu niet hebben. We besteden die tijd liever aan andere dingen, zoals het maken van de app en een agenda.

Wat we wel kunnen doen, is de tijd waarop we de release doen veranderen. We merken allebei dat we om 10 uur ‘s avonds niet meer helemaal helder en fris zijn. Daardoor maken we soms fouten of duurt het veel langer voordat we een fout gevonden hebben. De volgende release doen we dus niet meer om 22:00 maar om 21 uur.

vrouw ligt moe op bed
“10 uur ‘s avonds is te laat voor ons, wij zijn dan eigenlijk te moe”. Foto door Vladislav Muslakov op Unsplash

Met de komst van de app, gaan er dezelfde test- en releaseplannen komen voor de app. Gelukkig hoeven we dan niet tot zaterdagavond te wachten we die altijd releasen. Jij bepaalt namelijk zelf wanneer je de update downloadt.

Leave a Reply