Migrations Django: db de développement sqlite3, Amazon Elastic Beanstalk et base de données en direct d'Amazon RDS postgresql

Question

Je me demande comment la communauté pourrait gérer ce scénario particulier.

J'ai une application Django que je développe localement en utilisant une base de données SQLite3 comme base de développement. L'application en cours est hébergée sur Amazon Elastic Beanstalk et utilise une base de données Amazon RDS PostgreSQL pour la production.

Pour déployer l'application, il suffit de pousser l'application Django vers Elastic Beanstalk avec eb deploy (ce qui pousse la dernière version validée depuis le dépôt git local).

settings.py configure la base de données et vérifie si l'environnement est de vivre comme ceci:

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 * 

et settings_live.py modifie la configuration de base de données sur les paramètres de production comme ceci:

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

Tout cela fonctionne très bien, mais des problèmes surgissent quand il s'agit de migrations. Par exemple: dans mon environnement de développement, je crée un nouveau modèle dans une application models.py. Après avoir fait le changement, je cours manage.py makemigrations myapp et manage.py migrate. Les migrations sont correctement appliquées à ma base de données de développement sqlite3. Pas de problème. Puis j'engage mes modifications en préparation pour le déploiement en direct. Mon fichier .gitignore est configuré pour ignorer db.sqlite3 ainsi que */migrations (puisque ces migrations sont uniquement applicables à la base de données de développement).

Ensuite, je pousse mon dernier commit (qui ne contient pas ma base de données dev ou les migrations associées) à Elastic Beanstalk avec eb deploy. J'ai configuré un fichier .ebextentions (.ebextensions/02_commands.config) pour exécuter des migrations sur la base de données de production comme ceci:

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

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

Voici le problème: les migrations antérieures qui ont été générés dans l'environnement Elastic Beanstalk avec makemigrations n'existent plus dans app/migrations depuis le processus de déploiement eb deploy remplace l'ancienne application par la nouvelle (qui contient uniquement un répertoire vide migrations). Cela conduit à un comportement inattendu tel que des tables n'étant pas créées dans la base de données de production.

Une solution que j'ai pris en compte (mais ai même pas commencé à mettre en œuvre) est de créer un script que les fichiers de migration de copies d'un seau S3 pour */migrations et configurer 02_commands.config pour exécuter avant de lancer makemigrations et migrate. Ensuite, exécutez un autre script qui copie les nouveaux fichiers de migrations dans le compartiment S3. Je me demande simplement si tout mon flux de travail est mauvais si cela est arrivé à cela.

Answer 1

Votre erreur est de dire que les migrations ne sont applicables qu'à la base de données de développement. C'est juste faux. L'intérêt des migrations est qu'elles sont exactement destinées à synchroniser vos bases de données de développement et de production. Ils font partie de votre code; ils devraient être commis avec tout le reste du code, déployés en production, et courir là.