Question

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

创建一个新的virtualenv
在新的virtualenv中部署新代码
显示维护页面
将当前数据库复制到新数据库
迁移新数据库
将新代码指向新数据库
符号链接当前virtualenv到新的venv
重启服务
删除维护页面

我想快速迭代。现在，大多数代码更改都不包含迁移。此外，db正在增长，因此每次部署（通常很小）更改时，通过复制数据库会产生很多开销。为避免复制数据库，我想检查是否存在需要部署的迁移（在步骤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

如果将上述代码包装在脚本中，则结构部署脚本可以使用运行操作来获取新迁移的数量。

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

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

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

您的步骤应该是：

创建一个新的virtualenv
在新的virtualenv中部署新代码
显示维护页面
迁移新数据库
符号链接当前virtualenv到新的venv
重启服务
删除维护页面

如果没有实际的新迁移要运行，迁移步骤不需要那么长时间。它只是通过每个应用程序说它已经是最新的。

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

实际上，我每次都在创造一个新的virtualenv时感到困惑。规范化（读取：最典型）部署是：

部署新代码
迁移db
重启服务

如果你想在维护页面中添加回来，你可以，但这个过程只需要一两分钟。

Answer 4

dalore的答案更新为Django 1.7 +

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

如果您只想要计数：

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

以编程方式检查是否存在需要部署的django南迁移

4 个答案: