Comment devriez-vous construire votre base de données à partir du contrôle de code source?

Question

Il y a eu quelques discussions sur le wiki de la communauté au sujet de si les objets de base de données doit être la version contrôlée. Cependant, je n'ai pas vu beaucoup de discussions sur les meilleures pratiques pour la création d'une version de l'automatisation des processus pour les objets de base de données.

Cela a été un point litigieux de discussion pour mon équipe - en particulier parce que les développeurs et les Administrateurs ont souvent des objectifs différents, des approches et des préoccupations lors de l'évaluation des risques et bénéfices d'une approche d'automatisation de déploiement de base de données.

J'aimerais entendre quelques idées de la communauté sur les pratiques qui ont été efficaces dans le monde réel.

Je me rends compte que c'est un peu subjectif, dont les pratiques sont vraiment le meilleur, mais je pense qu'un bon dialogue sur ce qui pourrait être utile à beaucoup de gens.

Voici quelques unes de mes teaser des questions sur les domaines de préoccupation dans cette rubrique. Il ne s'agit pas d'une liste définitive, mais plutôt un point de départ pour les personnes pour les aider à comprendre ce que je suis à la recherche pour.

1. Devrait à la fois de test et de production des environnements être construit à partir de la source de contrôle?
   
   • Devrait à la fois être construit à l'aide d'automation - ou devrais-production par construit par de la copie d'objets à partir d'un stable, a finalisé l'environnement de test?
   • Comment traitez-vous avec les différences de potentiel entre le test et les environnements de production dans des scripts de déploiement?
   • Comment faites-vous tester les scripts de déploiement permettra de travailler aussi efficacement contre la production comme ils le font dans le test?
2. Quels types d'objets doit être la version contrôlée?
   • Code (procédures, des packages, des triggers, java, etc)?
   • Index?
   • Les contraintes?
   • Définitions De Table?
   • Table Des Scripts De Modification? (eg. MODIFIER les scripts)
   • Tout?
3. Les types des objets ne doit pas être la version contrôlée?
   • Les séquences?
   • Les subventions?
   • Les Comptes D'Utilisateur?
4. Comment doit-objets de base de données être organisé dans votre référentiel SCM?
   • Comment traitez-vous avec des choses comme les scripts de conversion ou de MODIFIER des scripts?
   • Comment réagissez-vous face à la retraite des objets de la base de données?
   • Qui devrait être responsable de la promotion des objets de développement, de test de niveau?
   • Comment coordonnez-vous les changements à partir de plusieurs développeurs?
   • Comment traitez-vous avec des branchements pour les objets de base de données utilisé par plusieurs systèmes?
5. Quelles sont les exceptions, le cas échéant, peut être raisonnable apportées à ce processus?
   • Les questions de sécurité?
   • De données avec de l'identification des préoccupations?
   • Les Scripts ne peuvent pas être entièrement automatisé?
6. Comment pouvez-vous rendre le processus résilient et exécutoire?
   • Développeur d'erreur?
   • À des questions environnementales?
   • Pour la reprise après sinistre?
7. Comment voulez-vous convaincre les décideurs que les avantages de la DB-SCM vraiment justifier le coût?
   • Des preuves anecdotiques?
   • L'industrie de la recherche?
   • L'industrie des recommandations de bonnes pratiques?
   • Les appels à des autorités reconnues?
   • L'analyse coût/Bénéfice?
8. Qui devrait "propre" objets de base de données dans ce modèle?
   • Les développeurs?
   • Administrateurs de base de données?
   • Les Analystes De Données?
   • Plus d'un?

Answer 1

Voici quelques unes des réponses à vos questions:

1. Devrait à la fois de test et de production des environnements être construit à partir de la source de contrôle? OUI
   • Devrait à la fois être construit à l'aide d'automation - ou devrais-production par construit par de la copie d'objets à partir d'un stable, a finalisé l'environnement de test?
   • Automatisation pour les deux. Ne PAS copier des données entre les environnements
   • Comment traitez-vous avec les différences de potentiel entre le test et les environnements de production dans des scripts de déploiement?
   • Utiliser des modèles, de sorte que effectivement vous produire de l'autre ensemble de scripts pour chaque environnement (ex. les références à des systèmes externes, bases de données, etc)
   • Comment faites-vous tester les scripts de déploiement permettra de travailler aussi efficacement contre la production comme ils le font dans le test?
   • Vous tester sur l'environnement de pré-production: le déploiement d'un test sur la copie exacte de l'environnement de production (base de données et éventuellement à d'autres systèmes)
2. Quels types d'objets doit être la version contrôlée?
   • Code (procédures, des packages, des triggers, java, etc)?
   • Index?
   • Les contraintes?
   • Définitions De Table?
   • Table Des Scripts De Modification? (eg. MODIFIER les scripts)
   • Tout?
   • Tout, et:
   • N'oubliez pas de données statiques (recherche de listes, etc), de sorte que vous n'avez pas besoin de copier les données entre les environnements
3. Conserver uniquement version actuelle de la base de données des scripts (version contrôlé, bien sûr), et

Magasin de MODIFIER les scripts: 1 GRANDE script (ou répertoire de scripts nommé aimé 001_AlterXXX.sql, de sorte que l'exécution de leur naturel tri de mise à niveau à partir de la version A à B) Les types des objets ne doit pas être la version contrôlée?

• Les séquences?
• Les subventions?
• Les Comptes D'Utilisateur?
• voir les 2. Si vos utilisateurs/rôles (ou techniques, les noms d'utilisateur) sont différents entre les environnements, vous pouvez toujours le script eux à l'aide de modèles (voir 1.)

Comment doit-objets de base de données être organisé dans votre référentiel SCM?

• Comment traitez-vous avec des choses comme les scripts de conversion ou de MODIFIER des scripts?
• voir les 2.
• Comment réagissez-vous face à la retraite des objets de la base de données?
• supprimé à partir de DB, retiré à partir de la source de contrôle du tronc/conseil
• Qui devrait être responsable de la promotion des objets de développement, de test de niveau?
• dev/test/calendrier de mise en
• Comment coordonnez-vous les changements à partir de plusieurs développeurs?
• essayez de ne PAS créer une base de données distincte pour chaque développeur. vous utilisez la source de contrôle, non? dans ce cas, les développeurs de modifier la base de données et l'enregistrement dans les scripts. pour être complètement sûr, re-créer la base de données de l'scripts pendant la nightly build
• Comment traitez-vous avec des branchements pour les objets de base de données utilisé par plusieurs systèmes?
• difficile: essayer d'éviter à tout prix.

Quelles sont les exceptions, le cas échéant, peut être raisonnable apportées à ce processus?

• Les questions de sécurité?
• ne pas stocker les mots de passe pour test/prod. vous pouvez l'autoriser pour dev, surtout si vous avez automatisé, tous les jours/tous les soirs DB reconstruit
• De données avec de l'identification des préoccupations?
• Les Scripts ne peuvent pas être entièrement automatisé?
• document et de les stocker avec la libération info/MODIFIER le script

Comment pouvez-vous rendre le processus résilient et exécutoire?

• Développeur d'erreur?
• testé avec le quotidien de construire à partir de zéro, et de comparer les résultats de la mise à niveau incrémentielle (à partir de la version A à B à l'aide de ALTER). comparer les deux résultant du schéma et des données statiques
• À des questions environnementales?
• utiliser le contrôle de version et des sauvegardes
• comparer les PROD schéma de base de données pour ce que vous en pensez, surtout avant le déploiement. SuperDuperCool DBA peut avoir corrigé un bug qui n'a jamais été dans votre système de ticket :)
• Pour la reprise après sinistre?

Comment voulez-vous convaincre les décideurs que les avantages de la DB-SCM vraiment justifier le coût?

• Des preuves anecdotiques?
• L'industrie de la recherche?
• L'industrie des recommandations de bonnes pratiques?
• Les appels à des autorités reconnues?
• L'analyse coût/Bénéfice?
• si les développeurs et les Administrateurs d'accord, vous n'avez pas besoin de convaincre qui que ce soit, je pense (Sauf si vous avez besoin d'argent pour acheter un logiciel comme un dbGhost pour MSSQL)

Qui devrait "propre" objets de base de données dans ce modèle?

• Les développeurs?
• Administrateurs de base de données?
• Les Analystes De Données?
• Plus d'un?
• Habituellement, Administrateurs de bases de données approuver le modèle (avant le check-in ou après dans le cadre de la révision du code). Ils ont certainement le propre de la performance relative des objets. Mais, en général, l'équipe de propre et de l'employeur, bien sûr :)]

Answer 2

Je traite le SQL dans le code source lorsque cela est possible

Si je peux l'écrire dans la norme de conformité du SQL puis il va généralement dans un fichier dans mon contrôle de code source. Le fichier de définir autant que possible (par exemple, SPs, de Table, de CRÉER des instructions.

J'ai également inclure des données factices pour les tests de contrôle de code source:

1. proj/sql/setup_db.sql
2. proj/sql/dummy_data.sql
3. proj/sql/mssql_specific.sql
4. proj/sql/mysql_specific.sql

Et puis j'ai résumé toutes mes requêtes SQL qui permet de créer l'ensemble du projet pour MySQL, Oracle, MSSQL ou quoi que ce soit d'autre.

Construire et d'automatisation de test utilise ces scripts comme elles sont aussi importantes que l'application source et les tests de tout, de l'intégrité par le biais de déclencheurs, procédures et exploitation forestière.

Answer 3

Nous utilisons intégration continue via TeamCity. À chaque checkin au contrôle de code source, la base de données et toutes les données de test est re-construit à partir de zéro, alors le code, les tests unitaires sont exécutés dans le code. Si vous êtes à l'aide d'un outil de génération de code comme CodeSmith, il peut également être placé dans votre processus de génération pour générer votre couche d'accès aux données fraîche avec chaque version, en s'assurant que tous vos calques "match up" et ne produisent pas les erreurs dues au décalage SP paramètres ou des colonnes manquantes.

Chaque version a sa propre collection de scripts SQL qui sont stockés dans le $projet\SQL\ répertoire du contrôle de code source, affectée d'un préfixe numérique et exécutés dans l'ordre. De cette façon, nous pratiquons notre procédure de déploiement à chaque génération.

En fonction de la table de recherche, la plupart de nos valeurs de recherche sont également stockés dans les scripts et les exécuter pour s'assurer que les données de configuration est ce que nous attendons pour, disons, "reason_codes" ou "country_codes". De cette façon, nous pouvons faire une recherche les données de changement de dev, test, puis à "promouvoir" par le biais de QA et de la production, au lieu d'utiliser un outil pour modifier les valeurs de recherche dans la production, ce qui peut être dangereux pour la disponibilité.

Nous avons également créer un ensemble de "rollback" scripts annuler nos modifications de base de données, dans le cas d'un build pour la production va tordu. Vous pouvez tester la restauration des scripts en cours d'exécution, puis de ré-exécuter les tests unitaires pour le construire une version en dessous de la vôtre, après son déploiement à l'exécution des scripts.

Answer 4

En posant des "questions-réponses", vous semblez plus intéressé par une discussion que par l'opinion de quelqu'un sur les réponses finales. La liste de diffusion active (> 2500 membres) agileDatabases a répondu à beaucoup de ces questions et est, selon mon expérience, un forum sophistiqué et civil pour ce type de discussion.

Answer 5

J'ai fondamentalement d'accord avec chaque réponse donnée par van. Pour plus de perspicacité, ma base pour la gestion de base de données est K. Scott Allen série (à lire absolument, à mon humble avis. Et Jeff l'avis de trop il me semble).

• Objets de base de données peut toujours être reconstruit à partir de zéro par le lancement d'un unique fichier SQL (qui peut lui-même appel à d'autres fichiers SQL) : Create.sql. Cela peut inclure statique d'insertion de données (listes...).
• Les scripts SQL sont paramétrés de sorte qu'aucun dépendant de l'environnement et/ou des informations sensibles sont stockées dans les fichiers bruts.
• J'utilise un fichier de commandes pour le lancement Create.sql : Create.cmd. Son objectif est principalement de vérifier les pré-requis (outils, les variables d'environnement...) et d'envoyer des paramètres pour le script SQL. Il peut également en vrac-charge statique de données à partir de fichiers CSV pour les problèmes de performances.
• Généralement, le système d'identification de l'utilisateur serait passée comme paramètre à la Create.cmd le fichier.

À mon humble avis, la dynamique de chargement de données devrait exiger une autre étape, en fonction de votre environnement. Les développeurs veulent charge de leur base de données avec des tests, indésirable ou pas de données à tous, même à l'autre extrémité de la production gestionnaires souhaitez charger les données de production. Je considère le stockage des données de test dans le contrôle de code source (pour faciliter les tests unitaires, par exemple).

Une fois la première version de la base de données a été mise en production, vous aurez besoin non seulement de construire des scripts (principalement pour les développeurs), mais aussi les scripts de mise à niveau (basé sur les mêmes principes) :

• Il doit y avoir un moyen de récupérer la version de la base de données (j'ai utiliser une procédure stockée, mais une table ferait aussi bien).
• Avant de publier une nouvelle version, j'ai créer un Upgrade.sql le fichier (que l'on peut appeler les autres) qui permet la mise à niveau de la version N-1 à la version N (N étant la version en cours de sortie). - Je conserver ce script dans un dossier nommé N-1.
• J'ai un fichier de commandes qui effectue la mise à niveau : Upgrade.cmd. Il peut récupérer la version actuelle (CV) de la base de données via une instruction SELECT simple, lancez l' Upgrade.sql script stocké en vertu de l' CV le dossier, et la boucle jusqu'à ce qu'aucun dossier n'est trouvé. De cette façon, vous pouvez mettre à jour automatiquement à partir, par exemple, N-3 à N.

Des problèmes avec ce sont :

• Il est difficile de comparer automatiquement les schémas de base de données, en fonction de la base de données des fournisseurs. Cela peut conduire à incomplète scripts de mise à niveau.
• Tout changement de l'environnement de production (généralement par les Administrateurs de base de données pour l'optimisation des performances) doit trouver son chemin vers la source de contrôle. Pour vous assurer de cela, il est généralement possible de se connecter à chaque modification de la base de données via un déclencheur. Ce journal est remis après chaque mise à niveau.
• Plus idéalement, cependant, DBA a initié des changements devraient être une partie de la presse/processus de mise à niveau lorsque c'est possible.

À quel genre d'objets de base de données voulez-vous d'avoir sous contrôle de code source ? Eh bien, je dirais autant que possible, mais pas plus ;-) Si vous voulez créer des utilisateurs avec des mots de passe, obtenir un mot de passe par défaut (login/login, pratique pour les tests unitaires), et faire le changement de mot de passe d'un fonctionnement manuel. Cela se produit beaucoup avec Oracle, où les schémas sont également des utilisateurs...