通过编程检查是否有需要部署的django South迁移

Question

我的部署策略如下所示（使用 Fabric）：

1. 创建一个新的 virtualenv
2. 在新的 virtualenv 中部署新代码
3. 显示维护页面
4. 将当前数据库复制到新数据库
5. 迁移新数据库
6. 点 新代码到新数据库
7. 符号链接 当前 virtualenv 到新 venv 重新
8. 启动服务
9. 删除维护页面

我想快速迭代。现在，大多数代码更改不包含迁移。此外，数据库正在增长，因此每次部署（大部分是小）更改时复制数据库都会产生大量开销。为了避免复制数据库，我想检查是否有需要部署的迁移（在步骤 4 之前）。如果没有迁移，我可以直接从步骤 2 到步骤 7。如果有，我将遵循所有步骤。为此，我需要以编程方式检查是否存在需要部署的迁移。我该怎么做？

Answer 1

在部署新代码的步骤 2 中，您可以部署一个脚本，该脚本在服务器上运行时将检测是否有新的迁移。

示例代码如下：

# copied mostly from south.management.commands.migrate
from south import migration
from south.models import MigrationHistory

apps  = list(migration.all_migrations())

applied_migrations = MigrationHistory.objects.filter(app_name__in=[app.app_label() for app in apps])
applied_migrations = ['%s.%s' % (mi.app_name,mi.migration) for mi in applied_migrations]

num_new_migrations = 0
for app in apps:
    for migration in app:
        if migration.app_label() + "." + migration.name() not in applied_migrations:
            num_new_migrations = num_new_migrations + 1

return num_new_migrations

如果将上述代码封装在脚本中，您的 Fabric 部署脚本可以使用 run 操作来获取新迁移的数量。

如果返回零，则您可以跳过与复制数据库相关的步骤。
   

Answer 2

 ./manage.py migrate --all --merge --list | grep "( )"

将告诉您并展示哪些迁移。如果您想要返回代码或计数，请使用 wc。

这样做的优点是不需要像接受的答案那样复制和粘贴代码（违反 DRY），而且如果内部南 API 发生更改，您的代码仍然可以工作。

更新：

Django 1.7 将输出更改为使用括号而不是括号，Django 1.8 引入了 showmigration 命令：

./manage.py showmigrations --list | grep '[ ]'

Answer 3

dalore 的答案已更新为 Django 1.7+

./manage.py migrate  --list | grep "\[ ]"

如果您只想要计数，那么：

./manage.py migrate  --list | grep "\[ ]" | wc -l

Answer 4

为什么要移动数据库？迁移的重点是将开发中所做的更改应用到生产数据库中。

您的步骤实际上应该是：

1. 创建一个新的 virtualenv
2. 在新的 virtualenv 中部署新代码
3. 显示维护页面
4. 将新的 db
5. 符号链接当前的 virtualenv 迁移到新的 venv
6. 重新启动服务
7. 删除维护页面

如果没有实际的新迁移，迁移步骤不会花费那么长时间运行。它只会运行每个应用程序，并表示它已经是最新的。

如果您要复制数据库以进行备份，那么无论如何都应该在 cron 或其他东西上运行，而不是作为部署的一部分。

实际上，我也对每次创建新的 virtualenv 感到困惑。规范化（读：最典型）部署是：

1. 部署新代码
2. 迁移数据库
3. 重新启动服务

如果您想在维护页面中添加回内容，您可以，但该过程总共只需要一两分钟。