Gestion de la fusion des modifications/ajustements de production de DBA avec les modifications de scripts de la DB en attente

Question

Nous maintenons un ensemble de scripts de modification qui doivent être exécutés sur la base de données lorsque notre application Web est publiée. Nous perdons beaucoup de temps et nous en éprouvons quelques difficultés à les mettre à jour, mais notre administrateur de bases de données aime (à juste titre) modifier les procédures stockées et les schémas sur le système en direct pour maintenir les performances du système. De temps à autre, nous devons refaire nos correctifs au schéma actuel et aux procédures stockées, mais il est extrêmement difficile de détecter les changements qui pourraient entrer en conflit et de déterminer quels changements de nos DBA nous pourrions être en train de faire.

Comment les autres gèrent-ils la nécessité de modifier les bases de données actives en fonction des modifications en attente? Quels processus pouvons-nous mettre en place pour rendre ce processus plus lisse?

Quelle est la meilleure façon de stocker, de gérer notre schéma et d'appliquer nos/nos changesets?

Merci d'avance.

Answer 1

Les administrateurs de base de données ne doivent jamais modifier les procédures sur Prod uniquement. Ils devraient également utiliser le contrôle de la source et mettre les changements sur les autres environnements afin que les autres qui en prennent connaissance en soient conscients.

Answer 2

Effectuez toutes les modifications DDL du script de schéma DB et stockez ensuite dans votre contrôle de code source. En particulier les changements apportés par votre DBA - Je suggère de faire examiner votre schéma de base et vos procs stockés par un développeur db et le DBA avant de les vérifier dans votre contrôle de code source (les accessoires à HLGEM pour le dire). Les déplacements dans prod devraient être scriptés et approuvés avant l'application (c.-à-d., Si le DBA trouve des choses qui ont besoin d'être changées, demander au DBA d'ouvrir un défaut et gérer via ce processus).

Verrouillez toutes ces modifications DDL de vos développeurs. Les gars intelligents qui écrivent Java et C# devraient communiquer avec votre «spécialiste» db de l'équipe sur la meilleure façon d'atteindre les objectifs de conception et les besoins du côté db. Limitez les réglages de production à ces cas hautement dépendants de la situation, par exemple, de nombreux magasins informatiques ont un DBA qui définira la configuration du stockage physique en fonction des scripts de déploiement db fournis par votre application, ce qui est généralement OK. Un assistant avec votre application pour aider les personnes moins expérimentées ainsi qu'une liste des 10 meilleures recommandations pour l'installation et l'accord de base ira un long chemin.