Un script pour faire des mises à jour

Version imprimable

28/12/2010, 19h54
zooffy

Un script pour faire des mises à jour

Bonjour à tous.

Je cherche à faire un système de mise à jour de mes développements de mon environnement de développement vers mon environement de production.

Je m'explique : je fais des sites Web. J'ai ma machine qui est instalée avec un SQL express 2008 sur laquelle je fais des tables, des vues, des procédures stockées et des fonctions.
Mon environnement de Production est un serveur dédié avec un SQL Express 2008 qui doit recevoir la même chose que ce que j'ai développé.

J'ai fouillé dans les bases de donnée Master et tempDB, mais je n'ai pas trouvé les données que je cherche.

L'idée est de lancer une procédure stockée qui va aller chercher toutes les modifications et les créations d'objet par rapport à une date donnée (qui serait un paramettre de la PS). Une fois trouvé les objets concernés, la PS va fabriquer un Script de création ou modification (selon le cas) que je n'aurais plus qu'à passer sur l'environnement de Production pour avoir une structure de donnée équivalente.

Deux soucis :
- je ne trouve pas les données qui concerne les dates de création ou de modification des objets
- je ne sais pas comment générer un script à partir d'une procédure stockée.

Eventuellement (mais là, je ne sais pas si le principe existe) je peux mettre en liaison les deux environnements. Mon serveur étant un serveur dédié, je fais ce que je veux (au sens autorisation du terme). Donc s'il existe un moyen de faire cette "mise à jour" directement entre serveur SQL, je suis preneur de l'idée.

Pouvez vous m'aider ?
29/12/2010, 14h45
Népomucène

Bonjour, si tu veux faire le script toi-même, c'est très courageux ;)

Déjà, il y a un outil gratuit qui te permet de visualiser les différences de
structure entre deux base SQL Server : http://www.sqldbtools.com/Default.aspx?LanguageId=FR

Si j'ai bien compris, tu souhaite déployer tes mises à jour sur la base
de production. Je ne vois pas l'intérêt de la date dans la démarche.

Pour mettre à jour tous les objets (sauf les tables),
le plus simple est de générer un script qui supprime et recrée les objets de la base :
- vues
- triggers
- ps
- udf

Pour les tables, c'est plus délicat.
Au moment où tu modifies une table dans l'environnement de développement,
il est possible de générer le script de modification (ALTER TABLE ...)
et de le passer ensuite sur la table de la base de production.

C'est vrai que c'est un peu laborieux mais c'est toujours mieux que d'essayer de générer le script soi-même.

Enfin ils existe aussi des outils payants qui font ce travail.
29/12/2010, 15h10
zooffy

Merci pour ton aide.

Je vais aller voir ton lien et étudier cela.

La date est un point de référence pour moi, histoire de ne pas avoir à recréer tout les objets à chaque fois que je fais une mise à jour.
Je m'aperçois que je n'ai pas bien exprimé un détail : mon idée et de faire de la mise à jour régulière, genre tous les jours, pour envoyer mon travail de la journée vers la Prod. Donc biensûr, lorsque je parle de Date j'y inclu l'heure.

Et donc, du coup, ton idée de rebalancer tous les objets, sans quelle soit mauvaise, n'est pas facilement applicable dans mon cas. La lourdeur de l'action va gravement entacher les perf de mon serveur, sans compter le fait que pendant que les objets sont supprimés (certes pas longtemps) les visiteurs des sites vont se retrouver avec des messages d'erreur violents.

Voilà pourquoi j'aimerais bien savoir où sont cachées les données sur les objets. Ainsi je pourrais faire un truc personnalisé qui aurait un minimum d'impact sur le serveur de Production.

Pour être encore plus précis : sur mon serveur j'ai fais un environement de Production ET un environnement de PréProduction, réplique quasi exacte de la Production, avec juste un temps d'avance pour que le Client puisse tester en Live les modifcations et amélioration que j'apporte à son site. Du coup, je transfert de Dev vers PreProd, je teste et fais tester et ensuite je transfert de PreProd vers Pord toujours avec le même outils, qui pourrait également me faire une sorte de versionning (mais trés léger).

Voilà, je suis conscient que c'est un poil ambitieux, mais il faut que je me fabrique les bons outils pour pouvoir bien travailler et être perfomant. Si j'arrive à réduire la mise à jour du travail à cliquer sur un bouton, je gagne un temps monstrueux, donc de l'argent.....

Encore merci pour ton aide et bonnes fêtes.
29/12/2010, 17h40
Népomucène

La liste des objets et leurs contenus se trouve dans la table Sysobjects

Cependant, je n'y ai pas vu de date de modification. Pour moi, il faut effectuer une comparaison objet par objet.

Je voulais faire exactement ce que tu as décris. Mais avec l'expérience,
je me suis rendu compte que certaines parties du développement pouvaient être en chantier assez longtemps alors qu'il faillait livrer d'urgence des correctifs.

Pour moi, le système d'intégration continu n'est donc pas adapté.
C'est pourquoi j'utilise ce comparateur de base qui se contente de m'indiquer les différences et ensuite, je décide de ce que je mets à jour.

Bon courage et bonnes fêtes. :)
29/12/2010, 18h13
Invité

Citation:

Envoyé par Népomucène

La liste des objets et leurs contenus se trouve dans la table Sysobjects

Cependant, je n'y ai pas vu de date de modification. Pour moi, il faut effectuer une comparaison objet par objet.

Je voulais faire exactement ce que tu as décris. Mais avec l'expérience,
je me suis rendu compte que certaines parties du développement pouvaient être en chantier assez longtemps alors qu'il faillait livrer d'urgence des correctifs.

Pour moi, le système d'intégration continu n'est donc pas adapté.
C'est pourquoi j'utilise ce comparateur de base qui se contente de m'indiquer les différences et ensuite, je décide de ce que je mets à jour.

Bon courage et bonnes fêtes. :)

Pas mieux !
29/12/2010, 21h41
soazig

Bonjour,
Je confirme la dangerosité de transférer les objets de façon automatique sur la production sans passer par une étape être humain qui vérifie qu'on n'est pas dans un état instable au moment de la réplication.

Pour résoudre un problème similaire, je me suis écrit un utilitaire qui génère les scripts de création, modification ou suppression de fonctions, vues, procédures stockées dont les noms d'objets sont dans un fichier de configuration xml.
Au fur et à mesure de mes développement je rajoute le nom des objets modifié et quand je suis sure de moi je génère le script.
Pour générer le script j'appelle depuis vb.net la procédure stockée

Code:

sp_helptext MonObjet

Inconvénient il ne faut des retours chariot fréquents, car sp_helptext tronque au bout d'un certain nombre de caractère, cette limitation ne m'a gênée qu'une seule fois en 4 ans d'utilisation de l'outil.
Pour les modifications de tables, je crée les scripts au fur et à mesure.
Cordialement
Soazig
30/12/2010, 10h08
zooffy

Merci pour votre aide et vos avis.

Je partage pas mal de point et je découvrir des failles dans mon idée de base.
En gros, vous êtes en train de m'éviter de faire une connerie, et ça, je trouve ça cool.....

Pour revenir sur le détail :
- sp_helptext MonObjet, ça sert à fabriquer un script automatique ?
- merci pour la table sysobject, je vais aller voir (on aprle bien de celle qui dans la base concernée ?)
- quand à la date, elle existe obligatoirement, le studio management la donne, donc il va la chercher quelque part.

PS : ce matin étude approfondie de sqldbtool
30/12/2010, 16h10
aieeeuuuuu

Citation:

Envoyé par Népomucène

Pour mettre à jour tous les objets (sauf les tables),
le plus simple est de générer un script qui supprime et recrée les objets de la base :
- vues
- triggers
- ps
- udf

Oui, Dans ce cas, penser aussi aux privilèges qui risquent de sauter en même temps que les objets.
Et pour des (mauvaises) raisons pratiques, les privileges ne sont pas toujours les mêmes en prod et en dev (les fameux comptes pseudo admin qui ont accès a tout, utilisés pour développer...:cry:)

Attention aussi aux vue indexées. Le temps de suppression/recreation avec les index peut être long...

Citation:

Envoyé par Népomucène

Je voulais faire exactement ce que tu as décris. Mais avec l'expérience,
je me suis rendu compte que certaines parties du développement pouvaient être en chantier assez longtemps alors qu'il faillait livrer d'urgence des correctifs.

Pour moi, le système d'intégration continu n'est donc pas adapté.
C'est pourquoi j'utilise ce comparateur de base qui se contente de m'indiquer les différences et ensuite, je décide de ce que je mets à jour.

Oui, moi je fais dans le même genre. J'ai fait des scripts en Powershell pour vérifier la différence entre plusieurs BDD.
Ça me génère des scripts drop/create pour les objets autres que les tables
pour les tables, ca m'indique les différences (en commentaire dans le script). Je crée ensuite les scripts de modif a la main (de toute façon, avec les éventuelles contraintes, il y a souvent un ordre précis pour modifier les tables...)

Ca me génère aussi le script qui va bien pour les privilèges...

Mais dans tous les cas, je ne lance jamais ces scripts sans une relecture avant, et test sur serveur d'integration !

Citation:

Envoyé par soazig

Je confirme la dangerosité de transférer les objets de façon automatique sur la production sans passer par une étape être humain qui vérifie qu'on n'est pas dans un état instable au moment de la réplication

:ccool:

Cela dit, c'est vrai que des solutions plus automatisées, ca fait rêver 8-)