Django Migrationen: SQLite3 Entwicklung db, Amazon Elastic Beanstalk und Amazon RDS postgresql Live-Datenbank

Question

Ich frage mich, wie die Gemeinschaft würde mit diesem bestimmten Szenario umgehen.

Ich habe eine Django-App, die ich lokal mit einer SQLite3-Datenbank als meine Entwicklungsdatenbank entwickeln. Die Live-Anwendung wird auf Amazon Elastic Beanstalk gehostet und verwendet eine Amazon RDS PostgreSQL-Datenbank für die Produktion.

Zum Bereitstellen der App, ich einfach Push die Django App auf Elastic Beanstalk mit eb deploy (die die neueste festgeschriebene Version aus dem lokalen Git-Repository schiebt).

settings.py konfiguriert die Datenbank und prüft, ob die Umgebung so leben, wie ist:

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 * 

und settings_live.py die Datenbankkonfiguration Änderungen an den Produktionseinstellungen wie folgt:,

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'], 
    } 
} 

Das alles funktioniert gut Aber es gibt Probleme, wenn es um Migrationen geht. Zum Beispiel: In meiner Entwicklungsumgebung erstelle ich ein neues Modell in der App models.py. Nachdem ich die Änderung vorgenommen habe, starte ich manage.py makemigrations myapp und manage.py migrate. Die Migrationen werden ordnungsgemäß auf meine sqlite3-Entwicklungsdatenbank angewendet. Keine Probleme.

Dann beginne ich meine Änderungen in Vorbereitung auf die Live-Bereitstellung. Meine .gitignore Datei ist konfiguriert, um db.sqlite3 sowie */migrations zu ignorieren (da diese Migrationen nur für die Entwicklungsdatenbank gelten).

Dann drücke ich meine neueste Commit (die nicht meine Dev-Datenbank oder zugeordnete Migrationen enthält) auf Elastic Beanstalk mit eb deploy. Ich habe eine .ebextentions Datei (.ebextensions/02_commands.config) konfiguriert wie so Migrationen auf die Produktionsdatenbank zu laufen:

03_makemigrations: 
    command: "django-admin.py makemigrations myapp1 myapp2" 
    leader_only: true 

04_migrate: 
    command: "django-admin.py migrate" 
    leader_only: true 

Hier ist das Problem: alle bisherigen Migrationen, die mit makemigrations nicht mehr in app/migrations gibt es in der Elastic Beanstalk-Umgebung erzeugt wurden seit Der eb deploy-Bereitstellungsprozess überschreibt die alte App mit der neuen App (die nur ein leeres migrations-Verzeichnis enthält). Dies führt zu unerwartetem Verhalten, z. B. wenn Tabellen nicht in der Produktionsdatenbank erstellt werden.

Eine Lösung, die ich in Betracht gezogen habe (aber noch nicht einmal zu implementieren begonnen) ist ein Skript zu erstellen, dass Kopien der Migration von Dateien von einem S3 Eimer */migrations und konfigurieren 02_commands.config dies vor laufen makemigrations und migrate zu laufen. Führen Sie anschließend ein anderes Skript aus, das die neuen Migrationsdateien zurück in den S3-Bucket kopiert. Ich frage mich nur, ob mein gesamter Workflow falsch ist, wenn es dazu gekommen ist.

Answer 1

Ihr Fehler besteht darin zu sagen, dass die Migrationen nur für die Entwicklungsdatenbank gelten. Das ist nur falsch. Der entscheidende Punkt bei Migrationen ist, dass sie genau dazu dienen, Ihre Entwicklungs- und Produktionsdatenbanken synchron zu halten. Sie sind Teil Ihres Codes; Sie sollten zusammen mit dem gesamten restlichen Code ausgeführt, in der Produktion bereitgestellt und dort ausgeführt werden.