Deploy from Source Control

dbForge Source Control is designed to streamline database change management among multiple developers within a team. The tool provides a straightforward process for committing changes to the repository, automatically generating scripts for database objects. In the Source Control Manager of the tool, the developer can easily select an object from the list and commit its changes to the repository. Subsequently, the Source Control tool detects the changes, generates a script for the object, and delivers it as a .sql file to the repository. When another developer needs to retrieve the latest changes from the repository, the tool deploys those changes by updating the database with the generated .sql script.

Note

Source Control starts tracking changes after the database has been linked to source control.

It is also important to link static data to source control to prevent any data loss when updating your local database with the latest changes from the remote repository or reverting database changes made to the object and static data in a database.

Prerequisites

Let’s assume there are two sample databases - development and production - and a development repository. The databases are synchronized, ensuring that objects such as Table1 and Table2 of both databases remain consistent with their DDL operations.

We need to pull the changes from the development repository and deploy them to the production database using dbForge Source Control.

The point to consider is the timing of when the user re-links the production database - before or after committing changes.

Let us explore the following deployment scenarios:

  • Case 1: Both databases are linked to the same version control repository. A user makes changes and commits them to the repository without disconnecting from it at any point. Then, the user gets the remote changes into the production database.
  • Case 2: Both databases are linked to the same version control repository. However, for some reason, a user disconnects the production database from the repository, modifies the development database, and commits changes. Then, the user re-links the production database to the repository to fetch any remote changes.

Cases

Case 1

1. Link the development and production databases to the development repository in the dedicated database development mode. The Refresh progress window opens automatically, showing the stages of the refresh operation. Also, the Source Control Manager opens for each database.

Note

The database can be linked to the repository anytime before committing the changes.

2. In the development database, modify Table1 by adding a column, delete Table2, and add Table3 to the database.

3. Refresh the Source Control Manager.

4. Commit these changes to the development repository. The Commit progress window opens, showing the stages of the commit operation. When all the stages are complete, click OK to close the window.

5. Switch to the Source Control Manager of the production database and refresh it. Source Control detects the changes and displays them with the following change types in the Remote changes section:

  • Modify for Table1
  • Remove for Table2
  • Add for Table3

6. Select the objects whose changes should be deployed from the repository to the production database and click Get Latest.

Case 1

Case 2

1. Link the development and production databases to the development repository in the dedicated database development mode. The Refresh progress window opens automatically, showing the stages of the refresh operation. Also, the Source Control Manager opens for each database.

2. Unlink the production database from the repository.

3. In the development database, modify Table1 by adding the column, delete Table2, and add Table3.

4. Commit these changes to the development repository. The Commit progress window opens, showing the stages of the commit operation. When all the stages are complete, click OK to close the window.

5. Link the production database to Source Control and see the following:

  • Table1, which has been modified, is now marked as a conflict.
  • Table3, which has been added, is in the Remote changes section.
  • Table2, which has been removed, is in the Local changes section.

6. To deploy the changes to the production database, select the objects and do the following:

  • In the Remote changes section, click Get Latest for Table3.
  • In the Local changes section, click Undo for Table2. In the pop-up window that displays, click Yes to confirm the undo operation.
  • In the Conflicts section, click Get Remote for Table1. After that, the table with the Modify change type will be displayed in the Remote changes section. Select the object and click Get Latest.

Case 2

In conclusion, when deploying changes from the development repository to the production database using dbForge Source Control, it is recommended to always maintain the connection between the source control and the production database. Alternatively, it is possible to deploy changes using the dbForge Schema and Data Compare tools.

Deploy changes using Get Latest

1. In Object Explorer, right-click the database containing the changes and select Source Control > Commit.

2. In the Local Changes section, select the checkboxes next to the changes you want to commit and click Commit.

Commit the changes

3. The Commit progress window opens, showing the stages of the commit operation. When all the stages are complete, click OK to close the window.

Note

The flow may differ depending on the timeline you link the databases to version control - before or after the commit operation.

4. In Database Explorer, right-click the remote production database and select Source Control > Get Latest.

Note

If you have modified the same object in both databases, Source Control will mark it as a conflict. To resolve a conflict, go to the Conflicts section, select the object and click Get Remote to apply new changes to the remote database. For more information, see Resolve conflicts.

5. In the Remote changes section, select the object and click Get Latest. For more information, see Get the latest version.

Get Latest

6. Confirm that you want to pull the latest changes and click OK. The Get Latest progress window opens, showing the stages of the operation. When all the stages are complete, click OK to close the progress window. The production database will be updated with the latest changes.

Helpful guides

Want to Find out More?

Overview

Overview

Take a quick tour to learn all about the key benefits delivered by dbForge Source Control for SQL Server.
All Features

All features

Get acquainted with the rich features and capabilities of the Source Control in less than 5 minutes.
Request a demo

Request a demo

If you consider employing the Source Control for your business, request a demo to see it in action.
Ready to start using dbForge Source Control for SQL Server?