Deploying Database Changes in Your Continuous Delivery Pipeline with Redgate ReadyRoll and Visual Studio Team Services

Managing database schema changes has always been challenging.  Keeping track of what scripts to run in what order and getting database states just right in all the different environments is painful and error prone.  However, there are some fantastic tools from Redgate which help us manage our database changes as well as creating a fully automated Continuous Integration and Continuous Delivery pipeline. ReadyRoll Core, SQL Prompt Core, and SQL Search are tools from Redgate that are included in each copy of Visual Studio Enterprise 2017 or in the Redgate SQL Toolbelt.  Using these tools, you can commit your database schema changes right alongside your source code in the same repository.  You can also seamlessly deploy these schema changes to the databases in all your environments in an automated manner.

ReadyRoll Core is a migrations-driven approach to database schema management.  Being migrations driven means we can now shift the creation of database deployment scripts to the left so that these migration scripts can be source controlled and tested early for fast feedback.  This gives developers more control over exactly how database changes will be deployed to the different environments.

We will walk through creating a ReadyRoll project, making schema changes to your database, and building out a CI/CD pipeline pushing your database schema changes to your different environments using Visual Studio Team Services.

Creating a ReadyRoll Visual Studio Project and Importing Schema from a Database

The first thing we need to do is verify that we have Visual Studio Enterprise 2017 with the “Data storage and processing” workload installed.   Make sure the three Redgate tools are checked (Redgate ReadyRoll, Redgate SQL Prompt, and Redgate SQL Search).

01

Next, let’s create our database Visual Studio project.  Usually, this project would sit in the same solution as the one holding your source code for your project.

  1. File > New Project , SQL Server > ReadyRoll SQL Server Database Project

    02

  2. This creates your ReadyRoll project

    03If you don’t see the ReadyRoll window, you can open it by clicking ReadyRoll > ReadyRoll

    04

Next, let’s assume we have a database that already exists and we want to import the schema into our ReadyRoll project.  Alternatively, we can start from a completely blank schema and build up our schema through the ReadyRoll project as well.

  1. Because my source database is in SQL Azure, I want to create my working databases locally so I can work quickly and offline if needed. Right click the ReadyRoll project and select properties

    05

  2. This opens up the project properties tab.  Click on Debug

    06

  3. Scroll down and check Always use default connection string for Shadow database

    07

  4. Click Save All

    08

  5. Click Connect to database button in the ReadyRoll window

    09

  6. This opens up the Connect dialog, enter in the credentials necessary to connect to your database.  In my example, I’m going to connect to an SQL Azure database named bikesharing-services-ridesname_prod on the database server bikesharing-services-dbserver.database.windows.net.  After entering credentials, click OK

    10

  7. Click Import database

    11

  8. Wait for import to finish

    12

  9. Click on Refresh (Verify Script)

    13

  10. This verifies the migration script works correctly on the shadow database.  Notice how there is now a big green check mark

    14

  11. Notice how a new migration script has been added.  The name of the script should be in the format of 0001_YearMonthDate_SomeNumber_username.sql

    15

  12. Let’s change the name of the migration script to be 0001_Initial_Schema.sql.  This will make the migration script name more readable and descriptive.

    16

After importing the initial schema from our “production” database, let’s point our database project back to the local db instance

  1. Click on the Home button in the ReadyRoll window

    17

  2. Click on Configure database connection link in the ReadyRoll window

    18

  3. This brings up the Connect dialog, connect to your local instance of your database and click OK

    19

  4. Click Deploy to deploy the initial schema to the local instance of your database

    20

  5. Wait for the deployment to finish

Preparing Deployment Databases for ReadyRoll

In this example there are two target deployment environments.  A Dev environment and a Prod environment.  Both the databases are hosted in Azure and the Dev database is called bikesharing-services-ridesname_dev and the Prod database is called bikesharing-services-ridesname_prod.  We have already imported the database schema from the Prod database, so we don’t have to do anything more with the prod database.  At this moment, the Dev database has the same schema as the Prod database.  We just need to prepare the Dev database for ReadyRoll.

  1. Click on Configure database connection

    21

  2. This brings up the Connect dialog.  Enter in the credentials to your Dev environment database and click OK

    22

  3. Notice how we are now connected to the Dev environment’s database

    23

  4. Double click the 0001_Initial_Schema.sql migration script to open the migration script.  Notice how the Script status window shows the Dev database.  Click on Mark as Deployed.  This step ensures that the Initial_Schema migration script will not be ran against the Dev database in future deployments since it already matched the Prod schema.

    24

Now, let’s connect ReadyRoll back to the local instance of the database that will do all our future development work against.

  1. Click on Configure database connection

    25

  2. This opens the Connect dialog, enter in the credentials for your local database instance and click OK.

    26

  3. Double click the 001_Initial_Schema.sql migration script to open it.  Notice how the Script status window says this migration script has been deployed to your local database instance.

    27

Making Changes to the Database Schema

You can use whatever tool you want to change the schema of your local database.  ReadyRoll Core will then look at the changes and will create and add a migration script to your ReadyRoll project.  In this example, I’ll use SQL Server Data Tools (SSDT) to change the schema of my local instance.  I’ll add an extra column (LastServicedAt) to my local dev instance of my database.  ReadyRoll Core will detect those changes and will create and add a migration script to my project.  I will then manually tweak the update script so that it initializes the LastServicedAt column with data from the InCirculationSince column.

  1. In SQL Server Object Explorer, browse to your local database instance.  In this example, I right click the dbo.bikes table and select View Designer

    28

  2. In the table designer, I add a column LastServicedAt as a datetime2(7) and then click Update

    29

  3. This opens the Preview Database Updates dialog.  Click Update Database to apply the schema change to my local database

    30

  4. Click on the ReadyRoll Core Edition tab to open the ReadyRoll window

    31

  5. Click on Preview objects pending Import button

    32

  6. ReadyRoll Core will now compare the schemas between your local dev instance and the shadow database.  Notice how ReadyRoll Core detected the changes I did to the bikes table.  Double click the row with the change to see the detected difference by ReadyRoll Core.

    33

  7. Click on Generate scripts for all database changes that are pending import button

    34

  8. ReadyRoll Core creates and adds the migration script for you.

    35

  9. If we wanted to tweak the script in anyway, we can just go and change the SQL in the migration script.  In this example, let’s go ahead and initialize the LastServicedAt column so that it is equal to InCirculationSince.  On line 9, I’m going to add the update SQL and then save the migration script.  I’ll go ahead, highlight those two lines and click on run so that I update my local dev database

    36

  10. Click on Refresh (Verify Script) to verify the migration script

    37

  11. Notice how after the verification we get a big green check.  Now let’s click on Mark as Deployed to mark this second migration script as deployed to the local dev instance

    38

  12. Change the name of the 2nd migration script to be 0002_Add_Last_Serviced_At_Column.sql to make it more readable.

    39

  13. Commit all of your changes into your Visual Studio Team Services repository.

I changed the schema using SQL Server Data Tools in Visual Studio.  I want to reiterate that you don’t have to use SSDT.  You can use whatever tool you want to update your local development database, including SQL Server Management Studio (SSMS).  ReadyRoll Core will compare the schema between your local developer database and the shadow to create and add the correct migration scripts to your project.

Setting up your Continuous Integration and Continuous Delivery Pipelines

Setting up your continuous integration pipeline in Visual Studio Team Services for ReadyRoll migrations is straightforward when using the Hosted VS2017 Agent.  Everything just works.

image

ReadyRoll Core will need the database server (TargetServer), the database name (TargetDatabase), the Database user name (TargetUserName) and the password to the database (TargetUserName).  ReadyRoll Core will use these variables to create the right scripts.  For this example, I used my Dev database values.  Next, ReadyRoll Core will also need to create a shadow database so we will need to pass in the shadow database name.

Create a new build using the Visual Studio solution template.  In the build, add the following variables

40

Then in the task list, add a task to create the shadow database using the Command Line task.  Set Display name to Setup  Shadow DB.  Set Tool to C:\Program Files\Microsoft SQL Server\130\Tools\Binn\SqlLocalDB.exe.  Set Arguments to create $(ShadowInstanceName) –s

41

Next, in your Visual Studio Build task, add the following MSBuild Arguments:

/p:TargetServer=”$(DatabaseServer)” /p:TargetDatabase=”$(DatabaseName)” /p:TargetUserName=”$(DatabaseUserName)” /p:TargetPassword=”$(DatabasePassword)” /p:ShadowServer=”(localdb)\$(ShadowInstanceName)” /p:GenerateSqlPackage=True /p:SkipDriftAnalysis=True

42

Make sure the build uses the Hosted VS2017 agent and queue a build.  My build artifacts looks something like this

43

Setting up your release to deploy your schema changes is straight forward as well.  Just use the Deploy ReadyRoll Database Package task. Enter in the path to the ps1 script that is created.  Enter in the release version, the target SQL Server Instance, the Target Database Name, the Username and also the Password

44

Because I’m using environment variables, make sure you set your environment variables to the correct environment values

45

Now my deployments will deploy my schema changes to the different environments

46

There are many benefits to using a migration based approach to database deployments.  The biggest is that by shifting your database deployment scripts to the left, developers now have much more control over exactly how database changes will be deployed.  These migration scripts are also tested early for fast feedback.  Redgate ReadyRoll Core makes this entire process seamless for developers in Visual Studio and Visual Studio Team Services.  Migrations are checked in and out of source control right alongside the actual source so that both the source and schema is versioned together.  CI and CD can easily be set up with pre-built tasks from Redgate that build and deploy database schemas using these migrations.

If you are interested in creating a Redgate ReadyRoll demo like what was shown in the Visual Studio 2017 Launch event, there is an in-depth walkthrough published here.

Leave a Reply

Your email address will not be published. Required fields are marked *