Je dois bient=C3=B4t d=C3=A9marrer le d=C3=A9veloppement d'une application =
"maison" avec
Django (et Postgres pour la base de donn=C3=A9es).
J'imagine livrer plusieurs versions successives de l'application avec entre
deux versions principalement des modifications du mod=C3=A8le et du code
applicatif mais peut =C3=AAtre aussi l'ajout ou la mise =C3=A0 jour de modu=
les Django.
L'application g=C3=A8re relativement peu de donn=C3=A9es (des donn=C3=A9es =
de
configuration) et pour donner un ordre de grandeur, la perte de toutes les
donn=C3=A9es saisies pendant une saisie me semble acceptable.
Avez-vous des conseils pour que les changements de version s'op=C3=A8rent e=
n
douceur ?
Comment op=C3=A8rent ceux qui font du CI/CD au petit d=C3=A9jeuner ?
<div dir=3D"ltr"><div>Bonjour,</div><div><br></div><div>Je dois bient=C3=B4=
t d=C3=A9marrer le d=C3=A9veloppement d'une application "maison&qu=
ot; avec Django (et Postgres pour la base de donn=C3=A9es).</div><div><br><=
/div><div>J'imagine livrer plusieurs versions successives de l'appl=
ication avec entre deux versions principalement des modifications du mod=C3=
=A8le et du code applicatif mais peut =C3=AAtre aussi l'ajout ou la mis=
e =C3=A0 jour de modules Django.</div><div><br></div><div>L'application=
g=C3=A8re relativement peu de donn=C3=A9es (des donn=C3=A9es de configurat=
ion) et pour donner un ordre de grandeur, la perte de toutes les donn=C3=A9=
es saisies pendant une saisie me semble acceptable.<br></div><div><br></div=
><div>Avez-vous des conseils pour que les changements de version s'op=
=C3=A8rent en douceur ?</div><div>Comment op=C3=A8rent ceux qui font du CI/=
CD au petit d=C3=A9jeuner ?</div><div><br></div><div>Slts<br></div><div><br=
></div></div>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel Caillibaud
Le 12/02/19 à 14:34, Olivier 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 f aut 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 t es fichiers - tu redémarres avec la nouvelle version Mais souvent on coupe pas et ça se fait au démarrage de l'applica tion : - 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 appl iqué - 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-bloqua nts 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 p ose 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…
Le 12/02/19 à 14:34, Olivier <oza.4h07@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 f aut 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 t es fichiers
- tu redémarres avec la nouvelle version
Mais souvent on coupe pas et ça se fait au démarrage de l'applica tion :
- 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 appl iqué
- 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-bloqua nts
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 p ose 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…
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 f aut 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 t es fichiers - tu redémarres avec la nouvelle version Mais souvent on coupe pas et ça se fait au démarrage de l'applica tion : - 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 appl iqué - 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-bloqua nts 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 p ose 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…
