南方的回滚应该如何运作？

Question

让我感到困惑。让我们假设我们有一个南方迁移的Django项目。目前，生产项目版本为A，正在开发中的版本B。现在让我们假设版本B已安装到生产中：

1. 安装新代码
2. 运行./manage.py syncdb && ./manage.py migrate
3. 重新启动网络服务器并感到高兴。

下一个假设：版本B根本不起作用。它确实在开发中，但不在生产中，因此必须回滚。这是我必须遗漏的地方。我看到两种可能性：

1. 重新安装旧代码。现在，南向后迁移是合适的，但是，这是不可能的，因为旧代码不包含返回所需的所有最新迁移。
2. 我们首先回滚数据库更改，然后重新安装旧代码。但是，我们如何知道哪个迁移是版本A的最新版本？由于一个项目可以很容易地计算几十个应用程序，因此您需要弄清楚哪个迁移站属于旧版本，然后单独迁移每个应用程序，然后回滚代码并希望最好。

在这两种情况下，我都缺少重要信息，第一种情况下的迁移代码或第二种情况下的“迁移<->版本”关系。我在这里缺少什么？

PS ：是的，我知道我可以从备份恢复数据库，这就是我实际做的。我想知道整个数据库迁移理论如何适应回滚。

Answer 1

行。我认为你正在使用版本控制？在这一点上，确定'A'和'B'的组成部分至关重要。如果我们正在挥手/猜测我们引用的这个代表性的代码是'A'，而另一个模糊定义的东西我们都标记为'B' - 它不会起作用。

如果您尝试在'B'处重新安装'A'，您有两种选择： 1）签出并从头开始重建'A'（同步和迁移） 2）将'B'回滚到'A'。

1）可能无法正常工作，因为你无法负担杀死数据库中的数据以便从零开始同步它 2）涉及迁移。首先，您应该在“B”而不是“A”中找到迁移。在南方，每个应用程序的所有迁移都编号（0001,0002，0003等）。因此，假设'B'为050，'A'为0031.当您'B'签出时，运行python manage.py migrate appname 0031这将撤消您为'B'所做的所有数据库更改。然后在您的版本控制系统中，签出'A'（无论'A'只是提交，标签还是分支）

不幸的是，你不能回滚到'A'，然后说“不迁移你没有的所有东西”。这将是一个更简单的解决方案 - 但是你需要迁移系统来了解你的版本控制系统，这有点毛茸茸。

Answer 2

不确定这是否是您的情况下的选项，但是在将代码移回版本'A'之前，您是否无法在生产中运行向后迁移？通过这种方式，您的数据库会在您执行syncdb之前返回到那里的任何迁移，然后您将代码更改回版本A，然后您就可以回到开始的位置。