Comment fusionner les modifications de schéma apportées à une base de données de production dans mon processus géré par migration?

Question

Mon équipe évalue dbdeploy pour gérer les migrations de base de données. Si je comprends bien, l'utilisation des migrations nécessite une certaine discipline de processus, à savoir qu'une migration est écrite pour chaque changement, et que pour atteindre la production, il faudrait passer du développement local au développement pour tester la production. De temps en temps, notre équipe de production DBA effectue des changements de schéma directement dans l'environnement de production. Si nous écrivons une nouvelle migration pour effectuer la modification par rapport à notre version de développement actuelle de la base de données, cette migration ne sera jamais testée sur un schéma qui contient déjà la modification tant que la migration n'est pas déployée en production. Cela me concerne.

L'autre option consiste à effectuer la modification directement dans le schéma de base, puis à reconstruire la base de données dans tous les environnements (local, développement, test, étape). Cette approche me concerne, car le nouveau schéma pourrait provoquer une ou plusieurs migrations.

Comment les gens manipulent-ils actuellement ce scénario?

Answer 1

Il est compréhensible que les modifications de base de données sur le schéma de production doivent se produire de temps en temps. Il est cependant très important que ceux-ci soient documentés et communiqués dès que possible à l'équipe de développement. Le texte brut avec le sql exécuté avec des commentaires sur les cas d'utilisation affectés/fonctionnalités et les problèmes de suivi des bogues pourrait faire

Récupérer la base de données en direct au développement de temps en temps et en la comparant (c'est le schéma) avec ce que les développeurs ont C'est une bonne idée aussi.

Answer 2

Je suppose que la seule chose que DBA peut changer sur la DB de production est d'ajouter un index ici et là et de modifier quelques sprocs - le tout pour des raisons de performance. Toutes les autres modifications apportées à la base de données peuvent, d'une manière générale, rendre le schéma de base de données incompatible avec l'application. Dans cet esprit, la seule chose qui devrait réellement être versionnée est sprocs, et il est de la responsabilité d'un administrateur de base de données de les vérifier dans le contrôle de la source. Les index sont beaucoup plus volatils et peuvent ne pas être inclus dans les scripts de migration.

Answer 3

Nous restaurons une copie de notre base de données de production sur un serveur de test pendant la nuit.

Cela sert alors:

• En tant que copie de référence (code et données)
• Nous pouvons réinitialiser toutes les modifications que nous avons apportées
• Nous pouvons tester contre des données réelles
• Nous pouvons côté à côté nouveau/ancien code de préformance
• Nous pouvons générer 100% des scripts de changement/annulation en toute sécurité (Red Gate)

Nous ne reconstruisons pas les bases de données de dev/test, mais certains de nos autres projets le font. Cependant, je ne suis pas sûr du bénéfice car une base de données n'est pas un schéma et un code: ce sont aussi des données. C'est différent d'une application .net respectée.

Dans mon magasin, un DBA de production apportant des modifications à une base de données prod (tout changement) sans approbation serait renvoyé. Et c'est arrivé.