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?
Related
I have an SQL Server Project as a part of my solution in Visual Studio. It requires that I include some stored procedures that access a different database on the same server. This database is not under our control, nor is it accessible locally to the developers, or in our dev Server. And we cannot import that database because its a few TB in size. The functionality represented by this stored procedures does not need to be called in our dev environment, and only has testable data in the staging and production environments where the other database is accessible.
When we attempt to publish the project to our dev servers, or locally, the publish script generated by VS fails at run time because SQL Server can't generate a stored procedure if it can't resolve the references to the missing database.
I am looking for a way to setup the publishing so that it is selective based on the ##servername variable (ideally, but I am open to other realistic scenarios, such as a way to tell the SQL Server not to try to resolve those references)
Thanks
P.S. I hadnt thought of mentioning it until #larnu's comment, but an additional thorn here is that our dev environment is hosted as an Azure Web app and using an Azure SQL Database server. Even if I created a Mock database for the missing reference, Azure SQL will not allow my stored procedures to see them.
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.
I am looking for a means to use Git deployment on Windows Azure together with either their MySQL or other database solutions.
I need a means of migrating database schema changes as part of deployment - does Azure provide support for this without using Visual Studio or .NET.
You basically want to use Azure as a Continuous Integration (CI) platform and my view is that Azure by itself just isn't there yet.
A basic git based CI scenario would involve the following steps.
Your src code and any database schema/data updates are pushed to a central git repository like GitHub. [Feature available]
GitHub would then push the updates to Azure. [Not supported in Azure until they support GitHub hooks]
Azure compiles and deploys the code. [Supported]
Azure updates the database from sql files pulled from the repo (remember, this needs to be automated). [Not supported]
Azure reports any error in running the database or web application. [Supported]
Azure runs user provided integration tests to check more thoroughly specific functionality and reports the status of those tests to the user [Not supported].
Azure allows you to roll back to a previous deployment snapshot [Partly supported. Snapshots are not based on git commits for instance].
I might be wrong on some of those points or new features might be added since I've written this. Corrections are very welcomed and I'll try to update the list accordingly.
I am not sure how much experiences you have with Windows Azure Websites, however when you are creating a Windows Azure Websites, you have ability to use SQL Azure Database or MySQL cloud database directly integrated with your Windows Azure Websites.
So if you will use SQL Azure Database then there are several ways you can migrate your DB following the link here:
Migrating Databases to Windows Azure SQL Database (formerly SQL Azure)
To manage MySQL you can use Local Web Server to do it. The way I have done is to use PHP, the MySQL Command-Line Tool (part of MySQL), and a web server set up on my local machine, and that I have enabled the PDO extension for MySQL. This way I can manager my MySQL directly from my own local machine and the details are explain at the bottom of this article:
Create a PHP-MySQL Windows Azure web site and deploy using Git.
Also the SQL part you can write in Workbench if you use MySQL and Oracle SQL Developer if you use Oracle SQL.
Finally Git Deployment allows you to deploy your any kind of application directly to Windows Azure without using VSx.
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.