Bogarting de la couche d'accès aux données

9

Situation: le dba est un entrepreneur hors site qui conserve l'intégralité du code DAL dans TFS. Ce serait bien en tant que développeur frontal de pouvoir ajouter des colonnes et de modifier les procs et ainsi de suite, sans avoir à attendre que ce mec réponde à vos e-mails pour faire le travail.

Question: Quelle serait la solution / le processus recommandé qui permettrait un développement plus rapide / agile, tout en maintenant l'intégrité des données ainsi que l'amour de la paix et le bonheur au sein de l'équipe?

— spaghetticowboy
source

Je m'inquiète ici de la raison pour laquelle vous avez dû ajouter une colonne et des règles métier associées à cette colonne. Vous pouvez trouver des moyens de contourner ce problème et éventuellement ajouter la colonne, mais qu'en est-il si vous avez utilisé le mauvais type de données, les paramètres NULL, la définition d'index, pire si la colonne ne doit pas appartenir à la table ou s'il vous manque une table d'intersection? Je pense que quelqu'un doit être responsable de l'impact commercial de la définition de nouvelles données et que quelqu'un doit également être responsable de l'impact d'un changement de base de données sur le code (autre que le DBA). Les 2 rôles peuvent être joués par la même personne.

— NoChance

Exiger que le DBA travaille dans sa propre branche. Ne leur donnez pas de droits de retrait à la branche principale de développement. Créez alternativement votre propre branche de développement et fusionnez vos modifications selon vos besoins.

— SoylentGray

11

Martin Fowler et Pramod Sadalage ont écrit un excellent article sur ce sujet.

Chaque développeur a sa propre base de données dans laquelle des modifications peuvent être apportées. Ces modifications sont ensuite communiquées (sous la forme d'un ensemble de modifications) au DBA qui les implémente dans la base de données master, il est donc toujours impliqué dans le processus, il est probablement le mieux informé des structures et des besoins de la base de données. Je pense que c'est la meilleure approche car elle est satisfaisante pour toutes les personnes impliquées dans le processus et elle est également très agile.

Vous pouvez modifier le DAL d'une manière similaire. Apportez simplement vos modifications et fournissez un ensemble de modifications pour le DBA lorsque vous pensez que vous avez terminé, afin qu'il puisse l'examiner et le fusionner dans son maître.

— Faucon
source

1

oooh j'aime ... c'est mon premier Q ici, donc je ne peux pas encore voter, mais vous avez sûrement un commentaire ... peut-être / probablement la réponse aussi, mais j'aime attendre un peu pour voir ce que les autres disent

— spaghetticowboy

Le problème est que le développeur fait tout son travail en supposant que la dba approuvera.

— HLGEM

@HLEGM: D'après mon expérience, c'est rarement le cas, la plupart du temps le DBA l'approuve ou le modifie légèrement. C'est toujours mieux que d'avoir des développeurs inactifs assis. De plus, cela conduira probablement à la meilleure solution si le DBA et le développeur sont tous deux des personnes raisonnables.

— Falcon

+1 pour expliquer pourquoi il s'agit d'un excellent article au lieu de simplement publier un lien.

— JeffO

@HLGEM - Je pense qu'il faut que les deux parties justifient ce qu'elles font. Le DBA devrait bénéficier du doute en matière de db, mais les deux doivent répondre à quelqu'un d'autre qui aurait la décision finale.

— JeffO

3

Eh bien, quand je fais le DBA, on sait que tout est verrouillé pour que les foutus programmeurs sales ne puissent pas mettre la main dessus. Tout le monde pense qu'ils savent comment faire mieux, et ils "peaufinent" les choses pour les rendre plus faciles pour eux-mêmes, et cela provoque un gâchis impie.

L'autre alternative est de le jeter grand ouvert, et de laisser les programmeurs se mêler dessus pendant un moment, puis d'intervenir et d'imposer de l'ordre alors que les choses commencent à se terminer ... C'est certainement plus "agile", mais cela peut être un vrai cauchemar en fonction de ce qui doit être supprimé ou modifié ... Les administrateurs de bases de données ont souvent une meilleure compréhension du projet dans son ensemble, et certains changements qui semblent anodins peuvent être problématiques.

S'il va être le seul gardien, il doit soit avoir une spécification fixe, soit être capable de "vendre" sa vision au reste des développeurs.

— Satanicpuppy
source

nous sommes sacrément sales ... et parfois nous sommes aussi assez impatients et devons faire les choses nous

— spaghetticowboy

@spaghetti: Oui ... Je suis probablement pire que la plupart parce que j'ai fait beaucoup de travail DBA, j'ai donc deux fois le "Je sais comment faire mieux!" que la plupart des programmeurs. Je dirai ceci: avec les bases de données, il est beaucoup plus important de bien faire les choses tôt ... Si vous continuez à ajouter jusqu'à la fin du projet, cela va certainement causer des problèmes.

— Satanicpuppy

3

Il y a un problème majeur qui remplace tout autre problème:

Pourquoi l'entrepreneur fait-il toujours vérifier le code?

Pourquoi est-il autorisé à faire cela? Personne ne devrait faire extraire un fichier à moins qu'il n'effectue activement des modifications. Il devrait y avoir une politique d'équipe concernant les paiements.

L'entrepreneur (qu'il le veuille ou non) travaille au sein d'une équipe, et parfois d'autres membres de l'équipe peuvent avoir besoin d'apporter des modifications. Il s'agit d'un problème de communication. Malheureusement, il n'existe aucun moyen automatisé de résoudre ce problème de communication.

— George Stocker
source

1

Au lieu de couches horizontales, je préfère travailler en silo à travers les couches.

De cette façon, aucune personne / équipe ne peut bloquer de cette façon.

Cela signifie également que vous êtes des développeurs polyvalents et capables de déplacer les fonctionnalités beaucoup plus facilement.

Bien sûr, il y a des sections (conception d'interface utilisateur et conception de base de données) qui peuvent nécessiter plus de travail spécialisé, mais vous avez l'idée.

— ozz
source

1

Simple, si vous ne l'avez pas déjà fait, vous devriez avoir 3 environnements:

Environnement de développement
Environnement QA
Environnement de production

L'environnement de développement doit être administré par vos développeurs.

Vous pouvez également ajouter un environnement RC.

Une autre réponse, si plusieurs environnements ne sont pas possibles, vous pouvez développer contre un référentiel simulé ... De cette façon, vous construisez vos modèles, puis votre entrepreneur est responsable de faire correspondre vos modèles à la base de données. D'une certaine manière, c'est mieux car cela libère vos développeurs de se soucier de la base de données.

— AJC
source

1

L'OP parle de code extrait. Des environnements différents n'auraient pas d'impact.

— NotMe

1

Votre problème me semble être lié à la main-d'œuvre. Il est approprié et nécessaire que tous les changements potentiels de base de données soient approuvés par un spécialiste de la base de données. Si la personne actuelle ne peut pas suivre le travail en temps opportun, vous avez besoin de plus de spécialistes de base de données.

— HLGEM
source

+1: Cela peut également être une cause du problème. De nombreuses entreprises ont trop peu de DBA.

— Falcon

1

Il s'agit d'un problème de gestion autant que technique.

Il existe certainement des raisons valables pour un administrateur de base de données (qu'il soit sur site ou non, sous-traitant ou employé) d'empêcher les développeurs de modifier tout type de base de données.

Cependant, le principal problème que vous avez défini est celui de la disponibilité. Votre manager sait-il que du temps / de l'argent est perdu à attendre cette personne? Sinon, vous voudrez peut-être expliquer comment tout le monde est assis.

— Pas moi
source