Database Projects – Making changes – Feature Branching

In my previous blog post about Database Projects: “Getting started with Database Projects and Version Control”, I explained how to set up a database project and connect it to Azure DevOps Repos. In this blog post, I will be focussing on how you can start development.

Quick Overview

What about branching?

Feature branching

How to get started?

Get started by example

Create a new feature branch

Making changes

What about branching?

Depending on how you have defined your branching strategy, you will start development differently. Below I’m defining a few different branching strategies:

1. No branching
2. Branching/environment
3. Branching/feature
4. …

In the past, I have used all of the above. I need to tell you that the Branching/feature strategy allows me to be the most flexible for database development. Why? Let’s dive into this method for now:

Branching/feature

How to get started?

When applying branching per feature, you will create a new branch for every feature you’re developing. What is important, is to create a new branch from the main branch (often referred to as the master branch as well). Starting from the main branch is essential to be able to keep full flexibility during release cycles.

Pros

+ flexible way of working when priorities change
+ code changes bundled by feature

Cons

– branch maintenance
– greater chance on merge conflicts

Get started by example

For this example, we will use the AdventureWorksDW2019. We are going to add a dutch description into the Product Dimension.

To get started we will first create a new branch based on the master branch, to do this you can execute the following steps in Visual Studio:1. Open your Database Project in Visual Studio.

Create a new feature branch

1. Create a new branch by opening the GIT pane in the Toolbar and choose New Branch…

2. Create a new branch based on the master branch named: feature/demo-ticket-1

As soon as you have confirmed, GIT will pull in all changes from the origin/master branch and create a new branch feature/demo-ticket-1 on your local machine.

To validate your created branch, look for the following in Visual Studio (hint: take a look at the right bottom corner of Visual Studio):

Making changes

As already mentioned, for this example, we will be making a change to the product dimension. To do so, we navigate to the Solution Explorer, open the Tables folder, navigate to DimProduct and click on the DimProduct.sql file. As a result, you should see something like:

Navigate to the preferred location where you want to create the new column named: DutchDescription.

For now, we will add the Dutch description at the end of the SQL file, just before the definition of the constraints, like this:

The column will be added to the existing table and during the publishing step by following generated code: (don’t worry about this, we will get to publishing in the end)

PRINT N'Altering Table [dbo].[DimProduct]...';

GO
ALTER TABLE [dbo].[DimProduct]
    ADD [DutchDescription] NVARCHAR (400) NULL;

When we would add the column in the middle of the DimProduct.sql script, a change script will be generated which will:

1. drop all constraints referring to your table (DimProduct in this case)
2. creating a temp table with the new table structure
3. inserting existing data in the temp table using IDENTITY_INSERT
4. drop the existing table (DimProduct)
5. renaming the temp table to the original table (DimProduct)
6. adding defined constraints

After we have made our change locally in Visual Studio and it is time to commit our changes. To do so, we need to navigate to the Git Changes section in Visual Studio.

You can navigate to this tab via

By doing this you will see the following result:

Tick the + sign to stage the change, write a proper commit message and hit the arrow next to Commit Staged:

As soon as you hit the arrow, choose “Commit Staged and Push”

As a result, you will receive a message like:

At this point, we have successfully developed our feature, and we can now continue by pushing our change to the development environment.

Wondering how to merge your change to your development branch? Find out in my next blog post: Database Projects – Merging changes.