我想知道社区将如何处理这种特殊情况。
我有一个Django应用程序，我使用SQLite3数据库作为我的开发数据库在本地开发。 实时应用程序托管在Amazon Elastic Beanstalk上，并使用Amazon RDS PostgreSQL数据库进行生产。
要部署应用程序，我只需将Django应用程序推送到Elastic Beanstalk并使用<cfset wordCount = ArrayNew(2)>
<cfset arrayRow = 0>
<cfset words = "cat,dog,etc">
<cfloop list = "#words# index = "thisWord">
<cfset arrayRow ++>
<cfset wordCount[arrayRow][1] = thisWord>
<cfset wordCount[arrayRow[2] = 0>
<cfloop query = "yourQuery">
<cfif listfind(textdata, thisWord, " "> <!--- space delimited --->
<cfset wordCount[arrayRow[2] += 1>
closing tags
（从本地git存储库推送最新提交的版本）。
eb deploy配置数据库并检查环境是否如此：
settings.py和DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}
if 'RDS_DB_NAME' in os.environ:
from settings_live import *
将数据库配置更改为生产设置，如下所示：
settings_live.py这一切都运行良好，但在迁移方面出现了问题。例如：在我的开发环境中，我在应用程序的DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': os.environ['RDS_DB_NAME'],
'USER': os.environ['RDS_USERNAME'],
'PASSWORD': CREDENTIALS['RDS_PASSWORD'],
'HOST': os.environ['RDS_HOSTNAME'],
'PORT': os.environ['RDS_PORT'],
}
}
中创建了一个新模型。完成更改后，我会运行models.py和manage.py makemigrations myapp。迁移已正确应用于我的sqlite3开发数据库。没问题。
然后我提交我的更改以准备实时部署。我的manage.py migrate文件配置为忽略.gitignore以及db.sqlite3（因为这些迁移仅适用于开发数据库）。
然后我将最新的提交（不包含我的dev数据库或关联的迁移）推送到带有*/migrations的Elastic Beanstalk。我已经配置了一个.ebextentions文件（eb deploy）来在生产数据库上运行迁移，如下所示：
.ebextensions/02_commands.config以下是问题：03_makemigrations:
command: "django-admin.py makemigrations myapp1 myapp2"
leader_only: true
04_migrate:
command: "django-admin.py migrate"
leader_only: true
中makemigrations不再存在使用app/migrations的Elastic Beanstalk环境中生成的任何先前迁移，因为eb deploy部署过程会使用新的应用程序覆盖旧应用程序（仅包含空白的migrations目录）。这会导致一些意外行为，例如未在生产数据库中创建表。
我考虑过（但尚未开始实施）的一个解决方案是创建一个脚本，将迁移文件从S3存储桶复制到*/migrations，并配置02_commands.config以在此之前运行此解决方案正在运行makemigrations和migrate。然后运行另一个脚本，将新的迁移文件复制回S3存储桶。我只是想知道如果我的整个工作流程都是错误的。
答案 0 :(得分：1)
您的错误在于说迁移仅适用于开发数据库。这只是假的。迁移的全部意义在于它们的确旨在使您的开发和生产数据库保持同步。它们是您代码的一部分;它们应该与所有其余代码一起提交，部署到生产中，并在那里运行。