Les meilleures pratiques pour la gestion du changement avec des index

Question

Notre boutique informatique est tout d'abord commencer à construire un groupe de DBA. Chacun d'entre nous (moi y compris) sont venus du monde sur le développement d'applications / architecture, de sorte que le monde DBA est encore assez nouveau pour nous.

Avec la construction d'un groupe DBA, nous cherchons à changer de construction gérer les procédures et les processus (espérons-basés sur les meilleures pratiques) lorsque nous devons passer des changements.

Je l'ai trouvé suivant post qui est utile pour déclencher la plupart du temps, la procédure stockée et / ou des modifications DDL. Mais il ne les indices d'adresse pas nécessairement ou les bases de données de fournisseurs.

Nous avons un mélange des deux bases de données propres et nos fournisseurs. Dans notre cas, quelques-uns des fournisseurs (mais pas tous) travaillent avec notre société pour construire la base de données (s) et les applications. Nous sommes en train de tester les performances de nos applications maintenant avant « go live ». Ainsi, nous analysons les indices (ou l'absence de celui-ci) assez fortement.

Comme nous croisons les indices que nous pensons devrait être fait, comment pouvons-nous mieux faire face à la gestion du changement à l'égard de ceux-ci, tant pour nos propres bases de données, ainsi que pour les fournisseurs?

Que faites-vous dans votre magasin? Je suis inquiète moins sur les outils, puis sur le processus.

EDIT: Jusqu'à présent, je suis en appréciant les commentaires, les commentaires et les réponses à cette question. J'ai remarqué que certaines des réponses sont un peu spécifique outil. Je cherche des pratiques plus « agnostique », si cela peut être eu.

Cependant, si agnostique est impossible, pour des ensembles d'outils, nous utilisons IBM DB2 LUW (et qui en fait sur AIX) la plupart du temps. Nous avons quelques DB2 sous Windows et DB2 for i (i5 / OS d'IBM), mais nous sommes la plupart du temps AIX DB2. Nous utilisons contrôle de la source, en particulier Subversion.

Encore une fois, à la recherche de bonnes pratiques générales, mais surtout est ce que nous utilisons ce serait spécifique du fournisseur.

EDIT: Décision actuelle: Nous avons l'intention de suivre notre raisonnement ainsi que nos changements. Donc, nous allons ouvrir un problème dans notre numéro de suivi logiciel (qui dans notre cas est JIRA). Maintenant, nous pouvons ajouter dans la documentation à quelle priorité le changement a, des données qui sauvegarde ce que le changement devrait être, le changement, et les résultats du changement d'une autre environnement où le changement a été testé.

Nous avons ensuite l'intention aussi de garder une trace de nos changements dans les scripts dans SVN (Un peu comme a été suggéré ci-dessous). De cette façon, nous pouvons suivre la version de ce qui existe où. Cela peut être enregistré dans notre numéro de JIRA (et en tout autre utilisation du logiciel d'audit de nous, par exemple. liens). empâtées Nous pouvons savoir avec plus de certitude que le changement est allé à quel environnement et pourquoi. nous pouvons puis suivre également si l'indice était quelque chose, nous avons ajouté au-delà des vendeurs la mise en œuvre ou en avance sur leur mise en œuvre, etc.)

Answer 1

Je recommande fortement que vous traitez votre base de données essentiellement de la même façon que vous traitez votre code d'application. Vous pouvez créer un script sur votre base de données à ses parties composantes et vérifier les dans le contrôle source, puis utilisez les mêmes étiquettes et versions là-bas que vous utilisez pour vos applications.

Pour obtenir les objets dans le contrôle des sources, il y a un certain nombre d'outils que vous pouvez utiliser. Microsoft dispose d'un outil qui est surnommé Mec Data. Il fonctionne avec Visual Studio. Ils préparent aussi à libérer un nouvel outil appelé Outils de base de données SQL Server (SSDT), encore une fois, en collaboration avec Visual Studio. Mon entreprise, Red Gate Software, fait un outil qui fonctionne avec SSMS appelé SQL contrôle de code source.

En termes de processus, je l'ai écrit plusieurs chapitres du livre Red Guide porte au développement de l'équipe . Il est disponible en téléchargement gratuit (ou si vous voulez tuer un arbre, vous pouvez purcahse un d'Amazon). Je vais dans beaucoup plus de détails sur l'utilisation des bases de données dans les équipes de développement là-bas.

Answer 2

1. We maintain database scripts as part of our application codebase which is maintained under version control. However we use different "processes" for development and production code

2. Development we maintain the following scripts:

   • base.sql - creates the schema tables and sample data
   • stagingchanges.sql - makes changes to the base.sql for staging environment, mainly email addresses, paths and other assets which might change
   • prodchanges.sql - makes changes to the base.sql for a production deployment. For new projects we usually get to test these out in actual production environments

3. Maintenance

   • base.sql - a sanitized version of the production database
   • stagingchanges.sql and prodchanges.sql - as above
   • changerequest.sql (usually has the id of the change request) which applies any schema changes for the current change request we are working on
   • changerequest-rollback.sql - reverses the changes made for the change request and resets the database back to production
   • archive (folder) for previous change request scripts

So in maintenance mode all we need to do is apply the changerequest.sql script during deployment to production

Answer 3

Being in the database version control space for 5 years (as director of product management at DBmaestro) and having worked as a DBA for over two decades, I can tell you the simple fact that you cannot treat the database objects as you treat your Java, C# or other files.

There are many reasons and I'll name a few:

• Files are stored locally on the developer’s PC and the change s/he
  makes do not affect other developers. Likewise, the developer is not affected by changes made by her colleague. In database this is
  (usually) not the case and developers share the same database
  environment, so any change that were committed to the database affect others.
• Publishing code changes is done using the Check-In / Submit Changes / etc. (depending on which source control tool you use). At that point, the code from the local directory of the developer is inserted
  into the source control repository. Developer who wants to get the
  latest code need to request it from the source control tool. In
  database the change already exists and impacts other data even if it was not checked-in into the repository.
• During the file check-in, the source control tool performs a conflict check to see if the same file was modified and checked-in by another developer during the time you modified your local copy. Again there is no check for this in the database. If you alter a procedure from your local PC and at the same time I modify the same procedure with code form my local PC then we override each other’s changes.
• The build process of code is done by getting the label / latest version of the code to an empty directory and then perform a build – compile. The output are binaries in which we copy & replace the existing. We don't care what was before. In database we cannot recreate the database as we need to maintain the data! Also the deployment executes SQL scripts which were generated in the build process.
• When executing the SQL scripts (with the DDL, DCL, DML (for static content) commands) you assume the current structure of the environment match the structure when you create the scripts. If not, then your scripts can fail as you are trying to add new column which already exists.
• Treating SQL scripts as code and manually generating them will cause syntax errors, database dependencies errors, scripts that are not reusable which complicate the task of developing, maintaining, testing those scripts. In addition, those scripts may run on an environment which is different from the one you though it would run on.
• Sometimes the script in the version control repository does not match the structure of the object that was tested and then errors will happen in production!

There are many more, but I think you got the picture.

What I found that works is the following:

1. Use an enforced version control system that enforces check-out/check-in operations on the database objects. This will make sure the version control repository matches the code that was checked-in as it reads the metadata of the object in the check-in operation and not as a separated step done manually
2. Use an impact analysis that utilize baselines as part of the comparison to identify conflicts and identify if a change (when comparing the object's structure between the source control repository and the database) is a real change that origin from development or a change that was origin from a different path and then it should be skipped, such as different branch or an emergency fix.

An article I wrote on this was published here, you are welcome to read it.