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.
Related
I have two environments, development and production. Each one of them has 2 databases, one main database and another that is used as an external data source.
Currently I'm trying to create a github deployment pipeline, I use SSDT to do source control and I have the actions for building the .dacpac and sending it to Azure working. How can I configure so that when in production the database looks to external source of prod, instead of the same external source as dev, when I deploy changes to production?
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 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 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.
In Visual Studio 2010 there is a nice feature of the database project that allows you to deploy to a database as well as set up various environments based on your configuration (Build deploy etc)
I Would like to integrate this into our automated build environment.
Firstly by having the deploy script run after a successful build on my local machine. (So I can go straight into running the unit tests)
Then by Having the deploy script run after the successful build on our build server. so that any schema changes required for the unit and integration tests will run.
How can I adjust the MSBuild or similar to run these in deploy mode.
Use the MSBuild task to call the "dbproj" file. Pass "DBDeploy" as the target and the build configuration as a property, e.g.:
<MSBuild Projects="MyDb.dbproj"
Targets="DBDeploy"
Properties="Configuration=$(Configuration)" />
On a build server, you might also need to supply properties like TargetConnectionString and TargetDatabase.