Le 12/02/19 à 14:34, Olivier <oza.4...@gmail.com> a écrit : > Avez-vous des conseils pour que les changements de version s'opèrent en > douceur ?
Si tu prévois des évolutions du schéma de données, il faut impérativement gérer des scripts d'updates. Tu peux faire - tu coupes - tu passe ton script de mise à jour de la structure et déploie tes fichiers - tu redémarres avec la nouvelle version Mais souvent on coupe pas et ça se fait au démarrage de l'application : - déployer les nouveaux fichiers de l'application - lancer un reload qui devra gérer les étapes suivantes : - je regarde dans la base de données quelle est le dernier update appliqué - je regarde dans le dossier d'updates si y'en a un plus récent à appliquer - si oui je le lance et quand il a fini je repars au début - sinon je démarre vraiment l'application et je peux commencer à répondre aux requêtes Pour limiter les coupures sur des applis avec de grosses bases, on peut gérer la notion de mises à jour non bloquantes (par ex un update qui va ajouter un champ calculé, mais dont l'absence ne plante pas l'appli), tu peux gérer cet aspect bloquant / non bloquant dans les étapes décrites ci-dessus (si tous les updates qui restent à appliquer sont non-bloquants tu peux démarrer quand même et les lancer en tâche de fond, mais en séquentiel). Pour la mise à jour sans modif de schéma, en général c'est rsync puis redémarrage du serveur applicatif. Je suppose que django ne relit les fichiers qu'au démarrage ou à leur premier appel et que ça pose pas de pb si le rsync dure qq secondes. -- Daniel Moi, je ne me pose jamais aucune question. Je me demande d'ailleurs bien pourquoi…