Sharing IT Best Practices with youSharing IT Best Practices with you
Versiebeheer
Versiebeheer van programmasources is sinds de introductie van computers altijd een aandachtspunt geweest. Kort gezegd gaat het om deze vraag: Wat moeten we doen als er een bug ontstaat in een programma dat toevallig onderdeel is van een andere change. Er zijn dus al twee versies van het programma en nu komt er een derde bij. Die derde versie heeft echter niet betrekking op de tweede versie, maar op de eerste… Dit verschijnsel moeten we ook wel branching, iedere versie is een nieuwe tak aan de boom.
In DevOps en bij het werken met meerdere ontwikkelteams moeten we hiervoor geavanceerde tools inzetten, anders is het probleem niet te behappen. Dit artikel beschrijft de issues die we bij versiebeheer tegen kunnen komen.
Het doel van versiebeheer is
Het beheren van software is overigens geen eenvoudige opgave. Door een strikte opzet van het versiebeheer kunnen we echter veel ellende voorkomen. Dit artikel is bedoeld als voorbeeld voor het opzetten van het versiebeheer in een maatwerk omgeving. Iedere organisatie kan echter een eigen invulling kiezen en we willen een handvat verschaffen aan ontwikkelteams en systeembeheer.
Als een applicatie gebruik maakt van aanvullende tools dan rekenen we de onderdelen die daarvoor aan de clientzijde benodigd zijn tot onderdelen van de applicatie. Deze dienen we dus ook in het versiebeheer van de applicatie mee te nemen.
In de database opgeslagen standaard routines gelden voor iedere applicatie en rekenen we niet tot de applicatie.
Voor iedere rol binnen de applicatie leveren we een script op dat de rol genereert en tevens 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 rollen in één script worden aangeleverd.
Het toekennen van rollen aan gebruikers is niet geautomatiseerd en kan alleen plaatsvinden met behulp van een Mutatie Autorisatie Formulier.
Synoniemen dragen we niet over tussen de verschillende omgevingen. Aan de hand van de rechten van een gebruiker zal systeembeheer dus synoniemen aan moeten maken. Dit gebeurt bij het aanmaken van nieuwe gebruikers of bij een wijziging in de applicatie.
Van een scherm wordt telkens de source files overgedragen. We genereren daarna het uitvoerbare scherm op de doelomgeving vanuit de source file. Libraries die bij een specifiek rapport of scherm horen dienen we samen met dit scherm of rapport op te leveren, ook als er geen wijzigingen zijn.
Schermen van dit type worden ook als source-file overgedragen maar in de doelomgeving niet gegenereerd.
Deze zijn opgeslagen in de database maar genereren we 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 bereiken we dat het script altijd de laatste versie van de module bevat.
Het script voor een index bevat het CREATE statement van de index of een ALTER statement voor de index. Als we de index moeten vervangen dan moet het DROP statement in het script zijn opgenomen.
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.
Het versienummer van een module geven we aan met drie cijfers (bijvoorbeeld 1.1.1).
Het eerste cijfer is het releasenummer van de applicatie. Dit wijzigt zelden.
De eigenaar van de applicatie bepaalt dit en het staat voor de release van de software.
Het tweede cijfer is het versienummer van de module. Dit versienummer begint bij 1 en hogen we op telkens wanneer we een module die al in productie is aanpassen.
Het derde cijfer is het testnummer. Dit cijfer begint bij 1 en hogen we op telkens wanneer we de module opnieuw ter acceptatie aanbieden. Bij wisseling van het tweede cijfer start dit opnieuw bij 1.
Elke keer als we een module opleveren voor productie zal het versienummer van de module één hoger zijn dan de versie in productie. Wanneer we de module echter meerdere malen ter acceptatie aanbieden hoogt testnummer meerdere malen op.
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 men een onderdeel accepteert zullen we alle versies, hoger dan de huidige versie in productie, opeenvolgend in productie nemen.
De reden hiervoor is dat we een database éénmalig aanmaken 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 we de huidige database dienen aan te passen.
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 we op de machine van de betreffende omgeving te bewaren 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.
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
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.
Voor de overdracht van ontwikkeling naar acceptatie en uiteindelijk naar productie dienen we de juiste procedure te gebruiken. Per modulegroep die opgeleverd gaat worden dient een Applicatie Changemanagement Formulier of een Problem Management Formulier ingevuld te worden. Op een bijlage dienen we aan te geven welke modules we opleveren 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.
Een applicatie changemangament formulier gebruiken we wanneer we een applicatie nieuw opleveren of bij een toevoeging van nieuwe functionaliteit. Tevens gebruiken we dit formulier bij het verwijderen van functionaliteit.
Een problem management formulier gebruiken we wanneer in bestaande functionaliteit problemen zijn ontdekt die we moeten oplossen.
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 voert systeembeheer uit.
Productie: Dit is de omgeving waarin de eindgebruikers werken.
Oplevering voor deze omgevingen voert systeembeheer uit.
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.
Discussieer mee op LinkedIn.
Meer boeken over systeembeheer vinden.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.