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

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 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 op

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 3 Software configuration management (SCM) Revision control a.k.a. version control a.k.a. source control

Versiebeheer van database changes | 19 april 2012 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.computerprogrammacomputerbestanden Het meest gebruikt bij de ontwikkeling van software.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.timestamp Wijzigingen kunnen vergeleken worden, hersteld en soms samengevoegd.

Versiebeheer van database changes | 19 april 2012 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)

Versiebeheer van database changes | 19 april 2012 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]

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 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….

Versiebeheer van database changes | 19 april 2012 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’ *

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 13 Een goed object script… Moet drie dingen doen:

Versiebeheer van database changes | 19 april 2012 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…

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 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…

Versiebeheer van database changes | 19 april 2012 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…

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 18 Anti-pattern: Re-executable Change Scripts

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 22 ‘Tools of the Trade’ Deze hulpmiddelen kan je gebruiken: Change Script Library Execution Logs Database Versioning

Versiebeheer van database changes | 19 april 2012 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

Versiebeheer van database changes | 19 april 2012 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

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 26 Voorbeeld van een metadata tabel

Versiebeheer van database changes | 19 april 2012 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.

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 28 Vragen? Discussie?

Versiebeheer van database changes | 19 april 2012 Dienst ICT Uitvoering 29 Dank voor jullie aandacht !