Procédures stockées / schéma de firebase database dans le contrôle de source

Est-ce que vous suivez les procédures stockées et le schéma de firebase database dans votre système de contrôle de code source de votre choix?

Lorsque vous apportez une modification (ajout d’une table, mise à jour d’un processus stocké, comment obtenez-vous les modifications dans le contrôle de code source?

Nous utilisons SQL Server au travail et j’ai commencé à utiliser darcs pour le contrôle de version, mais je serais curieux de connaître les stratégies générales ainsi que les outils pratiques.

Edit: Wow, merci pour toutes les bonnes suggestions, les gars! Je souhaite pouvoir sélectionner plus d’une “réponse acceptée”!

Nous avons choisi de tout scripter, ce qui inclut toutes les procédures stockées et les modifications de schéma. Aucun outil wysiwyg et aucun programme de synchronisation sophistiqué ne sont nécessaires.

Les modifications de schéma sont simples, il vous suffit de créer et de gérer un seul fichier pour cette version, y compris toutes les modifications de schéma et de données. Cela devient votre script de conversion de la version x à x + 1. Vous pouvez alors l’exécuter avec une sauvegarde de production et l’intégrer dans votre «construction quotidienne» pour vérifier qu’elle fonctionne sans erreurs. Notez qu’il est important de ne pas modifier ou supprimer le schéma / le chargement de données déjà écrit, car vous risquez de casser n’importe quel SQL écrit plus tard.

-- change #1234 ALTER TABLE asdf ADD COLUMN MyNewID INT GO -- change #5678 ALTER TABLE asdf DROP COLUMN SomeOtherID GO 

Pour les procédures stockées, nous choisissons un seul fichier par sproc et il utilise la forme drop / create. Toutes les procédures stockées sont recréées lors du déploiement. L’inconvénient est que si un changement a été effectué en dehors du contrôle des sources, le changement est perdu. En même temps, c’est vrai pour n’importe quel code, mais votre DBA doit en être conscient. Cela empêche vraiment les personnes extérieures à l’équipe de manipuler vos procédures stockées, car leurs modifications sont perdues lors d’une mise à niveau.

En utilisant SQL Server, la syntaxe ressemble à ceci:

 if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [usp_MyProc] GO CREATE PROCEDURE [usp_MyProc] ( @UserID INT ) AS SET NOCOUNT ON -- stored procedure logic. SET NOCOUNT OFF GO 

Il ne rest plus qu’à écrire un utilitaire qui regroupe tous les fichiers individuels et crée un nouveau fichier avec l’ensemble des mises à jour (en un seul script). Pour ce faire, ajoutez d’abord les modifications du schéma, puis récurer la structure du répertoire et inclure tous les fichiers de procédure stockés.

En tant que sharepoint départ pour tout scripter, vous deviendrez beaucoup mieux en lecture et en écriture SQL. Vous pouvez également rendre ce processus plus élaboré, mais c’est le format de base pour contrôler toutes les sources sans aucun logiciel spécial.

addendum: Rick a raison de dire que vous allez perdre les permissions sur les procédures stockées avec DROP / CREATE, vous devrez peut-être écrire un autre script pour réactiver des permissions spécifiques. Ce script de permission serait le dernier à s’exécuter. Notre expérience a trouvé plus de problèmes avec ALTER vers les sémantiques DROP / CREATE. YMMV

créer un “projet de firebase database” dans Visual Studio pour écrire et gérer votre code sQL et conserver le projet sous contrôle de version avec le rest de votre solution.

La solution que nous avons utilisée lors de mon dernier travail consistait à numéroter les scripts au fur et à mesure de leur ajout au contrôle de code source:

01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql

L’idée était que nous savions toujours quel ordre exécuter les scripts, et nous pourrions éviter de devoir gérer des problèmes d’intégrité des données qui pourraient survenir si vous essayiez de modifier le script n ° 1 (ce qui ferait probablement échouer les INSERT dans # 2).

Une chose à garder à l’esprit avec vos scripts drop / create dans SQL Server est que les permissions de niveau object seront perdues. Nous avons changé notre norme pour utiliser les scripts ALTER à la place, qui conservent ces permissions.

Il y a quelques autres mises en garde, comme le fait que la suppression d’un object supprime les enregistrements de dépendance utilisés par sp_depends, et la création de l’object crée uniquement les dépendances pour cet object. Donc, si vous déposez / créez une vue, sp_depends ne connaîtra plus d’objects faisant référence à cette vue.

Morale de l’histoire, utilisez les scripts ALTER.

Je suis d’accord avec (et avec force) la pratique de Robert Paulson. Cela suppose que vous contrôliez une équipe de développement ayant la responsabilité et la discipline d’adhérer à une telle pratique.

Pour “forcer” cela sur mes équipes, nos solutions gèrent au moins un projet de firebase database à partir de Visual Studio Team Edition pour les professionnels de la firebase database . Comme pour les autres projets de la solution, le projet de firebase database est contrôlé par version. Il en résulte un processus de développement naturel consistant à diviser tout ce qui se trouve dans la firebase database en blocs pouvant être maintenus, en «disciplinant» mon équipe en cours de route.

Bien sûr, étant un projet Visual Studio, ce n’est pas parfait. Il y a beaucoup de bizarreries que vous rencontrerez qui peuvent vous frustrer ou vous embrouiller. Il faut beaucoup comprendre comment le projet fonctionne avant de l’accomplir. Les exemples comprennent

  • déployer des données à partir de fichiers CSV .
  • déploiement sélectif des données de test en fonction du type de construction .
  • Visual Studio tombe en panne lors de la comparaison avec les bases de données avec un certain type d’assemblage CLR intégré .
  • aucun moyen de différenciation entre les bases de données de test / production qui implémentent différents schémas d’authentification – Utilisateurs SQL vs utilisateurs Active Directory.

Mais pour les équipes qui n’ont pas l’habitude de contrôler leurs objects de firebase database, c’est un bon début. L’autre alternative célèbre est bien sûr la suite de produits SQL Server de Red Gate , que la plupart des utilisateurs considèrent comme supérieure à l’offre de Microsoft.

Je pense que vous devriez écrire un script qui configure automatiquement votre firebase database, y compris les procédures stockées. Ce script doit alors être placé dans le contrôle de code source.

Coupler différentes outlook de mon expérience. Dans le monde Oracle, tout était géré par des scripts DDL “create”. Comme ahockley l’a mentionné, un script pour chaque object. Si l’object doit changer, son script DDL est modifié. Il existe un script d’encapsuleur qui appelle tous les scripts d’object afin que vous puissiez déployer la version de firebase database actuelle dans n’importe quel environnement. Ceci est pour la création de base principale.

De toute évidence, dans une application en direct, chaque fois que vous appuyez sur une nouvelle version nécessitant, par exemple, une nouvelle colonne, vous ne déposez pas la table et ne la créez pas. Vous allez faire un script ALTER et append la colonne. Donc, chaque fois que ce type de changement doit se produire, il y a toujours deux choses à faire: 1) écrire le DDL alter et 2) mettre à jour le fichier DDL de base pour refléter le changement. Les deux vont dans le contrôle de source, mais le seul script alter est un changement momentané dans le temps puisqu’il ne sera utilisé que pour appliquer un delta.

Vous pouvez également utiliser un outil comme ERWin pour mettre à jour le modèle et générer le DDL à l’avance, mais la plupart des DBA que je connais ne font pas confiance à un outil de modélisation pour générer le script exactement comme ils le souhaitent. Vous pouvez également utiliser ERWin pour désosser périodiquement votre script DDL de base dans un modèle, mais il est compliqué de le rendre correct (chaque fois que vous le faites).

Dans le monde Microsoft, nous avons utilisé une tactique similaire, mais nous avons utilisé le produit Red Gate pour gérer les scripts et les deltas. Toujours mettre les scripts en contrôle de code source. Encore un script par object (table, sproc, peu importe). Au début, certains administrateurs de bases de données préféraient utiliser l’interface graphique de SQL Server pour gérer les objects plutôt que d’utiliser des scripts. Mais cela a rendu très difficile la gestion de l’entreprise de manière cohérente au fur et à mesure de son développement.

Si le DDL est sous contrôle de code source, il est sortingvial d’utiliser un outil de génération (généralement ant) ​​pour écrire un script de déploiement.

J’ai trouvé que de loin, le moyen le plus simple, le plus rapide et le plus sûr de le faire est de simplement mordre la balle et d’utiliser le contrôle des sources SQL de RedGate. Scripté et stocké dans le référentiel en quelques minutes. Je souhaite juste que RedGate considère le produit comme un facteur de perte afin de pouvoir l’utiliser plus largement.

Semblable à Robert Paulson, ci-dessus, notre organisation conserve la firebase database sous contrôle. Cependant, notre différence est que nous essayons de limiter le nombre de scripts que nous avons.

Pour tout nouveau projet, il existe une procédure définie. Nous avons un script de création de schéma à la version 1, un script de création de processus stocké et éventuellement un script de création de chargement de données initial. Tous les processus sont conservés dans un seul fichier, certes massif. Si nous utilisons Enterprise Library, nous incluons une copie du script de création pour la journalisation; s’il s’agit d’un projet ASP.NET utilisant le framework d’application ASP.NET (authentification, personnalisation, etc.), nous incluons également ce script. (Nous l’avons généré à partir des outils de Microsoft, puis l’avons modifié jusqu’à ce qu’il fonctionne de manière reproductible sur différents sites. Pas amusant, mais un investissement de temps précieux.)

Nous utilisons la magie CTRL + F pour trouver le proc que nous aimons. 🙂 (Nous aimerions que SQL Management Studio ait une navigation par code comme VS le fait. Sigh!)

Pour les versions ultérieures, nous avons généralement des scripts upgradeSchema, upgradeProc et / ou updateDate. Pour les mises à jour de schéma, nous modifions les tables autant que possible, en en créant de nouvelles si nécessaire. Pour les mises à jour de proc, nous DROP et CREATE.

Une seule ride apparaît avec cette approche. Il est facile de générer une firebase database et il est facile d’en créer une nouvelle sur la version actuelle de la firebase database. Cependant, il faut faire attention à la génération de DAL (que nous faisons actuellement avec SubSonic) pour nous assurer que les modifications de DB / schéma / proc sont synchronisées correctement avec le code utilisé pour y accéder. Cependant, dans nos chemins de construction, il y a un fichier batch qui génère la DAL SubSonic. C’est notre SOP pour extraire le code DAL, ré-exécuter ce fichier batch, puis le vérifier à chaque fois que le schéma et / ou procs changent. (Ceci, bien sûr, déclenche un build source, en mettant à jour les dépendances partagées sur les DLL appropriées …)

Dans le passé, j’ai gardé les modifications de la firebase database contrôlées de manière à ce que chaque modification de firebase database soit toujours créée et stockée dans la version sur laquelle nous travaillons. Le processus de construction en place amènerait automatiquement la firebase database à la version actuelle en fonction d’une table de la firebase database qui stockait la version actuelle pour chaque “application”. Une application utilitaire .net personnalisée que nous avons écrite serait alors exécutée et déterminerait la version actuelle de la firebase database, et exécuterait tous les nouveaux scripts dans l’ordre des numéros de préfixe des scripts. Ensuite, nous faisions des tests unitaires pour nous assurer que tout allait bien.

Nous stockons les scripts dans le contrôle de source comme suit (structure de dossier ci-dessous):

Je suis un peu rouillé sur les conventions d’appellation actuelles sur les tables et les procédures stockées si nues avec mon exemple …

[racine]
[application]
[version]
[scénario]

\ scripts
Mon application\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql

Avec l’utilisation d’une table de versions prenant en compte l’application et la version, l’application restaurera la sauvegarde de production hebdomadaire et exécutera tous les scripts requirejs par rapport à la firebase database depuis la version actuelle. En utilisant .net, nous avons pu facilement intégrer ceci dans une transaction et si quelque chose échouait, nous pourrions annuler et envoyer des emails, donc nous savions que cette version comportait de mauvais scripts.

Ainsi, tous les développeurs s’assurent de conserver ce contrôle de source afin que la version coordonnée s’assure que tous les scripts que nous prévoyons exécuter sur la firebase database fonctionneront correctement.

C’est probablement plus d’informations que vous recherchiez, mais cela a très bien fonctionné pour nous et, étant donné la structure, il était facile d’intégrer tous les développeurs.

Lorsque le jour de la publication a été dévoilé, l’équipe des opérations suivait les notes de publication et récupérait les scripts du contrôle de code source et exécutait le package avec l’application .net utilisée lors du processus de construction nocturne. quelque chose a échoué, il serait automatiquement annulé et aucun impact sur la firebase database n’a été fait.

Les procédures stockées obtiennent 1 fichier par sp avec le standard s’il existe des instructions drop / create en haut. Les vues et les fonctions obtiennent également leurs propres fichiers, ce qui facilite leur version et leur réutilisation.

Schema est tout 1 script pour commencer alors nous allons faire des changements de version.

Tout cela est stocké dans un projet de firebase database de studio visuel connecté à TFS (@ work ou VisualSVN Server @ home pour des trucs personnels) avec une structure de dossiers comme suit:
– projet
— les fonctions
– schéma
— procédures stockées
– vues

Dans mon entreprise, nous avons tendance à stocker tous les éléments de la firebase database dans le contrôle des sources en tant que scripts individuels, comme vous le feriez pour des fichiers de code individuels. Toutes les mises à jour sont d’abord effectuées dans la firebase database, puis migrées dans le référentiel du code source afin de conserver l’historique des modifications.
Dans un deuxième temps, toutes les modifications de firebase database sont migrées vers une firebase database d’intégration. Cette firebase database d’intégration représente exactement ce que la firebase database de production doit ressembler au post-déploiement. Nous avons également une firebase database d’assurance qualité qui représente l’état actuel de la production (ou du dernier déploiement). Une fois toutes les modifications effectuées dans la firebase database d’intégration, nous utilisons un outil de schéma (SQL Diff pour SQL Server de Red Gate) pour générer un script qui migrera toutes les modifications d’une firebase database à l’autre.
Nous avons trouvé cela assez efficace car il génère un script unique que nous pouvons facilement intégrer à nos installateurs. Le plus gros problème que nous rencontrons souvent est que les développeurs oublient de migrer leurs modifications vers l’intégration.

Nous conservons les procédures stockées dans le contrôle de source.

Tout script (création d’object, etc) et stocker ces scripts dans le contrôle de code source. Comment les changements arrivent-ils? Cela fait partie de la pratique standard de la façon dont les choses sont faites. Besoin d’append une table? Ecrivez un script CREATE TABLE. Mettre à jour un sproc? Editez le script de procédure stockée.

Je préfère un script par object.

Pour procs, écrivez les processus avec des encapsuleurs de script dans des fichiers simples et appliquez les modifications à partir de ces fichiers. Si elle est appliquée correctement, vous pouvez archiver ce fichier et vous pourrez également le reproduire à partir de ce fichier.

Pour les modifications de schéma, vous devrez peut-être archiver des scripts pour apporter progressivement les modifications apscopes. Ecrivez le script, appliquez-le, puis archivez-le. Vous pouvez ensuite créer un processus pour appliquer automatiquement chaque script de schéma en série.

Nous conservons les procédures stockées dans le contrôle des sources. La façon dont nous le faisons (ou du moins je le fais) consiste à append un dossier à mon projet, à append un fichier pour chaque SP et à copier manuellement le code. Donc, lorsque je change le SP, je dois manuellement modifier le fichier du contrôle de source.

Je serais intéressé de savoir si les gens peuvent le faire automatiquement.

Je recommande fortement de conserver le schéma et les procédures stockées dans le contrôle de code source.

Garder les procédures stockées en version permet de les annuler lorsqu’elles sont jugées problématiques.

Le schéma est une réponse moins évidente selon ce que vous voulez dire. Il est très utile de maintenir le SQL qui définit vos tables dans le contrôle de code source, pour dupliquer les environnements (prod / dev / user, etc.).

Nous avons utilisé une approche alternative dans mon projet actuel – nous n’avons pas encore obtenu la firebase database sous contrôle de code source, mais avons plutôt utilisé un outil de comparaison de firebase database pour écrire les modifications lorsque nous arrivons à chaque version.
Cela a très bien fonctionné jusqu’à présent.

Nous stockons tout ce qui concerne une application dans notre GDS. Les scripts de firebase database sont généralement stockés dans leur propre projet, mais sont traités comme n’importe quel autre code … conception, implémentation, test, validation.

Je lance un travail pour créer un script vers une structure de répertoire formelle.

Voici le code VS2005, projet de ligne de commande, appelé à partir d’un fichier de commandes, qui effectue le travail. touches app.config à la fin du code.

Il est basé sur un autre code que j’ai trouvé en ligne. Un peu pénible à mettre en place, mais fonctionne bien une fois que vous le faites fonctionner.

 Imports Microsoft.VisualStudio.SourceSafe.Interop Imports System Imports System.Configuration Module Module1 Dim sourcesafeDataBase As Ssortingng, sourcesafeUserName As Ssortingng, sourcesafePassword As Ssortingng, sourcesafeProjectName As Ssortingng, fileFolderName As Ssortingng Sub Main() If My.Application.CommandLineArgs.Count > 0 Then GetSetup() For Each thisOption As Ssortingng In My.Application.CommandLineArgs Select Case thisOption.ToUpper Case "CHECKIN" DoCheckIn() Case "CHECKOUT" DoCheckOut() Case Else DisplayUsage() End Select Next Else DisplayUsage() End If End Sub Sub DisplayUsage() Console.Write(System.Environment.NewLine + "Usage: SourceSafeUpdater option" + System.Environment.NewLine + _ "CheckIn - Check in ( and adds any new ) files in the directory specified in .config" + System.Environment.NewLine + _ "CheckOut - Check out all files in the directory specified in .config" + System.Environment.NewLine + System.Environment.NewLine) End Sub Sub AddNewItems() Dim db As New VSSDatabase db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword) Dim Proj As VSSItem Dim Flags As Integer = VSSFlags.VSSFLAG_DELTAYES + VSSFlags.VSSFLAG_RECURSYES + VSSFlags.VSSFLAG_DELNO Try Proj = db.VSSItem(sourcesafeProjectName, False) Proj.Add(fileFolderName, "", Flags) Catch ex As Exception If Not ex.Message.ToSsortingng.ToLower.IndexOf("already exists") > 0 Then Console.Write(ex.Message) End If End Try Proj = Nothing db = Nothing End Sub Sub DoCheckIn() AddNewItems() Dim db As New VSSDatabase db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword) Dim Proj As VSSItem Dim Flags As Integer = VSSFlags.VSSFLAG_DELTAYES + VSSFlags.VSSFLAG_UPDUPDATE + VSSFlags.VSSFLAG_FORCEDIRYES + VSSFlags.VSSFLAG_RECURSYES Proj = db.VSSItem(sourcesafeProjectName, False) Proj.Checkin("", fileFolderName, Flags) Dim File As Ssortingng For Each File In My.Computer.FileSystem.GetFiles(fileFolderName) Try Proj.Add(fileFolderName + File) Catch ex As Exception If Not ex.Message.ToSsortingng.ToLower.IndexOf("access code") > 0 Then Console.Write(ex.Message) End If End Try Next Proj = Nothing db = Nothing End Sub Sub DoCheckOut() Dim db As New VSSDatabase db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword) Dim Proj As VSSItem Dim Flags As Integer = VSSFlags.VSSFLAG_REPREPLACE + VSSFlags.VSSFLAG_RECURSYES Proj = db.VSSItem(sourcesafeProjectName, False) Proj.Checkout("", fileFolderName, Flags) Proj = Nothing db = Nothing End Sub Sub GetSetup() sourcesafeDataBase = ConfigurationManager.AppSettings("sourcesafeDataBase") sourcesafeUserName = ConfigurationManager.AppSettings("sourcesafeUserName") sourcesafePassword = ConfigurationManager.AppSettings("sourcesafePassword") sourcesafeProjectName = ConfigurationManager.AppSettings("sourcesafeProjectName") fileFolderName = ConfigurationManager.AppSettings("fileFolderName") End Sub End Module      

Si vous recherchez une solution simple et prête à l’emploi, notre système Sql Historian utilise un processus en arrière-plan pour synchroniser automatiquement les modifications DDL sur TFS ou SVN, de manière transparente pour toute personne effectuant des modifications sur la firebase database. Dans mon expérience, le gros problème est de conserver le code dans le contrôle de code source avec ce qui a été modifié sur votre serveur, et cela parce que vous devez généralement compter sur des développeurs (développeurs!) Pour modifier leur stream de travail. après ils ont déjà fait sur le serveur. Mettre ce fardeau sur une machine facilite la vie de chacun.