releases
Wat is een release ?
Een release is een bepaalde versie van software. Letterlijk betekent release "vrijgave" en je kan dit vergelijken met de uitgave van een boek. Een boek heeft een eerste uitgave en als het wat succes heeft, komt er al heel snel een tweede uitgave, derde uitgave. En soms zie je in een boek ook wel "vierde verbeterde uitgave" staan. In dat geval heeft men er ook snel wat tikfouten of andere vergissingen uitgehaald.
Met software gaat het in feite heel gelijkaardig. Je geeft een bepaalde versie van software uit en dit kan een besturingssysteem zijn zoals Windows of Linux, een databank zoals MySQL, een pakket zoals Dynamics AX of andere.
Benaming
Als het gaat om een grote release, verandert het eerste cijfer (Tomcat 5.0, Java 6.0, MySQL 5.0). Soms geeft men een grote release ook een naam : denk hierbij aan Windows 2000, Windows XP, Windows Vista. EN af en toe mengt men het gebruik van namen en nummers voor releases. Java 5.0 staat ook bekend onder de codenaam "Tiger"; Java 6.0 heeft als codenaam Mustang.
werkwijze
Op kantoor werken we steeds met 3 verschillende releases : de "current", de "next" en de "next + 1". Of in het Nederlands de huidige uitgave, de volgende en de daaropvolgende. Voor deze 3 verschillende releases zijn er ook overeenkomstige werkomgevingen. De huidige uitgave staat op de productiemachine waar de gebruikers hun gegevens beheren. De volgende uitgave staat op de acceptatiemachine waar de sleutelgebruikers de software kunnen testen. En de daaropvolgende uitgave staat nog in de steigers op de integratiemachine, waar programmeurs en analisten aan werken om ze op te leveren.
Is de periode voorbij, dan verhuist de volgende uitgave naar de productiemachine en de daaropvolgende uitgave komt dan op de acceptatiemachine. En op de integratiemachine beginnen we met weer een nieuwe release.
Schematisch ziet het er als volgt uit.
iteraties
Op één punt in de tijd hebben we dus 3 releases waar we aan kunnen werken. In het schema spreken we van een periode en op kantoor streven we naar een periode van ongeveer een maand. Deze periode noemen we een iteratie.
Gedurende een iteratie werken we dus gelijktijdig aan 3 verschillende releases : de huidige, de volgende en de daaropvolgende release (current, next, next + 1). Het hoofddoel van de iteratie is natuurlijk de ontwikkeling van de daaropvolgende uitgave. Tijdens de acceptatietesten komen er evenwel fouten naar boven die zo snel mogelijk moeten worden rechtgezet. En jammer genoeg komen er ook nog fouten aan het licht op de productiemachine. Daarvoor moet men meestal alles laten vallen. En juist omwille van deze werkwijze moet men dit soort fouten ten allen prijze vermijden.
Tijdens één iteratie heb je dus drie releases waar de programmeurs en analisten aan werken. Maar de nadruk moet natuurlijk liggen op het werk op de integratiemachine. Anders zit je met een ernstig probleem.
requesten en user stories
Alles start met een vraag van de gebruiker om een fout te verbeteren, iets te wijzigen of nieuwe software (voor pakweg een nieuw rapport) te maken. Deze vraag wordt in een request genoteerd. Op kantoor hebben we daar een Lotus Notes databank voor.
Eenmaal per week worden de nieuwe requesten in XL-formaat gekopieerd. Dit XL werkblad wordt dan ingelezen in Rallydev.
En in Rallydev wordt de request behandeld als een zogenaamde user story.
Een user story is dus gelijk aan een request uit de Lotus Notesdatabank en dus ook gelijk aan een request.
Wel, niet helemaal. Binnen een user story gaan we met een hiërarchie werken. Iedere user story heeft minstens één sub user story.
De eerste user story heeft als naam de nummer en de titel van de request uit de Lotus Notes databank. De sub user story heeft de naam van het Axaptaproject dat de nieuwe software aanbiedt. Axapta is het ERP pakket van Deense origine dat enkele jaren geleden door Microsoft is opgekocht. Ondertussen werken we op kantoor nog wel met Axapta 3.0, maar de opvolger dient zich al aan. En de naam is ondertussen gewijzigd : Dynamics AX 4.0.
We hebben dus één user story die verwijst naar de request en minstens één sub user story die verwijst naar het xpobestand in Axapta dat de nieuwe software oplevert als antwoord op de vraag in de request. Het is de sub user story die aan een iteratie en een release wordt gekoppeld.
taken
Onder de sub user story plaatsen we de taken die door de programmeurs en analisten worden uitgevoerd tijdens de betreffende iteratie en voor de betreffende release. Voor het moment beperken we ons tot de taken gaande van technische analyse, ontwikkeling en test op integratie. Voor functionele analyse en acceptatietesten noteren we geen taken. En wat acceptatietesten betreft : gezien een release 3 iteraties duurt, één voor integratie, één voor acceptatie en één voor productie, zou de acceptatietest sowieso in een andere sub user story geplaatst worden. Logisch ook : het is de sub user story die gekoppeld wordt aan iteratie en release. En acceptatietesten komen altijd één iteratie na de ontwikkeling en integratietesten.
Als we hierbij ook rekening houden met de samenhang met releases en iteraties, dan ziet het plaatje er iets ingewikkelder uit.
Helemaal bovenaan vinden we de release. Iedere release neemt 3 iteraties in beslag : de integratieperiode, de acceptatieperiode en de productieperiode. Tijdens de integratieperiode noteren we de sub user story die we aanmaken zodra we de request uit de Lotus Notes databank hebben ingelezen in Rallydev.
Tijdens de acceptatieperiode kunnen we op een fout stoten. We noteren dan een defect in Rallydev en koppelen die aan een user story. Onder die user story noteren we dan een taak om de fout recht te zetten. Hetzelfde gebeurt tijdens de productieperiode. Maar daar gaan we vaak starten vanuit een request in de Lotus Notesdatabank. Vandaar dat de verhouding defect - user story hier omgekeerd is.
objecten
We hebben al twee bronnen van informatie vermeld, met name de Lotus Notes databank en de Rallydev webapplicatie. Via de LN databank noteren de gebruikers hun vragen. In Rallydev worden die vragen genoteerd en opgedeeld in sub user stories en bijbehorende taken en eventueel defects.
Maar er is nog een derde bron van informatie, met name Axapta zelf. Iedere vraag tot wijziging van software (lees request of user story) leidt natuurlijk tot het opleveren van nieuwe software. Die software kan bestaan uit allerhande objecten, een rapport, een formulier of scherm, een klasse.
De release notes die we bij iedere release opleveren, is een overzicht van de requesten die zijn opgelost en de bijbehorende XPO-bestanden. Daarnaast is er een overzicht van de XPO-bestanden en de bijbehorende objecten (lees nieuwe software) die hierbij worden opgeleverd.
