From: | Pam Contribution <pam(dot)contribution(at)gmail(dot)com> |
---|---|
To: | Cédric Villemain <cedric(at)2ndquadrant(dot)fr> |
Cc: | "pgsql-fr-generale(at)postgresql(dot)org" <pgsql-fr-generale(at)postgresql(dot)org>, Rémi DELCOURT <rdelcourt(at)straton-it(dot)fr> |
Subject: | Re: Intégration Continue avec PostgreSQL. |
Date: | 2014-02-14 11:56:09 |
Message-ID: | F669351D-FCF9-43B1-B528-84BF9EBF5D4F@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Bonjour,
Dans notre projet nous sommes confrontes a ce genre de probleme en ce qui concerne la mise a jour du schema de base lors du deploiement continu.
Voici la solution mise en place et tres simple:
Lors d une mise a jour de schema nous commitions le script sql dans un repertoire de notre application, chaque script est numerote afin de toujours etre joue dans le meme ordre.
Ensuite Nous avons mis en place un script schell qui est lance lors du deploiement via jenkins, ce script parcours le repertoire contenant les fichiers de mises a jour de base et a chaque fichiers trouves nous regardons dans une table played_scripts si le scripts na pas deja ete joue sur cette base de donnees.
S il a ete joue dans ce cas on passe au suivant sinon on le joue et on enregistre le nom du script en cours dans la table played_scripts afin de ne pas le rejouer au prochain deploiement.
Cela a l avantage de fonctionner pour nos deploiement en prod/recette/dev etc...car si un script es nouveau il sera joue. Et meme sur nos poste de dev vu que les scripts sql sont commite dans l application, lorsqu ont les recuperes on joue le script shell en question et il met a jour notre base local avec les nouveaux scripts automatiquement. Du coup en regardant dans la table played_scripts nous savons si une base est bien a jour ou pas.
Apres il es possible d ajouter au debut du script une ligne qui verifie la presence de la db avant de parcourirs la liste des fichiers sql.
Cordialement.
> Le 14 févr. 2014 à 12:33, Cédric Villemain <cedric(at)2ndquadrant(dot)fr> a écrit :
>
> Bonjour
>
>> Dans l'idéal voici ce que j'aimerai pouvoir faire à chaque déploiement de
>> l'application :
>>
>> · Si la base de données n'existe pas sur le serveur où je déploie
>> mon application alors je lance le script de création*.
>>
>> · Si la base de données existe et qu'il y a eu une modification du
>> modèle alors je lance le script d'upgrade*.
>>
>> · Si la base de données existe et qu'il n'y a pas eu de changements
>> du modèle de données, je ne fais rien.
>>
>> *Pour info les scripts de création et d'upgrade sont inclus dans le
>> packaging de l'application.
>>
>> Dernier cas un peu plus tordu :
>> Je suis en version 1.0 de mon application, je souhaite déployer la version
>> 1.2 en sachant qu'il y a eu une version 1.1 intermédiaire qui n'avait pas
>> été déployée sur ce serveur. Lors du déploiement de 1.0 vers 1.2 je dois
>> être capable de faire :
>>
>> · Exécution du script SQL d'upgrade de 1.0 vers 1.1.
>>
>> · Exécution du script SQL d'upgrade de 1.1 vers 1.2.
>>
>> Connaissez-vous des outils permettant de réaliser ce genre de tâches ? Je
>> sais que ceci peut être fait via un script bash, mais si un outil existe
>> autant l'utiliser.
>
> pyrseas est un outil qui devrait vous convenir.
> La tagline du projet :
> « Provides a framework and utilities to upgrade and maintain a relational
> database.»
> https://github.com/pyrseas/Pyrseas
>
> (en clair il va vous aider à faire des diffs de bases et fournir les scripts de
> migration d'une version X vers Y)
>
> http://www.pyrseas.org/
>
>
> --
> Cédric Villemain +33 (0)6 20 30 22 52
> http://2ndQuadrant.fr/
> PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2014-02-14 11:56:26 | Re: Aide sur pg_upgrade : il ne lance pas le nouveau postmaster |
Previous Message | Cédric Villemain | 2014-02-14 11:48:31 | Re: Relation shared_buffers - Checkpoint |