We have recently migrated to using the Visual Studio database projects. What we want to do is for the database to deploy when the TFS build server builds.
This is relatively simple and we have this working for a single database, however, what we need is for it to deploy to multiple database as we have a SaaS product with multiple databases. So for example, when we do a QA build, all the different databases with various configurations on the QA DB server should be updated.
Is there a 'proper' way to do this?
Our current plan is to take the deployment .sql script that will be generated from the database configured for deployment, then create a custom build task which runs this script against the rest of the databases.
I don't think there is a standard way of doing this, so we created a custom build task that iterates over the databases we want to deploy to executing the deployment script generated by the standard database project's deploy against each DB.
Related
I have a database for which I created a database project using visual studios.
I have created an Azure Repo and built it using Azure Build Pipelines.
I want to create a release pipeline for the same and deployment group to connect to the server.
My concern is I have multiple databases on the database server and I don't want them to get affected due to the deployment.
As far as I know the changes should affect only the concern database and not other databases.
Am I right or the TSQL scripts created will affect other databases too ?
If you deploy a single database it only your sql script/dacpac affect only this one database. However, if they are on the same server, your deployment may have some impact on other databases as resource utlization may increase during deployment.
Database - SQL Server
Version control - GIT/Bit bucket
Automation - Jenkins pipeline.
Question/task - I need to build SQL database project & deploy thru jenkins pipeline.
Currently we manually build & publish the database but I have scripts which I can use to build(dacpac) & publish to the database but problem scripts only work in VS(visual studio) command prompt.
Build SQL database project thru Jenkins - Is it possible, if so how?
Publish SQL database project thru Jenkins - Is it possible, if so how?
Please help me understand the process involved.
I used the DacFx API provided by Microsoft and created an API service that I integrated with jerkins. In the middle of the pipeline, I passed the SqlProject location, my target database information, and dacpac destination. The API uses Publish Method to Deploy and generate the delta and deploy it to the target database.
See the link below.
https://www.nuget.org/packages/Microsoft.SqlServer.DACFx
I am working on creating a visual studio database solution so that i could deploy databases in a more managed manner. Following are the steps that i performed after adding some sample tables and SPs in the solution.
Deploy the database to my local machine (and a new database is created).
Add some mock data to the tables in SSMS.
Add couple of columns to one of the tables in the VS 2010 solution.
Build the solution and deploy the database again (this time it deploys only the changes made to the schema).
Verfiy that the existing data was intact and new columns have been added to the table schema.
Everything is working as expected till this point.
Now I delete the database manually which was created by the deployment.
Go to VS 2010 and deploy the solution (expecting that it should do a clean deployment of the database), however i get the following error :
------ Deploy started: Project: MyDatabase, Configuration: Debug Any CPU ------
Pre-Deploy: Starting script execution…
Pre-Deploy: Finished script execution.
MyDatabase.dacpac(0,0): Error :
-->Cannot upgrade the DAC for database MyDatabase, a database with that name does not exist. Specify a valid database name.
Is there any setting in my solution where i could specify that the deployment should do a clean install if the database does not exist?
Or
Do i need to write separate (database creation) scripts if the database does not exist?
I ran into this issue as well. I deleted the database and could not deploy again. Then I found this link. DAC application needs to be deleted in the SQL Server Management Studio.
http://msdn.microsoft.com/en-us/library/ee240822.aspx
To Delete a DAC application
In SQL Server Management Studio connect to the database
Expand the Management node.
Expand the Data-tier Applications node.
Right-click the DAC to be deleted, and then select Delete Data-tier Application…
Complete the wizard dialogs:
I deleted the application and was able to deploy again. I am still learning that DAC is application.
I am running SQL Server 2012 and VS 2010 with SSDT (SQL Server Data Tools) installed. My dev DB uses stored procs, functions, CLR objects, etc. It has a snapshot of prod data of about 500GB.
I created SQL Server Database Project and then imported the database. This created all tables, views, procs and functions files under schema names. Great stuff -- now I can do a version control just like in other VS projects, create deployments, etc. So far, so good.
But, I am confused as to what my development process should be for changing/adding procs/tables under SQL Server Database Project. It appears that any changes I make are applied to some LocalDb/Projects database and NOT to my dev database.
Am I suppose to author all my objects in that LocalDb, then Build and deploy to my dev database via Publish? I am worried about my existing tables in the dev DB since if the publish process drops and recreates tables, I will loose my prod data snapshot.
What is the right development process to follow in SQL Server Database Project?
Think of the source database (in your case, your database project) as being the "to be" state after deployment. When a deployment is initiated, the executable (SqlPackage.exe) compares the source with the target and generates a difference/delta script to make the target look like the source. This is why we no longer have to specify CREATE or ALTER; the tool figures it out. To answer your question about ongoing development, you can develop either way. You can develop in the project files and publish them to a common Dev database (say, if you're on a team), or you can develop in the database with tools like SQL Server Management Studio (SSMS) and synchronize with the project files with a schema compare (I use the latter technique because I like SSMS).
For deployment, you'll have to have SSDT installed on the machine from which you execute the deployment (SSDT ships with SQL Server 2012 and later; I don't know about SQL Server 2008). You can create scripts to simplify deployment. You'll essentially call SqlPackage.exe (it lives in x:\Program Files (x86)\Microsoft SQL Server\nnn\DAC\bin) with an action and a source. I use Publish Profiles as well to take care of most command properties. So an example deployment might look like this:
SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml
For more information:
SQL Server Data Tools Documentation
http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx
SqlPackage.exe Documentation
http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx
Make changes inside the VS DB project.
Deploy changes to localDB to test
Publish the database to your production server. I prefer to use Schema Compare to do this manually, but you can also publish the project via the right click --> publish menu (which will also create a publishing profile), or using command line arguments. The publish process won't drop and create tables (unless you tell it to drop & recreate the entire db).
Alternatively, in the project settings you can change the connection string to point to your production server (as pointed out in the comment). However, I recommend against this, as it will then attempt to publish to the production server every time you run a local build (F5).
We have a system consisting of a winforms client, a bunch of web services, a bunch of reporting services reports and a database with a corresponding database project in VS 2010.
We use TFS as source control system and for automatic builds etc.
When our tester queues a new build from within the Build Explorer, our client and server is build and the server is deployed to the web server. Reports and database changes are not deployed automatically.
Is it possible to have the changes from the database project deployed automatically to the test database whenever a new test build is queued?
Yes.
Your build template can invoke VSDBCMD.exe to do a comparison between your database project (.dbschema) and your test database in order to generate and execute a script that will update your test database.
Here is info about VSDBCMD.
Here is the procedure to setup your build template to use VSDBCMD.