Django 在弹性Beanstalk上部署后运行manage.py命令的正确方法？

我正在将Django应用程序部署到EB—这是我的第一次EB部署—我对事情的顺序感到困惑

我的容器命令如下：

container_commands:
   01_migrate:
    command: "django-admin.py migrate"
    leader_only: true
   02_collectstatic:
     command: "django-admin.py collectstatic --noinput"
     leader_only: true

然而，我注意到，每次部署时，这些容器命令都在我的旧代码库上运行。假设我的当前代码是

app-v1.zip

。我更新了我的

models.py

，并创建了一个迁移。然后我部署了

eb

，它创建了

app-v2.zip

。

migrate

命令在EB环境中运行，但在

app-v2.zip

解包到

/var/app/current

之前，在旧代码库（

app-v1.zip

）上运行，因此不会应用我的迁移

如果我随后运行另一个

eb deploy

，它将创建

app-v3.zip

，但将在

app-v2.zip

中的代码上运行

migrate

。因此，它是可行的，但这意味着每当我想要更改数据模型或静态文件时，我必须运行两次

eb deploy

（同样的问题也适用于

collectstatic

）

这里有更多的解释和解决方法，但是所有的“deploy Django to EB”教程都像我使用

container\u命令所做的那样

正确的方法是什么？
您让我担心，但我已经确认
eb deploy
确实使用新版本的代码运行命令。在实际发布到服务器之前，它会在暂存区域执行此操作，但在使用正确的版本时会执行此操作

您可以在部署后执行
eb logs-a
，并查找
eb activity.log
，以查看所有命令的执行情况以及正确的迁移情况

至于流，我不希望将collecstatics作为EB流的一部分调用，因为我使用基于gulp的流将代码直接发布到S3（和CloudFront）中。因此，我只是将迁移作为部署的一部分运行（加上我的应用程序特有的其他内容）：

一切正常。
你确定吗？我已经使用电子商务一年了，我从未见过你描述的行为。该博客讨论了这样一个事实，即命令在部署之前在临时区域上运行，但是临时区域应该有新的存档。你能详细说明你认为这是怎么发生的吗？
 01_migrate:
    command: "django-admin.py migrate --noinput"
    leader_only: true