Mise en Production : migrations et MAJ

Bonjour,

Hier quelques mésaventures de mise en prod ahah. (NodeNotFound).
J'ai dû m'amuser à delete les dossiers pycache de mes dossiers de migrations, ainsi que les migrations elles même. Puis j'ai refait un makemigrations directement sur mon serveur de prod. Apparemment le contenu de mes fichiers de migration sur serveur et en local restent identiques car après le git pull je n'ai eu de changements d'appliqués.

Est-ce que c'est bien d'avoir fait ça ? Mais honnêtement c'est la meilleure solution que j'ai trouvé.

Du coup :

Est-ce quil est bien de faire un makemigrations sur le serveur de prod ? Ou toujours faire un makemigrations en local puis faire un git pull ?

Pour les MAJ des librairies.

Question sur la MAJ des lib, comme wagtail ou Django. Vous procédez comment sur projet en prod ? d'abord la maj en local ? puis si ok un upgrade sur le serveur ?

requirements

Pour le fichier requirements.txt. Il est bon de toujours le mettre à jour en local du coup ? Il sera actualisé en prod avec le git pull.
Je n'ai pas osé tester. Mais si j'ai mis à jour le requirements.txt en local, que je fais un git pull en prod. Si je fais un pip install -r, ça va mettre à jour mes libs ? ou c'est déconseillé ?

Désolé, je me pose pas mal de questions sur les projets en prod je commence à m'y intéresser vraiment... :) Et je suisi vraiment pas top c'est assez nouveau je ne l'ai fait que rarement depuis que j'ai commencé le dev.

Merci d'avance ! :)

Salut Gab,

Au sujet des mises à jours de librairies en prod, il m'est arrivé une petite histoire il y a deux semaines.

J'avais fait l'erreur de lancer une mise à jour de toutes les dépendances de mon site perso en faisant pipenv update, directement sur le serveur sans me poser de question. Et là, boom, le site HS. En fait ce qu'il s'est passé c'est que la librairie Django reCAPTCHA avait apporté des modifications dans le package, notamment au niveau du nom de l'application à renseigner dans les settings, ce n'est plus captcha mais django_recaptcha.

J'ai effectué le débugage en local :

• Mise à jours des dépendances

• Modification du fichier settings et des imports

• Pousser le tout sur GitHub

Ensuite en prod :

• git restore Pipfile.lock pour restaurer le fichier dans son état précédent (fichier qui contient les infos sur les dépendances)

• et enfin git pull

Du coup je pense que c'est plus sûr d'envisager de faire les mises à jours en local. Et peut-être même faire du cas par cas pour les différents packages, se renseigner d'abord sur les dernières modifications qui ont été apportées, voir si elles ne vont pas impacter le bon fonctionnement du projet.

Re ! Merci Cam ! :)

Par contre du coup j'ai mes fichiers de migrations qui sont différents en local et en prod

# Prod
class Migration(migrations.Migration):

    initial = True

    dependencies = [
        ("wagtailcore", "0092_query_searchpromotion_querydailyhits"),
        ("wagtailimages", "0025_alter_image_file_alter_rendition_file"),
    ]

# Local
class Migration(migrations.Migration):

    initial = True

    dependencies = [
        ('wagtailcore', '0092_merge_20240207_2332'),
        ('wagtailimages', '0025_alter_image_file_alter_rendition_file'),
    ]

C'est grave ? lol

EDIT

Au final j'ai exclu les fichiers de migrations avec le gitignore.
Et je fais le makemigrations sur le serveur de prod.

C'est juste une histoire de dépendances qui change. Donc je ferais makemigrations en local avant dans tous les cas pour tester, et je ferais un makemigrations sur le serveur après a chaque fois

Ce n'est pas le top mais pas le choix c'est wagtail qui m'embete lol

Salut Gab,

Normalement, il est conseillé de créer tes migrations en local et de les appliquer telles quelles en production. Ça permet d'assurer la cohérence entre tous tes environnements et de minimiser les risques de bugs en prod.

En voyant que tu as des fichiers de migrations qui diffèrent entre ton environnement local et ton serveur de prod, ça indique qu'il y a un désynchronisme. Cela pourrait te jouer des tours à l'avenir surtout si tu as une base de données qui évolue et que d'autres développeurs travaillent sur le projet.

Voici quelques pratiques recommandées :

1. Créer les migrations en local : Tu fais bien de penser à les créer en local où tu peux tester et vérifier que tout se passe comme prévu.

2. Utiliser le versionnement pour les migrations : En général, il n'est pas recommandé d'exclure les fichiers de migration de ton système de contrôle de version (sauf cas exceptionnels). Ils font partie de l'historique de ton schéma de base de données et les avoir versionnés t'aidera à maintenir la synchronisation entre les environnements.

3. Tester les migrations avant de les appliquer en prod : Il est important de ne pas juste faire un makemigrations en prod. Teste-les d'abord en local, applique-les sur une copie de la base de données de prod si possible, et une fois que tout est ok, pousse les fichiers de migration générés en prod et utilise migrate.

est ce que ça répond à ta question ?

Pour le dernier point oui je test d'abord en local. Mais je n'ai pas le choix avec mon projet wagtail de séparer les deux et d'exclure les fichiers de migration. J'ai vu que ça pouvait arriver (rarement). Donc pour ce projet jen 'ai pas le choix mais je test bien avant en local dans tous les cas.

Du coup c'est un peu n'importe quoi d'exclure les fichiers de migration ? Je ne sais pas comment faire autrement perso sur ce projet.
En fait je pense que je peux le faire tant que ça reste du perso. Mais si c'est collaboratif ce n'est plus possible du coup ? :s

Merci PA !

ok merci !