View Issue Details

IDProjectCategoryView StatusLast Update
0001074Common[All Projects] Generalpublic2016-04-02 00:41
ReporterXenosAssigned ToXenos 
PriorityurgentSeverityfeatureReproducibilityN/A
Status CloseResolutionfixed 
Product Version 
Target VersionFixed in Version1.0.16 
Summary0001074: Généraliser les scripts de déploiement SQL
DescriptionL'archi est la suivante:
• sql/initialize: contient des scripts d'initialisation de la BDD, à exécuter une et une seule fois
• sql/api: contient les procédures, triggers, et autres vues que l'on peut exécuter plusieurs fois sans problème (requiert donc un DROP PROCEDURE en tête de chaque fichier de procedure, même principe pour les vues et trigger)


Lors du déploiement, il faut que le système upload ces fichiers SQL (ça, ok), qu'il exécute les *NOUVEAUX* fichier d'initialisation (osef s'ils sont modifiés: on ne les rééexécute pas dans ce cas), qu'il stocke ces fichiers exécutés quelque part pour ne plus les ré-exécuter la prochaine fois et qu'il exécute ensuite *TOUS* les fichiers de sql/api/

Il faut que le système génère logs et dumps pour cette opération:
• Il faut dumper la BDD avant toute opération d'exécution, pour pouvoir revenir dessus si besoin (et on la gzip pour la place)
• Il faut créer un fichier unique (SQL) à exécuter pour toutes ces opérations, et l'exécuter en mode transactionnel pour, en cas d'erreur, ne pas tout péter
• En cas d'erreur, il faut que la BDD reste intègre et il faut rollback toute l'opération (et donc, ne pas releaser)
• Le fichier unique doit être stocké quelque part (gzippé avec le dump?)
• Un fichier de log doit contenir tout ce que le MySQL a renvoyé (et être gzippé avec le dump & le fichier SQL?)

Ainsi, le système mettra la BDD à jour tout seul, sans risque d'erreur (en cas d'erreur, release/deploy annulé) et avec des logs et des infos pour rééexécuter la même opération.

Pour savoir quels fichiers d'initialisation ont été exécutés, je vais tout simplement copier/coller le fichier exécuté (en fait, je pompe le contenu de ce fichier pour créer le fichier SQL unique qui sera exécuté) dans un dossier dédié, et, pour chaque fichier sql/initialize, je vérifie s'il existe déjà un fichier dans ce dossier dédié. Si oui, je ne fais rien, si non, je c/c le fichier de sql/initialize et je l'exécute. Ainsi, j'aurai les infos de la "version" du fichier sql qui a été exécuté par le serveur (si je mettais à jour la copie qui se trouve dans le dossier dédié, alors je ne saurai pas quelle version du sql/initialize a été exécutée; or ces fichiers peuvent changer pour des raisons d'optimisation par exemple).


Pour finir, il faudra ajouter un hook mercurial qui vérifie que les fichiers de sql/initialize ne sont pas modifiés par un commit. Si un commit les modifie, il faut soit envoyer chier tout court, soit demander confirmation car ces modifications ne peuvent se faire que s'il s'agit d'optimisation. Le plus simple reste d'envoyer chier tout court.
Il serait aussi intéressant d'ajouter un hook vérifiant que les fichiers de sql/api commencent tous pas un "DROP xx IF EXISTS", sinon, le fichier aura du mal à être exécuté par le serveur.

Enfin, le script de déploiement doit accepter des arguments pour être générique à tous les projets: je dois juste avoir à indiquer ce script comme étant un "on-deploy" (ou before release) avec d'éventuels paramètres (comme le nom de la BDD, l'utilisateur, le mot de passe etc).
TagsNo tags attached.
Attach Tags

Activities

Xenos

Xenos

2016-03-24 23:04

administrator   ~0001643

A tester (avec un projet bidon à déployer? ou en déployant "common" avec un script SQL juste pour tester?)
Xenos

Xenos

2016-04-01 17:42

administrator   ~0001666

Last edited: 2016-04-02 00:41

"Test&Tries" me servira à cela :)
Xenos

Xenos

2016-04-02 00:39

administrator   ~0001667

Last edited: 2016-04-02 00:41

J'ai viré le dump MySQL avant le déploiement car finalement, je n'en vois pas l'intérêt:
• Les fichiers SQL qui créent ou virent des vues/procedures/triggers n'altèreront pas les données (le dump est plutôt inutile)
• Les fichiers d'init ont plutôt tendance à créer des données
• Ces dumps vont s'accumuler avec le temps et ralentissent énormément le déploiement (là, je ne l'ai fait que pour testNtries, mais pour Eclerd et ses 1.000.000 de cases ou Variispace et ses futures milliards de vaisseaux, ce sera juste impossible!)

Il faut simplement un backup régulier de la BDD, histoire de ne pas risquer de tout perdre du jour au lendemain.

Issue History

Date Modified Username Field Change
2016-03-13 18:55 Xenos New Issue
2016-03-13 18:55 Xenos Status New => Accepted
2016-03-21 22:51 Xenos Priority normal => urgent
2016-03-24 15:21 Xenostom Assigned To => Xenostom
2016-03-24 15:21 Xenostom Status Accepted => In progress
2016-03-24 23:04 Xenos Note Added: 0001643
2016-03-24 23:04 Xenos Status In progress => Ready
2016-03-24 23:04 Xenos Resolution open => fixed
2016-04-01 17:42 Xenos Note Added: 0001666
2016-04-01 22:01 AutoUpdater Assigned To Xenostom => Xenos
2016-04-01 22:01 AutoUpdater Status Ready => Resolved
2016-04-01 22:01 AutoUpdater Fixed in Version => 1.0.8
2016-04-01 22:43 AutoUpdater Fixed in Version 1.0.8 => 1.0.9
2016-04-01 23:07 AutoUpdater Fixed in Version 1.0.9 => 1.0.10
2016-04-01 23:32 AutoUpdater Fixed in Version 1.0.10 => 1.0.11
2016-04-01 23:38 AutoUpdater Fixed in Version 1.0.11 => 1.0.12
2016-04-01 23:43 AutoUpdater Fixed in Version 1.0.12 => 1.0.13
2016-04-01 23:48 AutoUpdater Fixed in Version 1.0.13 => 1.0.14
2016-04-01 23:54 AutoUpdater Fixed in Version 1.0.14 => 1.0.15
2016-04-02 00:39 Xenos Note Added: 0001667
2016-04-02 00:41 AutoUpdater Fixed in Version 1.0.15 => 1.0.16
2016-04-02 00:41 Xenos Status Resolved => Close