Liste de contrôle pour les mises à niveau du schéma de base de données

Question

La nécessité de mettre à niveau un schéma de base de données rend l'installation d'une nouvelle version d'un logiciel beaucoup plus délicate.Quelles sont les bonnes pratiques pour y parvenir ?

Je recherche une liste de contrôle ou une chronologie des actions à entreprendre, telles que

• 8h30, fermer les applications
• 8h45 modifier le schéma
• 9h15 installer de nouvelles applications
• 9h30 redémarrage de la base de données

etc., montrant comment minimiser les risques et les temps d'arrêt.Des questions telles que

• annuler la mise à niveau si les choses tournent mal
• minimiser l'impact sur les applications existantes
• mises à jour "à chaud" pendant l'exécution de la base de données
• promotion du développement au test vers les serveurs de production

sont particulièrement intéressants.

Answer 1

J'ai beaucoup d'expérience avec cela.Mon application est hautement itérative et les changements de schéma se produisent fréquemment.Je fais une version de production environ toutes les 2 à 3 semaines, avec 50 à 100 éléments supprimés de ma liste FogBugz pour chacun.Chaque version que nous avons réalisée au cours des dernières années a nécessité des modifications de schéma pour prendre en charge de nouvelles fonctionnalités.

La clé est de pratiquer les modifications plusieurs fois dans un environnement de test avant de les appliquer réellement sur les serveurs en direct.

Je conserve un fichier de liste de contrôle de déploiement qui est copié à partir d'un modèle, puis fortement modifié pour chaque version avec tout ce qui sort de l'ordinaire.

J'ai deux scripts que j'exécute sur la base de données, un pour les modifications de schéma, un pour la programmabilité (procédures, vues, etc.).Le script des modifications est codé à la main et celui avec les procédures est scripté via Powershell.Le script de modification est exécuté lorsque tout est éteint (vous devez choisir le moment qui dérange le moins d'utilisateurs pour cela), et il est exécuté commande par commande, manuellement, juste au cas où quelque chose deviendrait bizarre.Le problème le plus courant que j'ai rencontré est l'ajout d'une contrainte unique qui échoue en raison de lignes en double.

Lors de la préparation d'un cycle de tests d'intégration, je parcours ma liste de contrôle sur un serveur de test, comme si ce serveur était en production.Ensuite, en plus de cela, je vais chercher une copie réelle de la base de données de production (c'est le bon moment pour échanger vos sauvegardes hors site), et j'exécute les scripts sur une version locale restaurée (ce qui est également bien car cela prouve mon la dernière sauvegarde est saine).Je fais d'une pierre beaucoup d'oiseaux ici.

Cela fait donc 4 bases de données au total :

1. Développeur :toutes les modifications doivent être effectuées dans le script de modification, jamais avec studio.
2. Test:Les tests d'intégration ont lieu ici
3. Copie de la production :Pratique de déploiement de dernière minute
4. Production

Vous devez vraiment, vraiment bien faire les choses lorsque vous le faites en production.Il est difficile d’annuler les modifications du schéma.

En ce qui concerne les correctifs, je ne corrigerai que les procédures, jamais les schémas, à moins qu'il ne s'agisse d'un changement très isolé et crucial pour l'entreprise.

Answer 2

Je suppose que vous avez réfléchi aux lectures de Scott Ambler ?http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

C'est un sujet dont je parlais justement au travail.Le problème est principalement que, à moins que les migrations de bases de données ne soient correctement gérées par votre framework, par exemple les rails et leurs scripts de migration, cela vous appartient.

La façon dont nous procédons actuellement présente des défauts apparents et je suis ouvert à d’autres suggestions.

1. Ayez un vidage de schéma avec des données statiques qui doivent être maintenues à jour et sous contrôle de version.
2. Chaque fois que vous effectuez une action de changement de schéma, ALTER, CREATE, etc.videz-le dans un fichier et jetez-le dans le contrôle de version.
3. Assurez-vous de mettre à jour le dump de base de données SQL d'origine.
4. Lorsque vous effectuez des mises en ligne, assurez-vous que vous ou votre script appliquez les fichiers SQL à la base de données.
5. Nettoyez les anciens fichiers SQL sous contrôle de version à mesure qu'ils vieillissent.

Ce n’est en aucun cas optimal et n’est vraiment pas destiné à servir de base de données de « sauvegarde ».Il s'agit simplement de faciliter la vie et de garder les développeurs sur la même longueur d'onde.Il y a probablement quelque chose d'intéressant que vous pourriez configurer avec Capistrano en ce qui concerne l'automatisation de l'application des fichiers SQL à la base de données.

Un contrôle de version spécifique à la base de données serait vraiment génial.Il y a probablement quelque chose qui fait cela et s'il n'y en a pas, il devrait probablement y en avoir.

Answer 4

Et si l'article de Scott Ambler vous met en appétit, je peux vous recommander son livre avec Pramod J Sadolage intitulé "Refactoring Databases" - http://www.ambysoft.com/books/refactoringDatabases.html

Il existe également de nombreux conseils et informations utiles au sein du groupe Agile Database de Yahoo - http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

Deux notes rapides :

1. Il va sans dire...Je vais donc le dire deux fois.
   Vérifiez que vous disposez d'une sauvegarde valide.
   Vérifiez que vous disposez d'une sauvegarde valide.

2. @mk.Vérifier Article de blog de Jeff sur le contrôle de version de la base de données (si ce n'est pas déjà fait)