Background Image
Table of Contents Table of Contents
Previous Page  459 / 478 Next Page
Information
Show Menu
Previous Page 459 / 478 Next Page
Page Background

Conclusions

This exercise was primarily aimed at building a data migration and testing it against

some real data. Inevitably, this is only a drop in the ocean of the possible testing you

could do for a migration. You could imagine building automated tests to check that all

your data was preserved, comparing the database contents before and after. You could

write individual unit tests for the helper functions in a data migration. You could spend

more time measuring the time taken for migrations, and experiment with ways to speed

it up by, eg, breaking up migrations into more or fewer component steps.

Remember that this should be a relatively rare case. In my experience, I haven’t felt the

need to test 99% of the migrations I’ve worked on. But, should you ever feel the need

on your project, I hope you’ve found a few pointers here to get started with.

On Testing Database Migrations

Be wary of migrations which introduce constraints

99% of migrations happen without a hitch, but be wary of any situations, like this

one, where you are introducing a new constraint on columns that already exist.

Test migrations for speed

Once you have a larger project, you should think about testing how long your

migrations are going to take. Database migrations typically involve downtime, as,

depending on your database, the schema update operation may lock the table it’s

working on until it completes. It’s a good idea to use your staging site to find out

how long a migration will take.

Be extremely careful if using a dump of production data

In order to do so, you’ll want fill your staging site’s database with an amount of data

that’s commensurate to the size of your production data. Explaining how to do that

is outside of the scope of this book, but I will say this: if you’re tempted to just take

a dump of your production database and load it into staging, be

very

careful. Pro‐

duction data contains real customer details, and I’ve personally been responsible

for accidentally sending out a few hundred incorrect invoices after an automated

process on my staging server started processing the copied production data I’d just

loaded into it. Not a fun afternoon.

Conclusions

|

431