附录 D 测试数据库迁移
Django-migrations
及前身 South 已经出现好多年了,所以一般没必要测试数据库迁移。但有时我们会使用一种危险的迁移,即引入新的数据完整性越苏。
在大型项目中,如果有敏感数据,在生产数据中执行迁移之前,你可能想先在一个安全的环境中测试,增加一些自信。
测试迁移的另一个常见原因是测速——执行迁移时经常要把网站下线,而且如果数据集比较大,用时并不短。所以最好提前知道迁移要执行多长时间。
D.1 尝试部署到过渡服务器
数据库中某些现有的数据违反了完整性越苏条件,所以当尝试应用约束条件时,数据库表达了不满。
为了处理这种问题,需要执行“数据迁移”。首先,要在本地搭建一个测试环境。
D.2 在本地执行一个用于测试的迁移
使用线上数据库的副本测试迁移。
测试时使用真实数据一定要小心。例如,数据中可能有客户的真实电子邮件地址。
D.2.1 输入有问题的数据
在线上网站中新建一个清单,输入一些重复的待办事项
D.2.2 从线上网站中复制测试数据
从线上网站中复制数据库:
D.2.3 确认的确有问题
现在,本地还有一个未执行迁移的数据库,而且数据库中有一些问题数据。如果尝试执行 migrate
命令,会看到错误。
D.3 插入一个数据迁移
重新创建以前的迁移
使用 makemigrations
重新创建以前的迁移,确保这是第 6 个迁移,而且还明确依赖于 0005,即那个数据迁移。
D.4 一起测试这两个迁移
现在可以在线上数据中测试了:
还要重启服务器中的 Gunicorn 服务:
sudo restart gunicorn-watch0.top
然后可以在过渡网站中运行功能测试。
D.5 小结
这个练习的主要目的是编写一个数据迁移,在一些真实的数据中测试。当然,这只是测试迁移的千万种方式之一。你还可以编写自动化测试,比较运行迁移前后数据库中的内容,确认数据还在。也可以为数据迁移中的辅助函数单独编写单元测试。你可以再多花点时间统计迁移所用的时间,然后实验多种提速的方法,例如,把迁移的步骤分得更细或更笼统。
但这种需求很少见。根据作者的经验,使用的迁移,99% 都不需要测试。
关于测试数据库迁移
小心引入约束的迁移
99% 的迁移都没问题,但是如果迁移为现有的列引入了新的约束条件,一定要小心。
测试迁移的执行速度
一旦项目变大,就应该考虑测试迁移所用的时间。执行数据库迁移时往往要下线网站,因为修改模式可能要锁定数据表(取决于使用的数据库种类),直到操作完成为止。所以最好在过渡网站中测试迁移要用多长时间。
使用生产数据的副本时要格外小心
为了测试迁移,要在过渡网站的数据库中填充与生产数据等量的数据。如果直接转储生产数据库导入过渡网站的数据库中,一定要十分小心,因为生产数据中包含真实客户的详细信息。
Last updated
Was this helpful?