问题
I am trying to automate existing sql server database deployment automation using Jenkins.
One of the ways to automate is to include the SQL scripts (stored procedures, views, table creation) in a SQL server Database project using Visual Studio. Use MSBuild to build the project and deploy dacpac using SQLPackage.exe. However, the existing database has reference to other databases inside Stored Procedures/Views so I have import other databases inside the SQL Server Database project. Additionally, I am getting a lot of errors when extracting dacpac of existing databases. I assume this is due to existing code is not dacpac compatible and may require changes to be dacpac compatible.
Is there any other way to automate SQL server code deployment instead of using SQL Server database project?
回答1:
An alternative to SSDT model-based projects is a migration script approach as discussed here.
Model based deployments need to validate dependencies during build, else you would run the risk of errors during deployment. Unfortunately, I know of no easy way to create a dacpac for other referenced databases that aren't dacpac-friendly without going through the effort of creating separate projects for referenced databases built from source. You could create a database project for referenced databases and use the SSDT import wizard to extract database the schema for the project source code and clean up the solution.
The complexity of this task will vary considerably depending on the number of cross-database and cross-server dependencies you have. It may be necessary to split databases into separate projects in order to avoid circular references.
回答2:
SSDT is a good option, however it will take a while for you and all developers to get used to it and understand what is offline development and state based deployments. You can read how SSDT works by yourself, however there are few advice for you:
- For every database involved into your queries you need to create project
- If you use other database in the code, then this project is supposed to be added as a reference
- Instead of having 3/4 part names in the code (server.database.schema.name or database.schema.name) create synonyms for every single object and in the synonym use variables for the server and database names
- Don't put logins, users and permissions into that project
- Create publish profiles and take a look to all settings carefully (for example exclude users, logins, permissions and so on from deploying)
- There are pre/post scripts where you can create some workarounds
Mostly people afraid of fully automated deployment to PROD using SSDT as the script is generated automatically and there is only very limit control on the final deployment script (to be fair, you can control pretty much everything using deployment contributors, but it is the topic of another discussion). Usually there is script review step between script generation and the deployment.
So, if you'll stick with SSDT the roardmap for you is:
- Create projects for all databases used in the code
- Create synonyms for all the objects in the project that are from other database with variables as the database and instance names (very important point)
- Use replace across multiple files for all the external database and instances
HINT for replacement. There are several combinations of the object names in the code:
- INSTANCE.DATABASE.SCHEMA.OBJECT
- INSTANCE.DATABASE..OBJECT
- INSTANCE...OBJECT
- All other combinations with [] or "", for example [dbo].[SomeTable] or [dbo].SomeTable
So what you can do is to replace INSTANCE with $(InstanceName) across of all files, the [Database] with [$(DatabaseName)] and so on. Be creative and basically when you know what to do you can put pretty much any db to the SSDT in few hours with these tricks.
来源：https://stackoverflow.com/questions/56289174/sql-deployment-automation