Pouvez-vous créer un script de déploiement généralisée d'un projet Sql Server Db dans VS 2015 qui ne nécessite pas un schéma comparer/publier sur une base de données cible spécifique?Création d'un script mise à jour générique/installation à partir d'une base de données Sql Server Project
Un peu d'histoire:
Nous utilisons Sql Server Database projects pour gérer notre schéma de base de données. Principalement, nous utilisons les projets pour générer des dacpac qui sont poussés vers nos environnements de développement. Ils s'habituent également aux nouvelles installations de notre produit. Récemment nous avons développé un add-on pour notre produit et nous avons créé un nouveau projet db pour celui-ci, référençant notre projet de base. Pour les nouvelles installations de notre produit où les clients veulent l'add-on, notre nouveau projet sera déployé.
Le problème que nous avons est que nous devons être en mesure de générer un script de mise à niveau "générique". La plupart de nos installations existantes n'ont pas été générées via ces projets et toutes contiennent de nombreuses procédures stockées "custom"/etc spécifiques à l'installation de ce client. Je cherche un moyen de générer un script qui ferait un "If Not Exists/Create + Alter" sans avoir besoin de spécifier la base de données cible.
Notre projet complémentaire ne contient que des procédures stockées et quelques tables, qui seront toutes nouvelles pour les clients qui optent pour ce module. Je dois éviter de laisser tomber des éléments qui ne sont pas dans le projet tout en étant capable de déployer tous nos nouveaux "trucs". J'ai trouvé l'option Include Composite Objects que je peux décocher pour que le déploiement soit spécifique à notre module, mais la publication nécessite encore que je spécifie une base de données cible afin qu'une comparaison de schéma puisse être effectuée et que je reçoive des scripts spécifiques cette base de données particulière. J'ai joué avec pratiquement toutes les options et je ne trouve pas de solution.
Bottom Line: Y at-il un moyen pour moi de générer un script générique que je peux donner à mon équipe de déploiement chaque fois que l'add-on est demandé sur une installation existante sans avoir besoin de faire un schéma ou de publier pour chaque base de données directement à partir du projet?
Actuellement, je gère un ensemble distinct de fichiers .sql dans notre projet (non db) suivant le paradigme if not exists/create+alter qui correspond aux éléments du projet db. Ceux-ci sont concaténés lors de la construction de notre addon afin que nous puissions donner à notre équipe de déploiement un script à exécuter. Cela s'avère lourd et nous aimerions pouvoir utiliser les projets de base de données pour cela, si possible.
Pourriez-vous mettre vos objets "complémentaires" dans un projet séparé, avec une référence à votre projet principal? Maintenir une base de données "propre" et générer le script "add-on" contre cette base de données propre. Il devrait générer seulement les instructions Create. Si vous avez besoin d'Alters, il est peut-être préférable que l'équipe de déploiement exécute SQLPackage pour générer les scripts.Vous pouvez créer un fichier batch pour le faire assez facilement. Il suffit de leur donner les dacpacs mis à jour et le processus est le même - script de génie, revoir si nécessaire, exécuter. –
Il est déjà dans un projet séparé avec une référence comme vous le suggérez. Cette approche pourrait fonctionner mais si jamais nous avions besoin de mettre à jour l'une des procédures stockées (correction d'un bug par exemple) cette approche ne fonctionnerait pas, c'est pourquoi je suis à la recherche d'altérations. Je ne suis pas familier avec SqlPackage, je vais devoir y jeter un coup d'oeil. – pinkfloydx33
Fondamentalement, vous donnez les dacpac à vos installateurs. Ils exécutent SQLPackage (peut-être à travers un fichier de commandes ou PowerShell) pour pointer sur le serveur/DB pour mettre à jour. Cela générerait alors le script ou la mise à jour directement. On dirait qu'ils ont déjà accès aux serveurs, ils devraient pouvoir le faire. SQLPackage doit également être inclus sur les serveurs ou il peut être exécuté localement pour le programme d'installation tant qu'ils peuvent voir la base de données cible. Cela pourrait aider: https://schottsql.wordpress.com/2012/11/08/ssdt-publishing-your-project/ –