Suggestions sur le développement continu du schéma de database lorsqu'il est en cours de réplication

Je travaille actuellement sur une database qui vient avec un projet hérité qui utilise EntityFramework (met à jour le code basé sur la database existante en utilisant Data Model Designer)

Actuellement, je travaille sur la copy principale et nos développeurs travaillent localement en utilisant des réplications de fusion SQL Server sur leur PC local.

Le problème ici est que nous avons récemment commencé à modifier le schéma de la database, donc lorsque nous utilisons la comparaison de schéma (Visual Studio SQL compare), il y a un grand nombre de changements de schémas de réplication. la database en direct. Donc ma solution actuelle est de supprimer la réplication du server de développement (pour que le schéma returnne à ce qu'elle devrait ressembler sans modifications de réplication), puis de comparer et de mettre à jour le schéma, puis de créer une nouvelle réplication de fusion. sur le dev db.

Je pensais que c'était juste un changement de schéma db unique, mais je me suis juste rendu count qu'il y aura des changements continus au less pour les 3-6 prochains mois, de sorte que chaque version aura un gros mal de tête (si on peut l'appeler 'release' préparation…)

Mes connaissances SQL et EntityFramework sont limitées, quelqu'un peut-il nous éclairer là-dessus?

Merci d'avance!

Quel est le besoin observé derrière la réplication de fusion dans l'environnement de développement? Je comprends la nécessité pour les développeurs de disposer d'une copy locale avec laquelle ils peuvent manipuler, exécuter des tests, etc. Je ne comprends pas pourquoi un model Publisher-Subscriber complet est nécessaire pour synchroniser l'état DB dans un environnement de développement / test. pour vous causer plus de problèmes que cela pourrait résoudre étant donné que le schéma sera malléable pendant quelques mois.

Si la réplication de fusion n'est pas une exigence ssortingcte pour l'environnement de développement, je vous suggère de la replace par une autre méthode de dissortingbution des modifications aux copys locales. Si les devs travaillent de toute façon avec une copy complète de la BD, je ne vois aucune raison de ne pas écrire un script qui sauvegarde la copy principale sur le server de dev, puis retire ce file et le restaure localement. Ensuite, les modifications apscopes à ce schéma seraient accomplies avec des scripts de changement, qui peuvent être exécutés et testés localement avant d'être appliqués à la database principale, puis dissortingbués à la request avec une autre exécution du script de sauvegarde / restauration.

C'est un process un peu plus manuel et une façon plus ancienne de travailler avec des DB, mais cela me semble beaucoup plus acceptable que de casser et de rétablir la réplication régulièrement. Cela nécessitera une certaine collaboration pour s'assurer que les développeurs n'essaient pas de faire une sauvegarde en même time ou d'apporter des modifications conflictuelles aux copys locales qui exploseront sur la copy principale; Vos développeurs devraient idéalement se parler entre eux de ce genre de choses, et vous pourriez rendre le script assez intelligent pour searchr une sauvegarde récente avant d'en générer une autre.

Une pensée de plus, ne sais pas comment cela est possible count tenu de vos progrès à ce jour; il n'est pas impossible de passer de DB-First à Code-First. La conversion est essentiellement un process hybride de Database First et Code First; la database est conçue en tant qu'opération unique pour générer un model similaire à DB First, mais à la place des files EDMX, le model est écrit dans les files de code source et les modifications apscopes aux files templates ou aux conventions de mappage sur le context peuvent ensuite être agrégées et appliquées au schéma en tant que migrations dans le style Code First typique. En supposant que vous prépariez également le DB actif pour les migrations (et que vous ayez le DB actif dans le même état que le DB Dev principal avant la génération du model), cela supprime même l'exigence d'une comparaison et d'une mise à jour SQL; vous appliquez simplement les migrations à la database en direct, comme vous le feriez pour n'importe quelle instance de développement. Le seul truc possible est que certaines migrations peuvent être écrites de manière destructive, donc vous devez vous assurer que ce que vous êtes sur le point d'appliquer ne va pas effacer tous les champs d'une colonne renommée.