Versiebeheer in een maatwerk omgeving

1. Doel versiebeheer

Het doel van versie beheer is om op ieder moment de juiste versie van de programmatuur in de productieomgeving ter beschikking te hebben. en ook te houden voor herstel bij calamiteiten. Ten tweede is het bedoeld voor het bijhouden van de historie van programmatuur. Zodoende kan worden teruggevallen op voorgaande versies van de applicatie als zich calamiteiten voordoen.
Tenslotte is versiebeheer een middel is om alleen die programmatuur in productie te nemen die door de gebruikersorganisatie is geaccepteerd.

2. Inleiding versiebeheer

Het beheren van software is geen eenvoudige opgave. Door een strikte opzet van het versiebeheer kan veel ellende worden voorkomen. Dit artikel is bedoeld als voorbeeld voor het opzetten van het versiebeheer in een Oracle omgeving. Iedere organisatie zal een eigen invulling kennen en dient als aanvulling op de handboeken en procedures van het ontwikkelteam en systeembeheer te worden gezien.

3. Over te dragen van onderdelen

Als een applicatie gebruik maakt van aanvullende tools dan worden de onderdelen die daarvoor aan de clientzijde benodigd zijn gerekend tot onderdelen van de applicatie. Deze dienen ook in het versiebeheer van de applicatie meegenomen te worden.
In de database opgeslagen standaard routines gelden voor iedere applicatie en worden niet tot de applicatie gerekend

3.1 Onderdelen die geen gegevens bevatten

3.1.1 Rollen

Voor iedere rol binnen de applicatie wordt een script opgeleverd dat de rol genereert en de rechten aan de rol toekent. Een volgende versie van dit script bevat opnieuw het gehele script inclusief het aanmaken van de rol, ook als deze al bestaat. Bij de eerste oplevering van een applicatie mag de definitie van alle rolen in één script worden aangeleverd.
Het toekennen van rollen aan gebruikers is niet geautomatiseerd en kan alleen plaatsvinden met behulp van een Mutatie Autorisatie Formuler.

3.1.2 Synoniemen

Synoniemen worden niet overgedragen tussen de verschillende omgevingen. Aan de hand van de rechten van een gebruiker zullen synoniemen worden aangemaakt door systeembeheer. Dit gebeurt bij het aanmaken van nieuwe gebruikers of bij een wijziging in de applicatie

3.1.3 Schermen, rapporten, grafieken, library’s en SQL*script’s

Van een scherm wordt telkens de source files overgedragen. Op de doelomgeving wordt het uitvoerbare scherm gegenereerd vanuit de source file. Library’s die bij een specifiek rapport of scherm horen dienen samen met dit scherm of rapport opgeleverd te worden, ook als er geen wijzigingen zijn.

3.1.4 Referentieschermen

Schermen van dit type worden ook als source-file overgedragen maar in de doelomgeving niet gegenereerd.

3.1.5 Functies, procedures, packages, triggers, snapshots en views

Deze zijn opgeslagen in de database maar worden gegenereerd vanuit een SQL script. Hiervoor geldt dat de naam van het script overeen dient te komen met de modulenaam.
De betreffende module wordt altijd compleet aangeleverd in het script (CREATE OR REPLACE), hiermee wordt bereikt dat het script altijd de laatste versie van de module bevat.

3.1.6 Indexen niet bedoeld voor een foreign-key of primary-key

Het script voor een index bevat het CREATE statement van de index of een ALTER statement voor de index. Als de index wordt vervangen dan moet het DROP statement in het script zijn opgenomen.

3.2 Onderdelen die wel gegevens bevatten

Dit zijn:
Tabellen en bijbehorende foreign-keys, primary-keys en check-constraints
Sequences
Voor deze onderdelen geldt een andere werkwijze dan voor andere onderdelen omdat hierin gegevens opgeslagen zijn. Omdat deze onderdelen niet opnieuw gegenereerd kunnen worden dienen ze bijgewerkt te worden. Er is gekozen voor het opleveren van één script met daarin de CREATE of ALTER statements voor alle tabellen, sequences en indexen waarbij dit van toepassing is.

4. Versiebeheer

Het versienummer van een module wordt aangegeven met drie cijfers (bijvoorbeeld 1.1.1).
Het eerste cijfer is het releasenummer van de applicatie. Dit wijzigt zelden.
Het wordt bepaald door de eigenaar van de applicatie en staat voor de release van de software.
Het tweede cijfer is het versienummer van de module. Dit versienummer begint bij 1 en wordt opgehoogd telkens wanneer een module die al in productie is wordt aangepast.
Het derde cijfer is het testnummer. Dit cijfer begint bij 1 en wordt opgehoogd telkens wanneer de module opnieuw ter acceptatie wordt aangeboden. Bij wisseling van het tweede cijfer start dit opnieuw bij 1.

4.1 Onderdelen die geen gegevens bevatten

Elke keer dat een module wordt opgeleverd voor productie zal het versienummer van de module één hoger zijn dan de versie in productie. Wanneer de module meerdere malen ter acceptatie wordt aangeboden wordt het testnummer meerdere malen opgehoogd

4.2 Onderdelen die gegevens bevatten

Al deze onderdelen bij elkaar worden altijd als één module opgeleverd. Hiervoor geldt dat het versienummer bij elke oplevering ter acceptatie 1 hoger is dan de vorige oplevering. Wanneer een onderdeel wordt geaccepteerd zullen alle versies, hoger dan de huidige versie in productie, opeenvolgend in productie worden genomen.
De reden hiervoor is dat een database éénmalig wordt aangemaakt waarna er diverse wijzigingen plaatsvinden. Het is immers niet mogelijk om voor een bestaande database met gegevens een nieuw creatie script op te leveren. Gevolg is dat de huidige database aangepast dient te worden.

5. Identificatie source files en overige onderdelen

De bestandsnamen van de sources die opgeleverd worden dienen als volgt te worden opgebouwd:
<MODULENAAM>_<VERSIE>_<RELEASENUMMER>.<EXTENSIE>.

Hierin is <MODULENAAM>
de naam van de module

<VERSIE>
1 e en 2e positie versienummer applicatie opgevuld

3e en 4e positie versienummer module opgevuld

<RELEASENUMMER> 5e en 6e positie releasenummer module opgevuld

<EXTENSIE> de extensie die behoort bij dat type onderdeel.

(bv. HEFAFR50_030203.FMB voor versie 3.2.3 van HEFAFR50.FMB of HEFADN12_012303.FMB voor versie 1.23.3 voor HEFADN12.FMB). Sources files dienen op de machine van de betreffende omgeving bewaard te worden in een aparte directory. Dit dient ook voor de productieomgeving zo te zijn. Doel hiervan is dat op de back-up van een willekeurige machine zowel de sources als de uitvoerbare bestanden staan.
De versienummers opgenomen in de bestandsnaam zullen in de uiteindelijke omgeving verwijderd worden door systeembeheer.

Verder dient het versienummer in schermen zichtbaar te zijn in de titelbalk, bij rapporten op het schutblad of, indien er geen schutblad is, onderaan de pagina.
Voor schermen kan dit bijvoorbeeld gebeuren door de windowtitle van het eerste blok aan te vullen met het versienummer.

Bij modules in de database, zoals triggers, procedures (niet in een package), functies (niet in een packages) en packages, dient het versienummer in de code te worden opgenomen, dit mag bonvenaan of onderaan de code. Dit bij voorkeur voortschrijdend zodat ook wijzigingen in het verleden zichtbaar zijn.

5.1 Uitzondering voor tabellen en sequences.

 De modulenaam voor het script dat tabellen en sequences oplevert heeft als naam
<applikatie afkorting>
. De extensie van dit bestand is .TAB. In dit bestand dienen alle statements ten aanzien van tabellen, sequences, foreign-keys, primary-keys en check-constraints te staan.

Bijvoorbeeld: HEF_010101.TAB

5.2 Uitzondering voor eerste oplevering

Voor de eerste oplevering van een applicatie voor acceptatie is het toegestaan om naast het script dat de tabellen en sequences oplevert ook voor de procedures, functies, triggers en grants één script op te nemen dat dit alles genereert. Dit komt overeen met de methode waarop Oracle Designer de scripts genereert.

Bijvoorbeeld (voor de applicatie IMI):
IMI_010101.SQL wat aanroept:
IMI_010101.TAB (voor de tabellen en sequences)
IMI_010101.TRG (voor database triggers)|
IMI_010101.FNC (voor functies)|
IMI_010101.PRC (voor procedures)
IMI_010101.RGR (voor rollen)|
IMI_010101.VW (voor views)

Indien modules die in één van deze script zitten opnieuw worden opgeleverd dienen ze opgeleverd te worden conform het hoofdstuk Versiebeheer en het hoofdstuk Identificatie source-files.

6. Formulieren

Voor de overdracht van ontwikkeling naar acceptatie en uiteindelijk naar productie dient de juiste procedure gebruikt te worden. Per modulegroep die opgeleverd gaat worden dient een Applicatie Changemanagement Formulier of een Problem Management Formulier ingevuld te worden. Op een bijlage dient aangegeven te worden welke modules worden opgeleverd en welke versies deze modules hebben.
Met één formulier is het mogelijk het gehele traject van één versie van één of meerdere modules te bestrijken van oplevering ter acceptatie tot in productiename. Ook als er meerdere malen een oplevering plaatsvindt.

6.1 Changemanagement

Een applicatie changemangament formulier wordt gebruikt wanneer een applicatie nieuw wordt opgeleverd of wanneer nieuwe functionaliteit wordt toegevoegd. Tevens wordt dit formulier gebruikt wanneer functionaliteit verwijderd dient te worden.

6.2 Problemmanagement

Een problem management formulier wordt gebruikt wanneer in bestaande functionaliteit problemen zijn ontdekt die opgelost dienen te worden.

7. Overdracht

Zeer belangrijk voor een goed versiebeheer is dat de drie omgevingen strikt gescheiden blijven:

Ontwikkeling: Hier werkt de ontwikkelaar aan de applicatie.
Acceptatie: Deze omgeving is alleen toegankelijk voor testers van de gebruikersorganisatie en is bedoeld voor het accepteren van opgeleverd programmatuur.
Oplevering voor deze omgevingen worden uitgevoerd door systeembeheer.
Productie: Dit is de omgeving waarin de eindgebruikers werken.
Oplevering voor deze omgevingen worden uitgevoerd door systeembeheer.

De stappen die programmatuur ondergaat is als volgt:

Ontwikkeling (Actie: ontwikkelaar)
Overdracht ontwikkeling – acceptatie (Actie: systeembeheer)
Acceptatie (Actie: gebruikersorganisatie)
Overdracht acceptatie – productie (Actie: systeembeheer)
In productiename

Het is in alle gevallen uitgesloten dat programmatuur rechtstreeks vanuit ontwikkeling naar productie gaat.

Boeken over dit onderwerp

ITIL A Pocket Guide – 2011 Edition

Auteur: Jan van Bon
Het primaire doel van deze pocket guide is een snelle referentie te bieden van ITIL. Zodoende is dit een zeer waardevolle hulp voor alle managers die actief zijn binnen Service Management.
Europrijs: 18,55
Bestellen

ITIL 2011 Editie – Pocketguide (NL)

Auteur: Jan van Bon
Deze pocketguide voorziet in dezelfde behoefte als de vorige edities: het bieden van een nauwgezette samenvatting van ITIL, gebaseerd op ITIL 2011 Editie.
Europrijs: 18,55
Bestellen

Meer boeken over systeembeheer vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Beoordeel programmeerprocedures 12 vragen.
Werkwijze programmabeheer 17 vragen.
Werkwijze implementatie 19 vragen.
Sidebar