Software releasebeleid

Uit G!ds
Ga naar: navigatie, zoeken

Releasebeleid

Versie 1.2
04-04-2011

Dit document beschrijft de manier waarop wordt bepaald hoe en wanneer G!DS-softwarewijzigingen of –aanpassingen worden gerealiseerd en in gebruik genomen. Drie soorten releases worden hier behandeld. De indeling vindt plaats op basis van impact en omvang. De major-releases, belangrijke uitrol van nieuwe software met meestal een aanzienlijke uitbreiding van de functionaliteit en grote gevolgen voor andere onderdelen van G!DS als lay-out en handleidingen en die een mogelijke veranderde werkwijze met zich mee brengen. De minor-releases, dit zijn over het algemeen kleinere verbeteringen en aanpassingen met ook kleinere gevolgen voor andere processen in G!DS. Emergency-fixes, oplossingen voor een bug.

Technische infrastructuur

Om het releasebeleid te kunnen laten functioneren is het van belang om een aantal aspecten van de technische infrastructuur vooraf te belichten. De G!DS2 applicatie bestaat uit 2 onderdelen, te weten de G!DS2-core en de G!DS2-backoffice. Van beide applicaties is er altijd slechts één in gebruik.

Van de G!DS zijn 3 omgevingen in gebruik, dit zijn:

  • Productie-omgeving
    Hier wordt de G!DS-instantie mee bedoeld waar men de gegevens in bijhoudt en waar websites live hun gegevens uit halen.
  • Zandbakomgeving
    Deze instantie van de G!DS is bedoeld als oefenomgeving voor eindgebruikers en voor websites(bouwers) die dingen willen uitproberen in de G!DS, maar niet het risico willen lopen iets te kunnen beschadigen. De zandbak is in softwarematig opzicht 100% gelijk aan de productie G!DS, alleen wordt er gewerkt in een (niet per sé actuele) kopie van de G!DS productie-database.
  • Acceptatie-omgeving
    Deze omgeving is bedoeld voor de landelijke redactie van de G!DS. Zij kunnen hier nieuwe functionaliteiten uitproberen alvorens deze in gebruik genomen worden op de productie omgevingen. Tevens wordt alle software altijd eerst getest op de acceptatie omgeving alvorens deze in gebruik genomen wordt in de zandbak en productieomgevingen (laatste integratietests).

Nb. Er zijn geen aparte ontwikkelomgevingen. Deze staan allemaal los op de systemen van de ontwikkelaars.

Changes

Als eerder aangegeven, behandelt dit document drie typen releases. Emergency-fixes, minor-releases en major releases.

Emergency fixes zijn het directe gevolg van een ernstig acuut defect. Afhankelijk van de ernst en mogelijkheid om de bug per direct op te lossen, wordt gehandeld. Is een bug per direct te verhelpen en heeft ze geen gevolgen voor het functioneren van G!DS, dan is dit de werkwijze. Mocht een bug leiden tot een wat zwaardere impact op het functioneren, dan wordt de bug behandeld als RFC en dientengevolge in die procedure opgenomen.

Het proces voor major- en minor-releases verloopt als volgt: Verzoeken tot wijzigingen in G!DS komen voort uit het incident-managementproces, via de Mantis of als gevolg van voortschrijdend inzicht. Dit verzoek mondt uit een RFC-traject dat bij App volgens de geldende procedure wordt behandeld. In deze procedure worden de benodigde middelen als tijd, kennis en geld bepaald en een impact-analyse gedaan.

Uit de impact-analyse blijkt voor welke groepen gebruikers de wijzigingen relevant zijn en wat voor gevolgen de eventuele wijziging of aanpassing heeft. De volgende groepen worden daarbij bekeken:

  • De serviceorganisatie (wijzigingen in hulp/beheer tabellen zijn vaak alleen relevant voor de medewerkers van de serviceorganisaties)
  • De provinciaal accountmanagers
  • De lokale accountmanagers
  • Redacteuren
  • Webredacties en webbouwers (veranderingen in de informatiestructuur zijn van belang voor bouwers en redacties van websites aangezien daar de informatie moet worden weergegeven)

Dit resulteert in de vaststelling dat het gaat om een major- of een minor-release. Implementatie en ingebruikname worden door App in overleg met de serviceorganisatie ingepland. Hierbij wordt dus rekening gehouden met de impact van de wijziging en de gebruikersgroepen waarvoor de wijziging merkbaar zal zijn.

Testen/Acceptatie

Alvorens de geïmplementeerde wijzigingen in gebruik genomen kunnen worden, moeten zij worden getest en geaccepteerd. Het testen gebeurt, mede afhankelijk van de grootte van de wijziging, door enkele personen betrokken bij de RFC-procedures of een speciaal hiervoor aangewezen team van G!DS-gebruikers. Als de wijzigingen zijn geaccepteerd door de landelijke G!DS-organisatie wordt in overleg het ingebruiknameproces gepland. Voor meer informatie zie onder.

Communicatie

Uitgangspunt is dat significante wijzigingen van tevoren breed worden gecommuniceerd, zodat de gebruikers op elk niveau dat het betreft kunnen anticiperen. Afhankelijk van het type wijziging en wie er mee worden geconfronteerd gelden er verschillende tijdschema’s.

  • Voor wijzigingen die alleen de serviceorganisatie aangaan: 2 weken van tevoren
  • Voor wijzigingen die provinciaal accountmanagers aangaan: 1 maand van tevoren
  • Voor wijzigingen die lokaal accountmanagers aangaan: 3 maanden van tevoren
  • Voor wijzigingen die redacteuren aangaan: 3 maanden van tevoren
  • Voor wijzigingen die makers en eigenaren van websites aangaan: communicatie via de nieuwsbrieven en de wiki.

De informatie behelst de wijziging, de directe gevolgen en de acties die men daarop dient te nemen of gevolgen waar men op termijn mee wordt geconfronteerd.

Ingebruikname

Als wijzigingen zijn geaccepteerd door de G!DS-organisatie worden deze, rekening houdend met de termijnen genoemd bij communicatie, ingepland om in gebruik te nemen.

Algemeen kan worden gesteld dat nieuwe versies worden geplaatst in de avond van de eerste maandag van de maand, tenzij het noodzakelijk is om dit op een ander tijdstip te doen (bijvoorbeeld voor emergency fixes).

Wijzigingen voor websites

De communicatie ten aanzien van websites (eigenaren, redacteuren, webbouwers) geschiedt door speciaal hiervoor ontwikkelde ‘GML’ functies. Deze functies geven allemaal hun data terug volgens een van te voren vastgestelde structuur.

Uitgangspunt is dat deze structuur zo weinig mogelijk mag veranderen, aangezien de software van websites niet direct overal gewijzigd of aangepast kan worden.

Om op dit uitgangspunt in te spelen is de mogelijkheid gemaakt om wijzigingen in de uitvoer alleen te laten plaatsvinden in een nieuwe versie van de uitvoer ‘GML’. Hierbij blijft de oude versie zo lang mogelijk ondersteund. Hierbij dient wel aangemerkt te worden dat oude versies waarschijnlijk niet voor altijd ondersteund kunnen blijven worden.

Er is altijd één GML versie die wordt aanbevolen om te gebruiken. Deze wordt niet meer gewijzigd. Alle wijzigingen zullen plaats vinden in een ‘in ontwikkeling’ zijnde versie van de GML. De GML versie die ‘in ontwikkeling’ is zal worden gepromoveerd tot de aanbevolen versie in overleg met de serviceorganisatie.

Deze constructie maakt het mogelijk om vernieuwingen voor websites redelijk snel en pragmatisch in de ‘in ontwikkeling’ zijnde GML-versie beschikbaar te stellen zonder dat andere websites hier last van ondervinden. Alle GML versies zijn gedocumenteerd op http://www.gids2.nl/wiki. Hierbij is ook aangegeven wat de status van de GML versie is; ‘niet meer ondersteund’, ‘verouderd maar ondersteund’, ‘aanbevolen’ en ‘in ontwikkeling’.

Wijzingen worden gecommuniceerd via de provinciaal accountmanagers.

Onderzocht gaat worden of deze werkwijze ook kan worden toegepast op wijzigingen die relevant zijn voor redacteuren.

9 november 2009