Versiebeheer van database changes

Versiebeheer van database changes | 19 april 2012

Versiebeheer van database changes“Database Changes done Right” – thedailywtf.com

Arjen van VlietDICTU AB Team 3

Versiebeheer van database changes | 19 april 2012Dienst ICT Uitvoering2

Inleiding• Kijk uit wat je shared op LinkedIn, voordat je ‘t weet mag je er een

presentatie over geven ;-)• Presentatie is deels gebaseerd op artikel “Database changes done

right”, verschenen op 28-02-2012 op www.thedailywtf.com


Software configuration management (SCM)• Revision control• a.k.a. version control• a.k.a. source control


Definitie Versiebeheersysteem• Een computerprogramma of een verzameling programma's

waarmee men de wijzigingen in documenten, programma's of andere informatie bewaard in computerbestanden kan beheren.

• Het meest gebruikt bij de ontwikkeling van software.• Meerdere mensen kunnen wijzigingen aanbrengen aan dezelfde

bestanden.• Wijzigingen worden meestal aangeduid met een code, het

"revisienummer" of "revisieniveau.• Elke wijziging wordt gekoppeld aan een timestamp en aan de

persoon die de wijziging maakte.• Wijzigingen kunnen vergeleken worden, hersteld en soms

samengevoegd.

http://nl.wikipedia.org/wiki/Computerprogramma

http://nl.wikipedia.org/wiki/Computerbestand

http://nl.wikipedia.org/wiki/Software

http://nl.wikipedia.org/w/index.php?title=Timestamp&action=edit&redlink=1


Bekende tools• Local

• Free/open-source: SCCS (1972), RCS (1982)• Properietary: PVCS (1985)

• Client/Server (‘Centralized’)• Free/open-source: CVS (1990), CVSNT (1998), Subversion(2000)• Proprietary: Software Change Manager (1970s), ClearCase (1992), CMVC

(1994), Visual Source Safe (1994), Perforce (1995), StarTeam (1995), MKS Integrity (2001), AccuRev SCM (2002), SourceAnywhere (2003), SourceGearVault (2003), Team Foundation Server (2005), Rational Team Concert (2008)

• Distributed• Free/open-source: GNU arch (2001), Darcs (2002), DVCS (2002), SVK

(2003), Monotone (2003), Codeville (2005), Git (2005), Mercurial(2005), Bazaar(2005), Fossil(2007), Veracity(2011)

• Proprietary: Teamware (1990s), Code Co-op (1997), Bitkeeper (1998), Plastic SCM (2006)


Verschil tussen client/server en distributed• Client/Server (plaatje):

• Centrale repository• “Locken d.m.v. Check-In /

Check Out”

• Distributed:• Iedere ontwikkelaar heeft een

eigen ‘working copy’ repository.

• Programmacode wordt ge-merged.

• “Possibly the biggest advance in software development technology in the past ten years." [Joel Spolsky]


Maar nu databases…• Databases zijn anders t.o.v. applicatiecode :

• Applicatiecode ‘does stuff’• Applicatiecode ‘leeft’ in source control• Applicatiecode wordt ge(systeem)test, gepromoveerd,

ge(acceptatie)test, gepromoveerd, etc.• Applicatiecode verandert niet na deployment; als er bug

gevonden wordt, begint het proces van voren af aan.

• Databases ‘leven’ op een database server.• Er kunnen andere instances zijn (ontw, test, accp), maar de

produktie database is de belangrijkste.• Databases ‘don’t do stuff’, maar ondergaan queries en updates• Databases veranderen wel na deployment, dat is de reden dat

ze uberhaupt bestaan.


‘Database changes done wrong’• Je kunt niet even een set bestanden in een directory neerzetten en

roepen dat de nieuwe database versie uitgerold is…• Idem voor terugrollen…

• Database changes kunnen alleen d.m.v. SQL script• Terugrollen door ‘spiegel/undo’ script, maar beter nog door restore

van backup

Dit gaat tegen de natuur in van de gemiddelde developer vanwege:• Weerstand tegen verandering• Ongecontroleerde verandering

Wat dan weer tot ongewenste anti-patterns leidt….


Slecht voorbeeld: ‘Entity-Attribute-Value design’• Eén van de ergste database design anti-patterns die er bestaat• Onder het mom van ‘lekker flexibel’• Mooi voorbeeld van ‘inner platform effect’ *


‘Inner platform effect’• De neiging van software architecten om een systeem zo

aanpasbaar/flexibel te maken, dat het een slechte replica van het gebruikte ontwikkelplatform wordt.


Taxonomie (indeling) van database scripts• Query scripts

Geen impact op data of database structuur, zoals eenvoudige SELECT statements.

• Object scriptsVeranderen de database, maar alleen door toevoegen/wijzigen/verwijderen van niet-data objecten zoals stored procedures, views, functies etc.

• Change scriptsVeranderen de structuur van de opgeslagen data in tabellen (ALTER TABLE, INSERT, CREATE INDEX etc.)

Alleen Object scripts en Change scripts vallen onder database changes.


‘Object Script Changes Done Right’• Veel applicaties maken gebruik van objecten in de database:

• Stored procedures• Views• Triggers

• Deze objecten zijn gewoon programmacode en moeten dus ook als zodanig behandeld worden:

• ‘leven’ in source control• Gelabeld bij een build• Deployed (uitgeleverd) tegelijk met de programmacode.• etc.


Een goed object script…• Moet drie dingen doen:


Naar Source Control…• Object scripts…

• creëren slechts objecten

• kunnen herhaald worden zonder consequenties

Eénmaal aangemaakt op disk, dan naar Source Control…

Let ook op de cijfer-prefix in de bestandsnaam…


Uitvoeringsvolgorde• Deze cijfer-prefixes zorgen voor de juiste uitvoeringsvolgorde.• Eventueel kan je een eenvoudig batch script maken dat de

bestanden in de goede volgorde uitvoert:FOR /R . %%f IN (*.sql) DO (

OSQL -E -i "%%f" -n -b -d MyDataBase

)

Met deze technieken volg je voor je object change scripts precies dezelfde werkwijze als met je applicatiecode.


‘Database Change Scripts Done Right’Wat database change scripts zo moeilijk maakt:• Veranderingen komen van twee kanten tegelijk:

1. Data changes (INSERT, UPDATE, DELETE) direct in produktie database2. Data structure changes (ALTER TABLE etc.) doorlopen staging (dev-

>test->prod) en testing.

Shortcuts leiden tot anti-patterns…


Twee belangrijke regels bij database change scripts

1. Draai het script één keer en niet vaker.Je kunt maar één keer een kolom aan een tabel toevoegen…

2. Het is onmogelijk om het script te ‘undo-en’Zodra je een kolom gedropt hebt, is-ie echt voorgoed weg…


Anti-pattern: Re-executable Change Scripts


• Het IF block test of het script al eens gedraaid is.• Lijkt leuk, maar leidt tot anti-patterns en uncontrolable change• B.V. de vorige versie van Sprocket_Name was VARCHAR(50) NULL

en was al goedgekeurd na acceptatietest.


Anti-pattern: Database Syncing• Er zijn veel ‘database-diff’ tools voorhanden• Sommigen maken zelfs change scripts aan om databases te syncen

Net als re-executable change scripts veroorzaken deze tools :• ‘kortsluiting’ in de volgordelijkheid van het change proces• ongecontroleerde veranderingen.

Grootste bezwaar:Door gebruik van deze tools wordt het testproces tussen de verschillende fasen

gepasseerd.


Following the Cardinal Rules1. Ontwikkel change script2. (Code review)3. Draai script in test omgeving4. Draai script in productie omgeving

Bij fout: herstel database en ga naar stap 1.


‘Tools of the Trade’Deze hulpmiddelen kan je gebruiken:• Change Script Library• Execution Logs• Database Versioning


Change Script LibraryAl je change scripts zouden in library moeten staan, met deze aandachtspunten:• Write–Once

Change scripts veranderen niet gedurende life cycle, net als de applicatiecode zelf.

• MetadataRegistreer:• Uniek ID• Auteur• Applicatie• Release nummer

• Geautoriseerde toegang en loggingAlleen geautoriseerde ontwikkelaars mogen change scrips

draaien


Execution LogsRegistratie van welk script wanneer gedraaid is, buiten de database.

Registreer minimaal:• Uniek ID van script• Wie het script gedraaid heeft• Wanneer het script gedraaid is• Tegen welke database het gedraaid heeft• Status na het draaien• Output log van het script


Database VersioningRegistratie van welk script wanneer gedraaid is, binnen de database; ‘metadata’ tabel.

Kan zo simpel zijn als een tabel met twee kolommen:1. Uniek ID2. Datum gedraaid

• Voordat je een script draait, eerst deze tabel checken of het al gedraaid is.

• Na het draaien deze ‘metadata’ tabel bijwerken. Dit valt te automatiseren!

Makkelijk hulpmiddel om een pre-productie database te restoren:• Backup terug (laten) zetten.• Alle scripts uit de ‘metadata’ tabel draaien.


Voorbeeld van een metadata tabel


‘Wrapping Things Up’ -> Conclusie• Databases zijn het middelpunt van je applicatie.

• Applicatiedata overleeft vaak de applicatie zelf.

• Als je bang bent om database veranderingen aan te brengen, of juist te onvoorzichtig, laat je een ‘legacy’ (erfenis) achter die niemand na jou wil/kan onderhouden.


Vragen?

Discussie?


Dank voor jullie aandacht !

Versiebeheer van database changes

Technology