Comment gérez-vous vos scripts d'installation une fois SQL dans subversion?

Question

Je travaille dans une entreprise qui produit plusieurs versions en production chaque année et pendant la construction de chaque version, nous rassemblons une collection de scripts d'installation 1 fois sql comme la création de table et les ports de données.

La façon dont les choses fonctionnent actuellement est qu'après la sortie en production, nous branchons, tag alors nous supprimons tous les scripts 1 fois de subversion.

Cela semble faire le travail, mais pour moi, cela n'a jamais semblé la bonne façon de résoudre le problème. Pourriez-vous imaginer supprimer tous vos codes source à chaque publication, puis écrire des correctifs pour la production? Les inconvénients que je vois est si vous voulez référencer et l'ancien script vous devez extraire une étiquette ou une branche de subversion.

Notre SVN repo semble actuellement quelque chose comme ça

svnrepo/monsite/src svnrepo/monsite/base de données/storedprocs svnrepo/monsite/base de données/installscripts

Je pensais que d'une manière plus précise à modéliser ce que nous voulons faire dans SVN est la suivante.

Utilisez un attribut svn: externals pour pointer vers la dernière version. Ensuite, après chaque sortie, dirigez-vous vers la dernière.

svnrepo/monsite/trunk/src/ svnrepo/monsite/trunk/src/base de données/installscripts/ -> svnrepo/monsite/trunk/base de données/Release_3

svnrepo/monsite/trunk/base de données/Release_1 svnrepo/monsite/trunk/base de données/Release_2 svnrepo/monsite/trunk/base de données/Release_3

en utilisant ce modèle, nous ne supprimons plus svn les scripts sQL et permettent à un développeur de base de données pour vérifier svnrepo/monsite/trunk/base de données/et voir facilement tout le développement de base de données qui s'est produit.

Avez-vous des commentaires sur mes idées, la structure actuelle ou la meilleure façon de gérer cette situation?

Merci

Answer 1

changements synchronisation de bases de données et les changements de code dans la subversion est difficile

Si vous avez la possibilité de construire la base de données à partir de zéro, vous pouvez mettre l'ensemble DDL dans le référentiel avec le code, vous n'avez pas besoin de vous soucier des changements qui vont avec quelle version. En regardant votre situation, je ne pense pas que vous ayez besoin d'utiliser des externes (ils peuvent causer des maux de tête). Vous n'avez pas non plus besoin de tout supprimer. Il n'est pas trop difficile de vérifier une branche (ou vous pouvez simplement utiliser un navigateur de référentiel).

Vous pouvez même placer les anciennes versions de db dans une balise distincte lorsque vous les lâchez afin qu'elles se trouvent toutes au même endroit, ce que les personnes de la base de données peuvent avoir extrait. Si vous faites des libérations une fois par an, ce ne sera pas difficile.

This question may also help