Comment gérez-vous les dimensions de la base de données en constante évolution?

9

Depuis environ deux mois, je recherche des solutions ou des pratiques pour gérer la gestion des versions dans les bases de données. Je cherche ce que les gens considèrent comme le meilleur processus pour gérer cela.

Nous avons 3 environnements pour nos bases de données:

  • Développement
  • Test d'acceptation utilisateur (UAT)
  • Production

Le problème est parfois que nous apportons des modifications à plusieurs choses dans notre base de données de développement et que le moment est venu de déployer, certaines fonctionnalités peuvent ne pas être prêtes à être publiées sur UAT.

Récemment, nous avons commencé à utiliser le contrôle Red Gate SQL Source pour stocker toutes nos entités (avec des validations régulières).

Je pensais à partir des ensembles de modifications (c'est-à-dire que tout depuis l'ensemble de modifications X et le retour est maintenant poussé vers UAT), cela signifie que les gens vérifient uniquement leur code dans le contrôle de code source juste avant de faire un déploiement qui peut devenir déroutant ( d'autant plus que les gens sont oublieux). Un autre problème lié à l'approche de l'ensemble de modifications est s'il y a un bogue dans une procédure stockée qui doit être corrigé, le numéro de l'ensemble de modifications finirait par être hors de portée de notre ensemble de modifications maximal pour la révision, ce qui le rend donc si nous devons recréer la base de données à partir d'un ensemble de modifications maximal, nous repousserions le bogue.

Des suggestions sur un processus?

Merci

database sql sql-server tsql judda
la source
Il semble que vos scripts de base de données ne soient pas dans le même contrôle de code source que votre code "réel". Pourquoi est-ce? Pouvez-vous le traiter comme du "code source" et le mettre avec les branches individuelles?
Mike M.
Nous ne stockons actuellement que la version de développement des scripts dans le contrôle de code source et UAT / Production ne sont pas synchronisés avec le développement actif. Chacun des scripts du contrôle de code source est mis à jour chaque fois qu'un développeur effectue une validation. Le problème avec les branches individuelles est que nous avons 1 base de données centralisée que tout le monde utilise (pour les changements plus importants, nous dérivons les bases de données distinctes).
1
Vous pouvez créer une branche pour la version et ne valider que les modifications qui se rapportent à la version. Toutes les autres modifications doivent être apportées au coffre. Vous auriez besoin de deux bases de données de développement pour y parvenir. Serait-ce un problème?
On dirait que l'on est susceptible de devenir obsolète assez rapidement. Non? Pour l'un de mes projets, nous sommes au milieu d'une refonte massive de la base de données, nous avons donc dérivé celui-ci afin que le développement actif puisse toujours se produire dans la version non modifiée de la base de données. Cependant, chaque jour, je vois notre version ramifiée devenir de plus en plus obsolète, ce qui je ne sais pas si c'est correct ou non ... Je n'ai jamais vraiment eu à faire face à des situations comme celle-ci auparavant.
judda

Réponses:

5

Migrations

Un haut et un bas, qui sont dans votre référentiel et étiquetés avec votre application.

Vous pouvez même bricoler avec des fichiers plats SQL qui modifient votre schéma et mettent à jour la version du schéma. Tout ce que vous avez à faire est de:

  • gardez vos migrations à côté du code source, elles doivent être versionnées et étiquetées ensemble
  • toujours utiliser les modifications gérées (migrations) dans tous les environnements
  • ne jamais autoriser de modifications ad hoc dans aucun environnement

Eh bien, vous pouvez effectuer des changements de développement dans le développement, mais vous devez toujours faire sauter votre base de données et le reconstruire avec des migrations une fois que vous avez capturé le changement.

Dietbuddha
la source
Que se passerait-il si un bug était trouvé dans les scripts? Revenez-vous au script sql et mettez-le à jour?
judda
1
Non, vous créez une nouvelle migration (qui augmente la version du schéma). C'est ainsi que vous savez que le correctif a été déployé, en regardant la version du schéma dans la base de données.
dietbuddha
Merci de votre aide. À première vue, cela semble être une approche très solide et similaire à notre stratégie de branchement.
judda
2

Contrôle de source!

Vous ne déployez pas vos binaires de développement directement en production sans passer par svn / git / p4, alors pourquoi vos bases de données feraient-elles cela à elles seules? Obtenez des instances privées pour que les développeurs testent leurs modifications locales, mais quand il doit aller dans la base de données de développement, il doit passer par les fichiers ddl archivés. Vous pouvez même rédiger des outils pour appliquer ces modifications ddl automatiquement (je ne connais aucun moyen existant de le faire correctement).

Une fois que vous avez mis en place les restrictions concernant les modifications du schéma db (plus de sqlplus -> problème avec ddl!) Et que vous avez un contrôle de compte strict (pas d'accès ddl à tout le monde), cela devrait devenir plus gérable.

Subu Sankara Subramanian
la source
1
Malheureusement, nos bases de données sont trop volumineuses pour être transmises entre développeurs pour que les sessions privées s'exécutent. De plus, cela ne semble pas vraiment tendre vers un développement basé sur une équipe, car en ce moment, je fais du développement back-end tout en discutant avec les gens pour le travail d'interface utilisateur reliant les deux. Je devrais commencer par vérifier toutes les modifications, puis les obtenir pour obtenir les dernières informations sur la base de données, ce qui semble être un gros problème.
judda
Pourquoi votre base de développement doit-elle avoir la même taille que la base de production? Ils peuvent avoir le même schéma, et vous pouvez même avoir un parc de test de charge spécial avec toutes les données, mais les bases de données de développement locales peuvent être petites. Cela évite également les problèmes de fuite de données, etc. - en théorie, les données de production ne devraient pas du tout affecter le développement.
Subu Sankara Subramanian
Toutes nos données sont chargées via notre processus de chargement de données qui traite les fichiers qui nous sont fournis par le client, puis les transforme en données dont nous avons besoin. Il nous est donc impossible de séparer les données de développement et de production étant donné que toutes les charges de données doivent être vérifiées de toute façon en cours de développement. Je suppose qu'il n'a pas besoin d'être de la même taille cependant, il a besoin de quantités comparables de données pour que les rapports que nous créons génèrent des informations significatives.
judda
La base de données entière n'a pas besoin d'être répliquée. Dans Oracle, chaque utilisateur a son propre schéma et nous avons un schéma d'application. Créez des synonymes publics pour tous les objets du schéma d'application. Ensuite, chaque utilisateur peut modifier les objets (tables, SP) dans son propre schéma et s’ils se connectent eux-mêmes, leurs noms d’objet seront utilisés. Pour les objets qui ne sont pas dans ce schéma, les synonymes devraient être utilisés. C'est ainsi que nous travaillons.
softveda
0

Suite à la suggestion d'utiliser les migrations ... peut-être utiliser un O / RM qui prend en charge les migrations comme Ruby on Rails et Entity Framework 4.3 Le problème avec les deux approches est cependant qu'une migration est tout ou rien. Vous ne pouvez pas (généralement) sélectionner les migrations à appliquer comme vous le pouvez en termes d'ensembles de modifications.

Une autre option viable (si vous êtes sur la pile Microsoft, vous n'avez jamais mentionné la plate-forme) est de gérer votre SQL avec les outils de base de données Visual Studio. Il a intégré le refactoring (renommer / supprimer des colonnes, etc.) et fait la vérification du modèle. Si par exemple, un proc stocké fait référence à une colonne qui n'est plus là, il vous en informera.

Michael Brown
la source