- Après la mise à jour de sa BD consécutive à la MÀJ de 1 à 2 de ton soft, l'utilisateur remarque que sa fonction préférée qui marchait très bien dans 1 ne marche pas dans 2. Il ne peut se permettre d'attendre une MÀJ et souhaite retourner à la version 1. Comment fait-il?
Effectivement, il ne peut pas faire de retour arrière. Pour le moment il est censé attendre une mise à jour corrective. Mais je pourrais le prévoir, d'ailleurs j'ai prévu plusieurs paramètres à mon script d'upgrade
--install (pour l'installation initiale)
--updade (pour la montée de version)
--force-update (pour forcer la réinstallation de la même version, voire d'une version antérieure. Il suffira de fournir en paramètre le chemin de la sauvegarde de la version n-1)
- Les système en prod peuvent-ils avoir un downtime?
Arf.. j'avais pas pensé aux scénarios utilisateurs... si le système se met en mode maintenance pendant un scénario ça risque de merder. Donc ça c'est chiant.
Je pourrais prévoir que l'update se fasse entre 2 scénarios. Une petite boucle dans mon script toutes les 10 secondes devrait faire l'affaire. Faut tester...
Les contraintes:
Quels sont les systèmes de BD supportés?
Pour le moment c'est du mysql.
L'upgrade de BD se fait côté soft ou bien avec un script SQL/sh?
L'upgrade se fait via script sh/sql. Il est géré par un cron quotidien.
Qui fait l'upgrade (admin, utilisateur inexpérimenté?)
C'est un cron. L'upgrade est géré par le système tel qu'expliqué précédemment.
Ton nouveau schéma est-il un sur ensemble strict de l'ancien (cas facile)?
Je ne suis pas sur de comprendre cette remarque.
Le fichier sql d'update se charge de créer des tables (ou d'en supprimer), de modifier des structures. et je n'ai pas utilisé de clé étrangères (pour le cas des violation de clé, etc)
Que doit-il se passer si la version 1 de ton soft tourne sur une BD avec le schéma de la version 2?
Je n'ai pas géré ce cas là car je pars du principe que toute nouvelle livraison contient forcément un Core, un Manager, Un Voice. Et elles doivent s'installer simultanément.
C'est super, tes remarques sont très pertinentes. Je me rends compte de tous les cas que j'ai pu oublié dans ce contexte de système décentralisé.
Ce que je peux te dire c'est donc que :
Je développe mon projet sur mon ordi. Je le teste dans une VM (c'est ma qualif). Et je le teste chez moi ( c'est ma prod).
Une fois que les corrections/évolutions me semblent intéressantes et stabilisées, je met en ligne les livrables.
Aucun des scénarios utilisateurs ne pourront tourner au moment de la montée de version. Sauf si je gère une mise en pause de ces scénarios durant l'installation. raaa j'avais pas pensé à ça !!! Donc mon installation automatique ne pourra pas marcher. Sauf si j'impose à l'utilisateur une période de 10 minutes de mise en maintenance quotidienne du système.
Et il faut forcément que le système (Core, Manager, Voice) se mette en mode maintenance en même temps pour se mettre à jour afin qu'il n'y ait pas de requête sur la base mysql.
J'aimerai bien utiliser un système en cluster avec un système de fichier distribué, pour que le service mysql puisse démarrer sur n'importe quel noeud. Tous les noeuds se mettraient à jour les uns après les autres et redémarreraient. C'est chaud, faisable mais dangereux. Quoique terriblement GEEK.
Voilà merci pour ton aide. Ca a été très instructif !
[^] # Re: Il n'y pas de remède miracle
Posté par popof . En réponse au message Méthode pour gérer les montées de version de structure de base de données. Évalué à 0.
Whaou! ça c'est du conseil !
Les objectifs
- Après la mise à jour de sa BD consécutive à la MÀJ de 1 à 2 de ton soft, l'utilisateur remarque que sa fonction préférée qui marchait très bien dans 1 ne marche pas dans 2. Il ne peut se permettre d'attendre une MÀJ et souhaite retourner à la version 1. Comment fait-il?
Effectivement, il ne peut pas faire de retour arrière. Pour le moment il est censé attendre une mise à jour corrective. Mais je pourrais le prévoir, d'ailleurs j'ai prévu plusieurs paramètres à mon script d'upgrade
--install (pour l'installation initiale)
--updade (pour la montée de version)
--force-update (pour forcer la réinstallation de la même version, voire d'une version antérieure. Il suffira de fournir en paramètre le chemin de la sauvegarde de la version n-1)
- Les système en prod peuvent-ils avoir un downtime?
Arf.. j'avais pas pensé aux scénarios utilisateurs... si le système se met en mode maintenance pendant un scénario ça risque de merder. Donc ça c'est chiant.
Je pourrais prévoir que l'update se fasse entre 2 scénarios. Une petite boucle dans mon script toutes les 10 secondes devrait faire l'affaire. Faut tester...
Les contraintes:
Quels sont les systèmes de BD supportés?
Pour le moment c'est du mysql.
L'upgrade de BD se fait côté soft ou bien avec un script SQL/sh?
L'upgrade se fait via script sh/sql. Il est géré par un cron quotidien.
Qui fait l'upgrade (admin, utilisateur inexpérimenté?)
C'est un cron. L'upgrade est géré par le système tel qu'expliqué précédemment.
Ton nouveau schéma est-il un sur ensemble strict de l'ancien (cas facile)?
Je ne suis pas sur de comprendre cette remarque.
Le fichier sql d'update se charge de créer des tables (ou d'en supprimer), de modifier des structures. et je n'ai pas utilisé de clé étrangères (pour le cas des violation de clé, etc)
Que doit-il se passer si la version 1 de ton soft tourne sur une BD avec le schéma de la version 2?
Je n'ai pas géré ce cas là car je pars du principe que toute nouvelle livraison contient forcément un Core, un Manager, Un Voice. Et elles doivent s'installer simultanément.
C'est super, tes remarques sont très pertinentes. Je me rends compte de tous les cas que j'ai pu oublié dans ce contexte de système décentralisé.
Ce que je peux te dire c'est donc que :
Je développe mon projet sur mon ordi. Je le teste dans une VM (c'est ma qualif). Et je le teste chez moi ( c'est ma prod).
Une fois que les corrections/évolutions me semblent intéressantes et stabilisées, je met en ligne les livrables.
Aucun des scénarios utilisateurs ne pourront tourner au moment de la montée de version. Sauf si je gère une mise en pause de ces scénarios durant l'installation. raaa j'avais pas pensé à ça !!! Donc mon installation automatique ne pourra pas marcher. Sauf si j'impose à l'utilisateur une période de 10 minutes de mise en maintenance quotidienne du système.
Et il faut forcément que le système (Core, Manager, Voice) se mette en mode maintenance en même temps pour se mettre à jour afin qu'il n'y ait pas de requête sur la base mysql.
J'aimerai bien utiliser un système en cluster avec un système de fichier distribué, pour que le service mysql puisse démarrer sur n'importe quel noeud. Tous les noeuds se mettraient à jour les uns après les autres et redémarreraient. C'est chaud, faisable mais dangereux. Quoique terriblement GEEK.
Voilà merci pour ton aide. Ca a été très instructif !