Version control of database changes (in Dutch). based on article 'Database Changes done Right' on www.thedailywtf.com

1. Versiebeheer van
database changes
“Database Changes done
Right” – thedailywtf.com
Arjen van Vliet
DICTU AB Team 3
Versiebeheer van database changes | 19 april 2012

2. 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
2 Dienst ICT Uitvoering

3. Software configuration management (SCM)
• Revision control
• a.k.a. version control
• a.k.a. source control
3 Dienst ICT Uitvoering

4. 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.
4 Dienst ICT Uitvoering

5. 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)
5 Dienst ICT Uitvoering

6. 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]
6 Dienst ICT Uitvoering

7. 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.
7 Dienst ICT Uitvoering

8. ‘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….
8 Dienst ICT Uitvoering

9. 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’ *
9 Dienst ICT Uitvoering

10. ‘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.
10 Dienst ICT Uitvoering

11. Taxonomie (indeling) van database scripts
• Query scripts
Geen impact op data of database structuur, zoals eenvoudige
SELECT statements.
• Object scripts
Veranderen de database, maar alleen door
toevoegen/wijzigen/verwijderen van niet-data objecten zoals
stored procedures, views, functies etc.
• Change scripts
Veranderen de structuur van de opgeslagen data in tabellen
(ALTER TABLE, INSERT, CREATE INDEX etc.)
Alleen Object scripts en Change scripts vallen onder database
changes.
11 Dienst ICT Uitvoering

12. ‘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.
12 Dienst ICT Uitvoering

13. Een goed object script…
• Moet drie dingen doen:
13 Dienst ICT Uitvoering

14. 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…
14 Dienst ICT Uitvoering

15. 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.
15 Dienst ICT Uitvoering

16. ‘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 database
2. Data structure changes (ALTER TABLE etc.) doorlopen staging (dev-
>test->prod) en testing.
Shortcuts leiden tot anti-patterns…
16 Dienst ICT Uitvoering

17. 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…
17 Dienst ICT Uitvoering

18. Anti-pattern: Re-executable Change Scripts
18 Dienst ICT Uitvoering

19. • 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.
19 Dienst ICT Uitvoering

20. 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.
20 Dienst ICT Uitvoering

21. Following the Cardinal Rules
1. Ontwikkel change script
2. (Code review)
3. Draai script in test omgeving
4. Draai script in productie omgeving
Bij fout: herstel database en ga naar
stap 1.
21 Dienst ICT Uitvoering

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

23. Change Script Library
Al 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.
• Metadata
Registreer:
• Uniek ID
• Auteur
• Applicatie
• Release nummer
• Geautoriseerde toegang en logging
Alleen geautoriseerde ontwikkelaars mogen change scrips
draaien
23 Dienst ICT Uitvoering

24. Execution Logs
Registratie 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
24 Dienst ICT Uitvoering

25. Database Versioning
Registratie van welk script wanneer gedraaid is, binnen de database;
‘metadata’ tabel.
Kan zo simpel zijn als een tabel met twee kolommen:
1. Uniek ID
2. 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.
25 Dienst ICT Uitvoering

26. Voorbeeld van een metadata tabel
26 Dienst ICT Uitvoering

27. ‘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.
27 Dienst ICT Uitvoering

28. Vragen?
Discussie?
28 Dienst ICT Uitvoering

29. Dank voor jullie aandacht !
29 Dienst ICT Uitvoering