Mon DBA vient de perdre du travail de développement qu'il a fait sur notre base de données de développement. Pauvre gars. Donc, naturellement, notre responsable lui a demandé, à notre réunion de statut, comment cela pourrait arriver et comment nous pourrions éviter cela à l'avenir. "Le contrôle des sources pourrait atténuer le problème" J'ai suggéré ... la réponse de la DBA; "Non, nous venons de sauvegarder le serveur plus souvent". Maintenant, je voudrais aider mon DBA à comprendre à quel point le contrôle de la source est et comment il convient avec un schéma de base de données et un développement sur ce schéma.
Auparavant, j'ai essayé de l'expliquer qu'il n'y a rien de spécial sur le code source derrière les tables et les procédures stockées et il devrait être dans un système de contrôle source (TFS dans ce cas). Mais il n'a tout simplement pas mordé. Maintenant, alors que ce disape est dans la mémoire récente, j'aimerais prendre un autre coup de poignard.
Donc, ma question est, savez-vous de bons conseils que je pouvais transmettre à mon DBA et peut-être même quelques ressources expliquant comment vous allez migrer un schéma de base de données pour être sous contrôle source et trouver sa place appropriée dans les processus de construction et de déploiement?
Quelques faits sur l'environnement:
Clarification: Nous utilisons DB Ghost et d'autres solutions de gestion de changement sur d'autres projets avec d'autres DBA, par le passé. Nous avons même la licence pour VS DB Edition! Le problème consiste à faire penser à la DBA de penser à cette façon de développer la base de données. Il est vraiment vieille école (c'est-à-dire la migration des changements manuellement de l'environnement à l'environnement), et il est malheureusement hes le seul à savoir quoi que ce soit sur ce dB particulier.
10 Réponses :
Vous ne pouvez pas vraiment mettre une grande base de données sous contrôle source, votre DBA a donc raison.
Ce que vous pouvez faire pratiquement est de mettre votre schéma sous contrôle source, et peut-être quelques petites tables «configurations».
Je voulais dire le schéma ... désolé je vais clarifier.
Il est possible tant que tout est au format du script, mais les fichiers volumineux ralentissent les performances, mais ma devinière et recommandation sont que nous ne parlons que du script de schéma comme vous l'avez souligné.
Si vous utilisez un système d'équipe Visual Studio, je vous recommande d'avoir un coup de poing à leur édition de base de données (je pense que ces jours-ci sont livrés avec l'édition du développeur si vous êtes un abonné MSDN). Ce que cela vous permettra de faire, c'est de scripter tout votre schéma, des Procs stockés, des vues, des déclencheurs, etc. et le contrôle des sources. Cela devrait également rendre le DBA plus confortable car il fonctionnera avec une version "base de données" de l'outil plutôt que la version "Developer" (la nommée peut faire une grande longueur avec des personnes). Lorsque vous apportez des modifications de Visual Studio, vous pouvez gérer les modifications de script à mesure que vous travaillez et que vous les contrôlez.
Je pense que nous sommes d'accord ... vous penseriez que mon cher DBA devrait sauter à un outil tel que VS DB Edition. Mais il n'est pas.
Si votre entreprise dispose d'une licence MSDN, elles peuvent utiliser l'édition de la base de données Visual Studio. Il y a un didacticiel vidéo d'IT ici .
Je n'ai pas de pouvoir d'achat, je ne sais donc pas quelles sont les pannes de coûts. Mais il a la capacité de contrôler la source de toutes les parties d'un schéma de base de données, et comprend la création de scripts de changement ainsi que le déploiement automatique droit de VS si vous le souhaitez (je ne recommanderais pas que).
En général, il est assez solide comme une option de contrôle de la source de base de données.
Merci pour le lien, cela sera envoyé rapidement. Nous avons une licence à VS DB Edition, mais le principal problème est de convaincre mon DBA qu'il devrait l'utiliser. ;) Il est vraiment vieille école. Je veux dire, nous utilisons DB Ghost et d'autres solutions de gestion des changements de DB avec d'autres projets et autres DBA, mais celui-ci est persistant de faire des modifications directement à chaque environnement.
Dans ce cas, s'il est bon le faisant de son chemin, et je suppose qu'il est, sinon il pourrait être obligé de changer. La principale caractéristique que la DB Edition ou tout contrôle de la source a pour effet de mettre à jour par un nombre de personnes et que ces changements seront automatiquement fusionnés. De toute évidence, quelqu'un doit wtach la fusion, mais cela signifie que cela ne manquera pas de changer la façon dont une fusion manuelle. S'il y a beaucoup de gens touchant la base de données, des choses se produisent. mauvais choses. Donc, la commande Source DB permet à plusieurs personnes de travailler sur la même base de données sans toucher it.
Malheureusement, il n'est pas très bon pour la manipuler son chemin. S'il était il ne perdrait pas son travail. ;) Et même pire ce n'est pas la première fois que son développement "processus" a causé des problèmes. Mon problème est que je n'ai pas de pouvoir sur le gars, donc tout ce que je peux faire est de le présenter avec la preuve de la mise en place qu'il devrait changer ses méchantes manières.
Eh bien, la première partie est convaincante que la commutation sera facile. S'il estime que la commutation fera son travail plus difficile, il pourrait en fait être pire à basculer. Maintenant, bien sûr, utiliser la version de version est plus facile, vous vous battez donc contre la perception. Commencer là. Puis convaincez-le que cela vaut la peine d'être basculé vers Quelques contrôle de la version. Si vous pouvez alors effectuer des exigences de rassemblement sur ce qu'il ressent des carences de son propre processus, vous pourrez peut-être trouver un produit qui corrige les éléments qu'il admet besoin de la fixation. Ensuite, vous pouvez le sevrer sur toutes les autres fonctions utiles.
Ça ma l'air bon. Merci. ;)
Un moyen de stocker la base de données de contrôle consiste à stocker les données dans et autour de la base de données séparément
Vous pouvez avoir toutes les tables, procédures et scripts de fonction sous forme de fichiers SQL et les ajouter au contrôle de la source.
Exportez les données de base de données comme insérez des instructions dans des fichiers SQL, chacune avec une taille fixe. C'est un processus encombrant car il impliquerait beaucoup de fichiers à suivre et à contrôler.
Je ne suis pas sûr que le VSS / SVN est capable de lire et de conserver l'historique des modifications apportées aux fichiers de décharge créés par les options de sauvegarde de la base de données.
voir Comment contrôler les bases de données SQL Server et Sourez-vous contrôler vos bases de données , parmi beaucoup d'autres. Ou utilisez le Rechercher page . Fondamentalement, votre approche semble correcte. Bonne chance persuader le dba ...
Merci, je ferai de mon mieux.
Ce n'est pas clair de votre question si vous souhaitez protéger les données dans la DB ou les schémas de la DB. Si ces derniers, vous pouvez identifier tous les schémas importants et exécuter un travail cron qui tire les définitions de schéma de la DB et les insère automatiquement dans un système de contrôle source (peut-être même via des déclencheurs sur les schémas ??).
Mais cela équivaut toujours à soutenir le système plus souvent. Pour ce que vous envisagez, vous auriez besoin de contrôle de source intégré aux outils de DB et je ne connais aucun produit qui le fait.
(et je frémise de penser à VSS intégré dans SQL Management Studio: - (()
J'ai clarifié la question de sorte qu'il est plus clair que je parle du schéma. Cependant, des produits tels que DB Ghost et VS DB Edition font un excellent travail d'extraction de scripts de schéma et de générer des scripts de changement entre les versions de schéma.
@Johannes selon mon commentaire à la question principale après votre clarification, la technologie n'est pas cassée, votre DBA est!
Le contrôle de la source pour les bases de données peut être assez controversé. Il est différent d'utiliser le contrôle de la source pour quelque chose qui produit un binaire car vous ne pouvez pas verrouiller la source: une procédure stockée est une ligne dans une table et il n'y a pas une table unique à lire pour obtenir une définition de table.
En outre, la version à la version est principalement un ensemble d'instructions d'alter. Votre script Out crée et ajoutez-les au contrôle de la source. Cela rend plus difficile à utiliser dans des cas comme celui-ci.
Pour moi, c'est plus une erreur de procédure.
Pourquoi le changement n'est-il pas fait d'un script? Oublier où le script vit, mais pourquoi aucun script reproductible et runnable? Peut-être liée au numéro de suivi des modifications? Si la base de données est réinitialisée (chargée à prod), comment la modification aurait-elle été réappliquée pour se préparer à la production. Et d'autres questions.
Je crois au contrôle de la source et nous l'utilisons: mais il a des limites pour le travail de base de données.
C'est vrai que vous écrivez des déclarations "Créer". Mais est-ce un problème? Je veux dire, autant que je puisse comprendre ces scripts, il est utilisé pour créer une base de données vide. Vous faites ensuite une difforme entre la base de données vide (d'une version spécifique) contre la cible DB que vous souhaitez mettre à jour. Ce diff sera un script up- / basculer pour lequel vous pouvez exécuter sur le serveur cible. Est-ce un malentendu de ma part? Je n'ai pas, alors je ne vois pas le problème dans ce processus de déploiement. S'il vous plaît élaborer.
Nous travaillons contre une copie de la production plutôt que dans une construction vide: nous voulons assurer des travaux de code contre des données réalistes
... et c'est plus un problème de gens / processus pour vous, je pense
Tout d'abord, vous approchez-vous de manière incorrecte. Si le DBA ne mordra pas sur le contrôle de la source et qu'il fait des erreurs qui affectent le système, la personne dont vous avez besoin pour persuader est son patron.
Si cela aide, je viens de la vieille école aussi et j'adore avoir nos objets de base de données dans le contrôle de la source. Dans quelle mesure être capable de revenir à une table sans avoir à restaurer la sauvegarde de la base de données entière à un emplacement différent, puis déplacez la table. Combien de temps plus rapide et plus simple. Dans quelle mesure être capable de comparer deux versions différentes et de voir ce qui a changé. Dans quelle mesure déployer une modification et savoir exactement quelle base de données change (par exemple, par exemple, douze des 23 personnes possibles) accompagnez la pièce que vous déploiez et non un autre projet inachevé. Comme c'est bien de savoir exactement quels scripts ont été impliqués dans un changement particulier que vous avez dû retourner. Dans quelle mesure personne ne fait des changements à la volée sur la production, car nous exigeons maintenant que toutes les modifications de production provenaient des scripts de contrôle de la source. Il y a tellement de moins d'erreurs et de questions à craindre.
Oui, ce fut une modification de la façon dont nous avons fait des affaires, mais nous l'avons fait à travers une modification de la politique de High Ainsi, il n'y avait aucun argument et que les DBA ont traversé plusieurs fois et ont rétabli des objets différents du contrôle de la source à la source. Version de contrôle, alors maintenant personne ne pensera même à effectuer une modification de la base de données sans qu'il soit au contrôle de la source.
Ma réponse à ce même problème consistait à exporter tous les objets DB sur le formulaire de texte (plus de 136 000 d'entre eux), puis créez les projets SourceSafe pour les conserver. Tous les objets nouveaux ou modifiés dans la DB se rendent maintenant à la structure SourceSafe, tandis que inchangés sont laissés seuls.
En tant que responsable du produit pour SQL Comparez, j'ai parlé à de nombreux dbas «traditionnels» qui sont inconfortables avec des outils tiers principalement parce qu'ils ont un système qui les convient et qui change parfois peut être difficile. Il y a de nombreuses situations où je suis convaincu qu'ils bénéficieraient de nos outils si seulement ils leur donnaient une chance. Frustrant.
Une chose que vous pourriez envisager d'essayer est l'outil à venir de la Gate rouge, le contrôle SQL Source. Ceci est conçu pour construire un contrôle de source dans SSMS, en d'autres termes, il ne nécessite pas de DBAS de quitter la zone de confort de leur environnement de gestion. La mauvaise nouvelle est que l'outil n'a pas encore été libéré. La bonne nouvelle est que nous avons un programme d'accès rapide. Veuillez visiter le lien suivant pour en savoir plus sur l'outil:
http://www.red-gate.com/products/sql_source_control /index.htm
Juste pour annoncer que cela a été publié et est disponible pour évaluer et acheter. rouge-gate.com/products/sql_source_control/index.htm
Je n'ai pas encore trouvé de moyen simple d'obtenir des objets SQL Server dans le contrôle de la source. C'est toujours un défaut de travailler de scripts sur votre disque dur. Ensuite, certains puz peuvent toujours entrer, appuyer sur "Modifier" sur ce procédé stocké, puis ils vont. Donc, je suis intéressé s'il y a une meilleure façon (TM).
Compte tenu de la clarification, il semble que vous n'aviez pas de problème «technologique», mais un problème «personnes». Aucune quantité d'outils parfaits ne va changer d'avis sur la façon dont il fait son travail. On dirait que c'est un cas de besoin qu'il lui a dicté via une autorité supérieure.
Vous pouvez essayer d'obtenir beaucoup de gens qui se disputent votre cause quelque part (... ici?), Puis dirigez-le à la page. Peut-être s'il voit que ce n'est pas seulement vous , mais beaucoup d'autres personnes qui pensent une certaine chose, il sera persuadé de lui donner une plus grande considération.