Automated Testing of Database Schema Migrations
Modern applications use databases, and the majority of them are relational databases, which use schemas to impose data integrity constraints. As applications change, so do their databases. Database schemas are changed using migrations. Certain conditions can result in migrations failing in productio...
Main Author: | |
---|---|
Format: | Others |
Language: | English |
Published: |
KTH, Skolan för elektroteknik och datavetenskap (EECS)
2019
|
Subjects: | |
Online Access: | http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-255012 |
id |
ndltd-UPSALLA1-oai-DiVA.org-kth-255012 |
---|---|
record_format |
oai_dc |
collection |
NDLTD |
language |
English |
format |
Others
|
sources |
NDLTD |
topic |
Computer and Information Sciences Data- och informationsvetenskap |
spellingShingle |
Computer and Information Sciences Data- och informationsvetenskap Jonsson, Peter Automated Testing of Database Schema Migrations |
description |
Modern applications use databases, and the majority of them are relational databases, which use schemas to impose data integrity constraints. As applications change, so do their databases. Database schemas are changed using migrations. Certain conditions can result in migrations failing in production environments, leading to a broken database state and testing can be problematic without accessing production data which can be sensitive.Two migration validation methods were proposed and implemented to automatically reject invalid migrations that are not compatible with the database state. The methods were based on, and compared to, a default method that used Liquibase to structure and perform migrations. The assertion method used knowledge of what a valid state would look like to generate pre-conditions from assertions to verify that the database’s state matched expectations and that the migrations were compatible with a database’s state prior to migration. The schema method, used a copy of the production database’s schema to perform migrations on an empty database in order to test the compatibility of the old and new schemas. 108 test cases consisting of a migration and a database state were used to test all methods. Both valid and invalid test cases that were not compatible with the database’s state were used. The distribution of aborted, failed, and successful migrations were analyzed along with the automation, traceability, reliability, database interoperability, preservability, and scalability for each method.Both the assertion method and the schema method could be used to stop most of the invalid migrations without access to the production data. A combination of the assertion method and the schema method would result in only 2/108 migrations failing and could reduce the failure rate even further through using a schema to reduce complexity for uniqueness constraints and to improve support for handling data type conversions. === Moderna applikationer använder ofta relationsdatabaser som har en strikt regeluppsättning för att garantera dataintegritet. När applikationerna förändras måste även deras regeluppsättningar göra det. Omständigheter kan leda till att databasförändringar inte går att genomföra i produktionsmiljön, vilket resulterar i ett trasigt databastillstånd. Testning av förändringar kan vara problematiskt utan tillgång till produktionsdata, men detta kan vara svårt då produktionsdatan i sig kan vara känslig.Två valideringsmetoder föreslogs och implementerades för att automatiskt stoppa ogiltiga förändringar som inte är kompatibla med databasens tillstånd. Metoderna grundades i, och jämfördes med, en grundmetod som använde Liquibase för att strukturera och genomföra databasförändringar. Påståendemetoden använde kunskap kring vad som är ett giltigt tillstånd för att generera villkorssatser som verifierar att databasens tillstånd matchar förväntningarna innan förändringen genomförs. Regelmetoden använde en kopia av produktionsdatabasens regeluppsättning för att exekvera förändringen på en tom databas för att testa kompatibiliteten mellan den gamla regeluppsättningen och den nya. 108 testfall användes och bestod av förändringar samt tillstånd. Både giltiga och ogiltiga testfall som inte var kompatibla med databasens tillstånd användes. Distributionen av avbrutna, misslyckade och lyckade förändringar analyserades i faktorer som automation, spårbarhet, pålitlighet, databasinteroperabilitet, konserverbarhet samt skalbarhet för varje metod.Både påståendemetoden och regelmetoden kunde användas för att stoppa de flesta ogiltiga förändringarna utan tillgång till produktionsdata. En kombination av påståendemetoden och regelmetoden skulle resultera i att enbart 2/108 förändringar misslyckades och kunna nå ännu lägre felfrekvens genom att analysera databasschemat för att reducera komplexiteten som krävs för vissa unikhetskrav och vidare öka stödet för konvertering av datatyper. |
author |
Jonsson, Peter |
author_facet |
Jonsson, Peter |
author_sort |
Jonsson, Peter |
title |
Automated Testing of Database Schema Migrations |
title_short |
Automated Testing of Database Schema Migrations |
title_full |
Automated Testing of Database Schema Migrations |
title_fullStr |
Automated Testing of Database Schema Migrations |
title_full_unstemmed |
Automated Testing of Database Schema Migrations |
title_sort |
automated testing of database schema migrations |
publisher |
KTH, Skolan för elektroteknik och datavetenskap (EECS) |
publishDate |
2019 |
url |
http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-255012 |
work_keys_str_mv |
AT jonssonpeter automatedtestingofdatabaseschemamigrations |
_version_ |
1719224063246729216 |
spelling |
ndltd-UPSALLA1-oai-DiVA.org-kth-2550122019-07-13T04:28:53ZAutomated Testing of Database Schema MigrationsengJonsson, PeterKTH, Skolan för elektroteknik och datavetenskap (EECS)2019Computer and Information SciencesData- och informationsvetenskapModern applications use databases, and the majority of them are relational databases, which use schemas to impose data integrity constraints. As applications change, so do their databases. Database schemas are changed using migrations. Certain conditions can result in migrations failing in production environments, leading to a broken database state and testing can be problematic without accessing production data which can be sensitive.Two migration validation methods were proposed and implemented to automatically reject invalid migrations that are not compatible with the database state. The methods were based on, and compared to, a default method that used Liquibase to structure and perform migrations. The assertion method used knowledge of what a valid state would look like to generate pre-conditions from assertions to verify that the database’s state matched expectations and that the migrations were compatible with a database’s state prior to migration. The schema method, used a copy of the production database’s schema to perform migrations on an empty database in order to test the compatibility of the old and new schemas. 108 test cases consisting of a migration and a database state were used to test all methods. Both valid and invalid test cases that were not compatible with the database’s state were used. The distribution of aborted, failed, and successful migrations were analyzed along with the automation, traceability, reliability, database interoperability, preservability, and scalability for each method.Both the assertion method and the schema method could be used to stop most of the invalid migrations without access to the production data. A combination of the assertion method and the schema method would result in only 2/108 migrations failing and could reduce the failure rate even further through using a schema to reduce complexity for uniqueness constraints and to improve support for handling data type conversions. Moderna applikationer använder ofta relationsdatabaser som har en strikt regeluppsättning för att garantera dataintegritet. När applikationerna förändras måste även deras regeluppsättningar göra det. Omständigheter kan leda till att databasförändringar inte går att genomföra i produktionsmiljön, vilket resulterar i ett trasigt databastillstånd. Testning av förändringar kan vara problematiskt utan tillgång till produktionsdata, men detta kan vara svårt då produktionsdatan i sig kan vara känslig.Två valideringsmetoder föreslogs och implementerades för att automatiskt stoppa ogiltiga förändringar som inte är kompatibla med databasens tillstånd. Metoderna grundades i, och jämfördes med, en grundmetod som använde Liquibase för att strukturera och genomföra databasförändringar. Påståendemetoden använde kunskap kring vad som är ett giltigt tillstånd för att generera villkorssatser som verifierar att databasens tillstånd matchar förväntningarna innan förändringen genomförs. Regelmetoden använde en kopia av produktionsdatabasens regeluppsättning för att exekvera förändringen på en tom databas för att testa kompatibiliteten mellan den gamla regeluppsättningen och den nya. 108 testfall användes och bestod av förändringar samt tillstånd. Både giltiga och ogiltiga testfall som inte var kompatibla med databasens tillstånd användes. Distributionen av avbrutna, misslyckade och lyckade förändringar analyserades i faktorer som automation, spårbarhet, pålitlighet, databasinteroperabilitet, konserverbarhet samt skalbarhet för varje metod.Både påståendemetoden och regelmetoden kunde användas för att stoppa de flesta ogiltiga förändringarna utan tillgång till produktionsdata. En kombination av påståendemetoden och regelmetoden skulle resultera i att enbart 2/108 förändringar misslyckades och kunna nå ännu lägre felfrekvens genom att analysera databasschemat för att reducera komplexiteten som krävs för vissa unikhetskrav och vidare öka stödet för konvertering av datatyper. Student thesisinfo:eu-repo/semantics/bachelorThesistexthttp://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-255012TRITA-EECS-EX ; 2019:470application/pdfinfo:eu-repo/semantics/openAccess |