Bonjour,
Nous avons eu une discussion hier en interne et nous n'avons pas trouvé de solution idéale. Voici la problématique :
Nous sommes dans une infrastructure saas avec une bdd par client. Pour la mise à jour applicative on a du git/jenkins classique qui tourne. En revanche, on se pose la question de comment faire pour mettre à jour les BDD.
On a plusieurs centaines de clients et on aimerait éviter de passer les mises à jour base par base. Actuellement nous avons 2 applications avec 2 fonctionnements différents : - La première application, c'est le 1er utilisateur qui se connecte qui lance le script de MAJ sql - La seconde application, on a un script qui passe sur toutes les bases dans un modèle blue/green deploy.
Notre réunion n'a pas permis de trouver d'autres solutions que celles déjà mises en place. Et ces deux solutions ont du positif mais aussi du négatif.
Qu'utilisez vous de votre côté ? Quelle app connaissez-vous qui pourrait faire le job ? Quels sont vos conseils ?
Merci,
Guillaume
Bonjour Guillaume,
Ici pour une application déployer en masse depuis 15 ans, on utilise les scripts SQL pour UPGRADE avec toujours une capacité de script DOWNGRADE.
On lance dans l’application une action de mise à jour qui va télécharger, vérifier la licence et lancer les mises à jour base et soft.
On a quasiment reproduit un truc sympa a utilisé qui est maintenant plus simple dans les langages modernes ORM.
On ne changera pas pour cette application pour différentes raisons notamment une maitrise parfaite de ce qui est fait et la quantité de travaille que la migration donnerai.
Sans compter les phases de test etc etc
Donc sur nos nouvelles applications et leurs différents modules, on a tout passé en ORM.
On a privilégié la méthodologie Code First (presque à 90%, 10% en Data first)
Il y a énormément de choses sympa a dire la dessus mais pour ton point -> migration de versions par fichier de code qui donne l’explication de l’évolution du modèle de données lors de leur évolution. Donc l’appli qui UPG c’est toi.
Après reste a choisir la méthode de lancement : individuel, global sur Target (via un petit dev), par lot l’applicatif vient sur un déposit pour voir si une maj est dispo pour elle…
C’est selon le contexte, l’usage utilisateur, l’infra, localisation des données, la fréquence, heure de l’interruption possible.
Si cela peut t’aider un peu, bonne semaine
Xavier
De : Guillaume BRUEL bruel.guillaume48@gmail.com Envoyé : vendredi 23 novembre 2018 10:30 À : frsag@frsag.org Objet : [FRsAG] Déploiement MAJ BDD et intégrité des schémas
Bonjour,
Nous avons eu une discussion hier en interne et nous n'avons pas trouvé de solution idéale. Voici la problématique :
Nous sommes dans une infrastructure saas avec une bdd par client. Pour la mise à jour applicative on a du git/jenkins classique qui tourne. En revanche, on se pose la question de comment faire pour mettre à jour les BDD.
On a plusieurs centaines de clients et on aimerait éviter de passer les mises à jour base par base. Actuellement nous avons 2 applications avec 2 fonctionnements différents :
- La première application, c'est le 1er utilisateur qui se connecte qui lance le script de MAJ sql
- La seconde application, on a un script qui passe sur toutes les bases dans un modèle blue/green deploy.
Notre réunion n'a pas permis de trouver d'autres solutions que celles déjà mises en place. Et ces deux solutions ont du positif mais aussi du négatif.
Qu'utilisez vous de votre côté ? Quelle app connaissez-vous qui pourrait faire le job ? Quels sont vos conseils ?
Merci,
Guillaume
On Fri, Nov 23, 2018 at 10:32 AM Guillaume BRUEL < bruel.guillaume48@gmail.com> wrote:
Bonjour,
Hello,
Nous avons eu une discussion hier en interne et nous n'avons pas trouvé de
solution idéale. Voici la problématique :
Nous sommes dans une infrastructure saas avec une bdd par client. Pour la mise à jour applicative on a du git/jenkins classique qui tourne. En revanche, on se pose la question de comment faire pour mettre à jour les BDD.
On a plusieurs centaines de clients et on aimerait éviter de passer les mises à jour base par base. Actuellement nous avons 2 applications avec 2 fonctionnements différents :
- La première application, c'est le 1er utilisateur qui se connecte qui
lance le script de MAJ sql
- La seconde application, on a un script qui passe sur toutes les bases
dans un modèle blue/green deploy.
Notre réunion n'a pas permis de trouver d'autres solutions que celles déjà mises en place. Et ces deux solutions ont du positif mais aussi du négatif.
Qu'utilisez vous de votre côté ? Quelle app connaissez-vous qui pourrait faire le job ? Quels sont vos conseils ?
Chez nous les développeurs travaillent avec différents outils comme Phinx ( https://phinx.org/ ) pour les applis PHP ou Active Record Migration ( https://edgeguides.rubyonrails.org/active_record_migrations.html ) pour les applis Rails. Les modifications de schéma sont versionnées avec l'application et cela permet également de gérer des rollbacks dans certains cas.
Il ne reste plus aux admin sys qu'à exécuter la commande correspondante pendant les montées de version.
Merci,
Guillaume _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut,
Bien que des scripts pourront faire le travail correctement j'approuve particulièrement des outils de gestion de migration SQL comme Phinx. Pour les mêmes avantages cités (versioning, rollback et faciliter de suivre la bonne exécution des migrations).
Selon les applications et langages utilisées cela peut s'intégrer très facilement, ex: Le framework PHP Symfony avec le bundle doctrine que l'on utilise beaucoup chez nous.
Cela s'intègre parfaitement bien dans de l'intégration / déploiement continu, en exécutant la commande de migration le bundle détermine automatiquement les migration à passer / rollback.
++
-
Benoit Garcia -
Guillaume BRUEL -
Maximilien Douchet -
Xavier ROCA