Build a VM Test Lab using Unraid - Working From Home Part I
Understanding how hypervisors work is key to setting up a test lab on a home server. In this article, read about lessons I learned setting up a VM test lab on Unraid.
Everything written on this site is how to get a database change automatically pushed up through the environments. But that was for the entire database. There are some parts of the database where they shouldn't be put under source control or shouldn't be promoted. Now you are probably thinking, "that doesn't make a whole lot of sense, I should always deploy the entire schema all the time." First off, Mr./Mrs. hypothetical reader, that is a very extremist view, secondly, there are instances where deploying the entire schema shouldn't happen.
Below are some of the scenarios I have run across since I started automating my deployments.
Redgate's SQL Source Control has this covered. It is possible to create a filter using the GUI. This filter will then be saved in the version control repo as a .scpf (SQL Compare Filter) file. That file will be read by their DLM automation tooling when deploying a database change and exclude those items from the deployment.
Fun Fact: The .scpf file is nothing more than an .xml file. Once you know the schema you can easily modify it without using the SQL Source Control GUI. Just be careful and test the changes.
The most common scenario I have run across is excluding tables in a specific schema or if they match a certain naming standard. These tables are typically created for a backup or for testing. My advice is work with your team on establishing a standard everyone is familiar with. The easiest for my team was placing all the tables in the test schema and excluding any table in the schema. The schema itself would be checked into source control, just not any tables in that schema.
In this example, we will be creating a backups schema and excluding any table found in that schema from source control.
The filtering engine supports a lot of different ways to create a filter. For tables alone, you can filter by the following
The name comparison supports the following options
The filters can get fairly complex using a combination of ORs and Ands.
The GUI makes it very easy to build out as complex or as a simple filter as you would like.
This is a very easy to use feature in Redgate's SQL Source Control, but it is very powerful. It provides you and your team the necessary flexibility to exclude items you don't want as part of your automated database deployment pipeline. Without this feature, I don't think it would be possible for Farm Credit Services of America to implement automated database deployments without having to jump through some serious hoops.
I want to finish up with a story. When I put a legacy database into version control it was filled with a lot of backup tables and test tables. I did not want to delete those tables (I dislike "the look" from QA), I couldn't just move them without having the QA person update a lot of their tests. But, that database needed to get into source control. I ended up creating a rather complex filter to exclude out all the unwanted tables. RedGate's SQL Source Control and DLM Automation Suite handled it like a champ.