[FRsAG] Déploiement MAJ BDD et intégrité des schémas

[Guillaume BRUEL]

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

[Xavier ROCA]

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 <***@gmail.com>
Envoyé : vendredi 23 novembre 2018 10:30
À : ***@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

[Benoit Garcia]

On Fri, Nov 23, 2018 at 10:32 AM Guillaume BRUEL <

Post by Guillaume BRUEL
Bonjour,

Hello,

Nous avons eu une discussion hier en interne et nous n'avons pas trouvé de

Post by Guillaume BRUEL
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
- 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.

Post by Guillaume BRUEL
Merci,
Guillaume
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

[Maximilien Douchet]

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.

++
--
Maximilien D

Co-gérant, Co-Fondateur
Responsable Hébergement & Infogérance
***@kabolt.fr <mailto:***@kabolt.fr> - [phone]